A person starts in an outside AI assistant, finds a campaign in a product, and asks the assistant to send the campaign. The product may never show that conversation. The product’s service still has to work out which account the person means, what the person may send, and whether the operation actually happened.
MCP moves the entry point. MCP doesn’t hand ownership of those product decisions to the host.
The useful design question isn’t how many endpoints to expose. The question is which jobs someone can finish reliably when the product’s own screens no longer supply context, review, and feedback.
Separate the host, the connection, and the work
An MCP server isn’t automatically an agent. The protocol describes how hosts, clients, and servers exchange capabilities and context, not the application’s model loop. A server may expose ordinary operations or hand a bigger job to an agent of its own. MCP architecture
When a tool delegates work, make the delegation visible. “Accepted a job” isn’t “finished a job.” The caller needs a run ID and a way to retrieve the result. Otherwise the host may summarize an acknowledgment as success, or resubmit the work after the connection drops.
Rebuild the context the product’s own screen supplied
Inside the product, the open page might identify the campaign and the workspace. An outside host has to identify both through search, resource references, or explicit inputs. A display name alone is fragile: two accounts may each have a campaign called “September update.”
A useful search result includes a stable object ID and enough permitted context to tell objects apart, without exposing other accounts. At execution, resolve the chosen object against the signed-in account and current permissions. Treat an account ID supplied by the client as a claim to check, not a way to pick whichever tenant the caller wants. MCP itself doesn’t supply tenant isolation; the product’s backend does.
A valid connection is not permission for every operation
The MCP authorization spec covers access at the transport level and requires protected servers to validate tokens for their intended audience. MCP authorization
An accepted token still has to meet the product’s own rules. May this actor edit this campaign? Is sending turned on for this account? Is the sender approved? Is the reviewed recipient list still valid? The answers depend on the product, not on the generic shape of a tool call.
Likewise, a host’s confirmation can record a person’s decision without proving the backend allows the action. A tool argument saying approved: true is a claim from the caller. When execution needs a recorded approval, the service has to verify where the approval came from and tie the approval to the actor, the proposal, and the permitted effect. Renaming a tool “approve” doesn’t turn a client’s call into a human decision.
None of that requires another dialog for every write. The distinction that matters is between a trusted standing grant, a verified approval for one proposal, and untrusted text reporting that an approval happened.
Design tools around a recoverable conversation
Consider three operations: prepare a campaign, execute the prepared proposal, and retrieve the operation’s result. Preparing gives the host a concrete scope to explain, and retrieving gives a disconnected caller a route back to evidence.
A direct write is fine when the request is already precise and policy allows the write. Three steps help when selection, review, or uncertainty would otherwise get buried in one call. Don’t split every small edit into a ceremony.
| What the caller receives | What the caller can conclude |
|---|---|
| Prepared proposal | These objects and changes are proposed; nothing has changed yet |
| Review required | A specific decision remains, with a way to make the decision |
| Completed receipt | The stated effect is confirmed and can be inspected |
| Partial receipt | Some effects are confirmed; the exceptions are listed |
| Unknown outcome | The evidence isn’t enough; starting a new operation may repeat the work |
The states belong to the application; MCP doesn’t require them. The MCP tools spec supports structured results and an output schema, so a tool can return a real product result rather than a sentence the host must reinterpret. MCP tools
Keep a stable operation ID wherever the destination supports one. When the destination accepted a request but the acknowledgment vanished, a new tool call mustn’t silently mean “do the same thing again.” Keep working after the tab closes covers result lookup, direct checks, and unresolved outcomes.
Bring the review to a screen that can hold it
A host can explain a small change in text. A recipient comparison may need a richer screen. MCP Apps lets compatible hosts show tool-related interfaces in sandboxed frames, as another way to present the review, not a replacement for permission checks in the backend. MCP Apps overview
Offer a fallback that keeps the decision intact: a link to a durable review page that carries the proposal ID, the scope, and the current status. The page should require sign-in; holding the link shouldn’t grant authority. And when the person finishes review inside the product, the host needs a supported way to learn whether the work committed, was declined, or is still pending.
Keep outside access legible inside the product
Someone looking at a changed campaign should see who requested the change, which account executed the change, and what changed, without finding the original chat. Record the entry point as context, not as a substitute for identity.
Legibility matters most when the credentials belong to someone other than the person using the agent. Notion documents that MCP connections for Custom Agents use the credentials of the person who set up the connection: one product’s sharing contract, not a property of MCP. Notion Custom Agent connections
Test the contract without trusting the host’s narration
In a test workspace, prepare an operation, revoke access, and try to execute. Repeat with the capability switched off, with stale search results, and with a resource from a different account. Check that the destination stayed unchanged on every denial, not just that the host showed an error. Then test the successful path in each host the product supports, including an interrupted connection and receipt retrieval.
MCP can make a product’s operations reachable from anywhere. The product still has to make the consequences understandable.