Giving an AI assistant the keys, not the whole building: action boundaries for MCP tools

October 31, 2026 · By Arthur Teboul · 7 min read

When you connect an AI assistant to a real system through MCP, the useful question is not "is the assistant smart enough?" It is "what can this tool do if the assistant is wrong, confused, or following a bad instruction?" A tool list is a set of keys. You decide which doors they open.

This guide gives a way to sort tools by consequence, a preview/commit checklist for the risky ones, and a clear separation between boundaries a client suggests and boundaries a server enforces.

Sort tools by what they can't take back

Group every tool by the worst thing it does. Six tiers cover most cases.

Read. Lists, fetches, searches. The worst case is exposure of data the assistant was already allowed to see. These can usually run freely, though read access to sensitive data still deserves scoping.

Draft. Creates or edits something only the owner can see. Nothing leaves the building, and the owner can discard it. Drafts are the best place to let an assistant be fast and wrong.

Publish. Makes something visible to the public. It can be unpublished, but people may have already seen it.

Send. Delivers a message to a third party. This is the first tier that can't be undone. Once an email lands in someone's inbox, deleting your copy doesn't help.

Spend. Moves money or creates an ongoing financial commitment. Treat it as irreversible even when a refund path exists.

Delete or replace. Destroys or overwrites something that works. The danger is that the old thing is gone, and often nobody notices until it matters.

The tiers don't all demand the same friction. Friction should rise with irreversibility and with who is affected. A draft that only the owner sees needs almost none. A message to an outside person needs a human decision.

Not every write needs a prompt. Making a draft or a reversible, owner-scoped change interrupt-free is often right. Prompting on everything trains people to click "allow" without reading, and that defeats the prompts that matter.

Preview, then commit

For anything at the send tier or above, split the action into two steps: a preview that changes nothing, and a commit that does. This checklist works for most tools.

Show the exact payload. Recipient, content, amount, target. Not a summary of what the assistant intends to do, but the actual arguments it is about to pass.
Name the side effect in plain words. "This emails a client" or "this replaces the domain currently serving your site."
State what can't be undone. If nothing is irreversible, say so. If something is, say it first.
Require an explicit yes from the person who owns the outcome. Not the assistant's own judgment that the request was probably approved. The owner, in this conversation, about this specific action.
Make the commit argument specific. A confirmation tied to the exact payload beats a generic "confirm: true" the assistant can pass on its own.
Fail closed. If the preview and the commit disagree, or the confirmation is missing, do nothing.
Leave a record. Who approved what, and when, so you can reconstruct events later.

Items 1 to 4 are conversation design. Items 5 and 6 only mean something if the server cares about them. That distinction matters most, so here it is directly.

Hints versus walls

The MCP specification's tools section says tool annotations should be treated as untrusted unless they come from a trusted server, and that clients SHOULD prompt the user to confirm sensitive operations. Two things follow from that wording.

First, an annotation such as "destructive" or "needs approval" is a hint from a tool's author to a client. A client may honor it, and a well-behaved one will. But the hint itself enforces nothing.

Second, the prompt lives in the client. Whether it appears depends on that client's implementation, its settings, and the mode the user is running it in. A server author can't see any of that.

So there are two different kinds of control:

Client-side annotations and prompts are cooperative. They shape what a compliant client asks the human. They are valuable, because most people use compliant clients, but they are a request, not a guarantee.
Server-side boundaries are structural. They hold regardless of which client is calling, what the model decided, or whether a human was watching: a tool that doesn't exist, a flow that requires a step the assistant can't perform, a parameter that must be set explicitly.

Use both. Rely on the second for anything you can't afford to get wrong.

One related trap: a connector lacking a capability is not the same as a server refusing it. If a connector simply doesn't expose a "delete" tool, the assistant can't delete through that connector. That is a real limit, but it describes what the connector offers. It says nothing about what the underlying API would accept from some other caller. Be precise about which one you're relying on.

Example: a site builder

RunCabin's agent documentation and connect guide show how the tiers can map onto a real flow.

Free site, live in one call. Standing up a site is a low-stakes, owner-scoped action, so it doesn't need ceremony. The assistant can do it in a single call. Friction here would only slow people down.
Domain purchase passes an owner-completed browser checkout. This is the spend tier. The assistant can start the process, but the payment step happens in the owner's browser, completed by the owner. The boundary isn't a polite request to the model. The assistant has no path to finish the purchase on its own.
Replacing a working domain needs an explicit replace=true, after the owner agrees. This is the delete/replace tier. Swapping out a domain that currently works is the sort of change that causes quiet damage. The call has to carry the flag, and the flag is meant to be set only once the owner has said yes. The default behavior protects what exists.

The pattern: cheap, reversible actions are one step; spending crosses into a surface the owner controls; overwriting something live requires a deliberate, named argument. The friction sits where the consequences are.

Example: a document-request connector

DokuTrak is a different domain, but the same reasoning applies. Per the project's reviewed notes, its connector can create and send client document requests, but it doesn't accept or reject uploaded documents. A firm's human accepts each file.

That is a deliberate split between sending and judging. Sending a request is outward-facing, so it gets friction. Accepting a document is a professional judgment, so it stays with a person. The connector doesn't offer an accept or reject tool at all, so the assistant has no way to make that call through it.

For the send step, the public connector README describes the client-side layer. It flags create_request so that compliant clients ask for approval before every call, including in Claude Code's auto and bypass modes. It also tells the agent to show the recipient, deadline, checklist, and message, and wait for a yes.

Read that carefully. It is a client-side prompt, not a server-enforced one. The README says compliant clients honor the flag, including in those modes. It doesn't promise that nothing can skip the prompt, and you shouldn't read it that way. A client that ignores annotations, as the specification allows for untrusted hints, could still make the call. The flag raises the odds that a human sees the preview. The decision about who accepts a file is the part held structurally, because there's no tool for it.

That is a sensible layering: a hint where a hint is the best available tool, and a missing capability where the decision must stay human.

Putting it into practice

When you design or evaluate an MCP tool surface, run through this:

List every tool and place it in a tier.
For read and draft, keep friction low.
For publish and send, add a preview and a human yes, and set annotations so compliant clients prompt.
For spend, move the final step somewhere the assistant can't reach, such as an owner-completed checkout.
For delete and replace, make the dangerous behavior opt-in through an explicit argument, and default to preserving what works.
Ask of each boundary: is this a hint to the client, or does the server hold it regardless? Write down the answer.
For decisions that must stay with a person, consider whether to expose the tool at all.

Annotations are good manners. Missing tools and required steps are locks. A well-run connector uses manners for the everyday friction and locks for the doors that matter. And when you describe your own boundaries, say which is which, so the people relying on them know what they actually have.

See what your agent can do on RunCabin

RunCabin is website hosting your AI assistant runs through MCP: it publishes, edits and rolls back the site, and anything that costs money ends in a checkout you complete yourself.

Website hosting for AI agents →