If employees can export a report, copy a customer record or paste a support thread into an AI tool, there is a risk that some will, to save time or because the platform is hard to search. Data moved that way sits in a tool the platform owner does not control, and the platform keeps no record of what was shared.
MCP, the Model Context Protocol, gives an AI client a defined way to ask a business system for context or to request an action. For a custom platform, its use is to replace that copy-and-paste path with one that the platform's own permission checks and logs apply to. The server exposes capabilities the application already understands, such as open orders for an account or approvals waiting more than 10 days.
A workflow where data leaves by hand
Support managers may be pasting ticket histories into a chat tool to draft a customer summary, or operations staff may export the approval queue to a spreadsheet every morning to sort it.
The first server should cover one workflow like that, where data already leaves the platform by hand. Ask the people doing it which questions they paste in and which records they need to answer them. Those answers set the first server's scope, and the same people can point to edge cases a design review might miss.
Read-only resources and one drafting tool
The MCP specification separates resources, which supply context, from tools, which a model can invoke. A first server can be mostly resources: the account summary, open orders, support history or policy documents that users already search for and export, filtered to the records each user can see in the application. Then add one tool whose effect is limited and reversible, such as creating a draft follow-up task in a CRM or a ticket summary for a support agent to review.
Tool names should read like the business action: get_customer_open_orders, list_overdue_approvals, draft_project_update. A generic tool such as run_sql_query makes scope much harder to constrain: the query text decides which tables and rows are touched, so the rules the application applies above the database would have to be rebuilt around arbitrary SQL, for example through a restricted database principal or row-level security. Designing these tools is ordinary API development for an application-facing interface.
Where does a draft become a write?
A tool called "draft a follow-up task" only stays a draft if the server makes it one. The MCP tools specification puts confirmation on the client side: applications should let a human deny tool invocations and should present confirmation prompts, and clients must treat tool annotations as untrusted unless they come from trusted servers. A platform cannot count on every MCP client showing a prompt before a call, and a read-only annotation does not stop one, so the line between draft and write has to be enforced by the platform.
Creating a draft still changes state, since it writes a record, so the drafting tool needs the same authorization and logging as any other write. What it should not do is take the final business action: no customer email sent and no status changed on the underlying record. The user commits it in the application screen, under the permission check that screen already runs. If a second tool is ever allowed to submit drafts, the specification's guidance on handles applies: an identifier returned by one call does not by itself authorize anything, and the server should validate the caller's authorization against it on every call. A draft ID from one user's session should not be submittable by another user who guesses it.
Permissions, logs and what support sees
The MCP layer should call the same service methods the application's screens call, with the same user identity, so a permission change applies to both. A second permission model inside the MCP server risks drifting from the application's, because every permission change would have to be made in both places. The specification's server requirements are short: validate all tool inputs, implement access controls, rate limit tool invocations and sanitize tool outputs.
An audit record of each call can hold who called which tool, the arguments, what the server returned and whether the call was refused. Both the arguments and the returned payload need selecting and redacting where they carry personal or financial data, since a read tool's response can expose more than its request. When a drafting call fails, the support screen should show the user, the tool, the error and whether a draft was created, so a retry does not leave a second draft behind.
Related Reading
For customer booking and reorder examples, read Customer-facing MCP servers: permissions, approvals and retries. For authorization on internal .NET MCP servers, read MCP tool permissions in .NET applications.