Designing an MCP tool that must confirm before it acts

Guest article by Arthur Teboul, founder of DokuTrak.

Most tools an AI assistant can use are cheap to get wrong. Ask for a stock price, get a stale number, and you ask again. A few tools are different, because their output is something that happens in the world. Some actions, like a message sent to a real person, can't be taken back.

If you build tools for assistants, that difference deserves its own design pass. This article uses three examples: market-data tools whose listed examples are reads, a hypothetical alert tool, and a real product whose connector sends requests to real clients. Disclosure: I'm Arthur, founder of DokuTrak, which is the third example.

Reads are forgiving, writes are not

A read tool asks a question and returns an answer. Call it twice and the world stays the same. Call it with the wrong ticker and the cost is a confusing paragraph that you can see and correct.

Leeway's MCP page illustrates this. The examples listed there are market-data retrievals: prices, company updates, market-cap history. Each is a read. I'm describing only what that page shows, not the whole server. I haven't audited it, and it may change.

Reads still carry some risk. Some can cost money per call, so a looping assistant can run up a bill. And returned content can be untrusted: text from a third party that ends up in the assistant's context. Those concerns are real, but they differ from a mistake you can't undo.

Now imagine, as a thought experiment, a market-data connector extended with a send_alert tool that emails or texts someone when a price crosses a threshold. This is hypothetical. I did not find a send-alert tool on the cited page; this example is invented. An alert goes to a recipient who never asked the assistant anything. If the assistant reads "tell me if it drops below 40" as "tell my whole team," the damage is done before anyone notices.

A second example: asking clients for documents

A real case is client document collection. DokuTrak is built for US professional-services firms, such as accountants chasing clients for paperwork during tax season.

What the product does today:

• The firm creates a request with a checklist of what it needs.
• The client uploads files through a link, with no account to create.
• Reminders nudge the client along.
• Optionally, an AI first pass flags files that look wrong, unreadable, or expired.
• A human accepts every document. The AI flags; a person decides.

DokuTrak's connector lets an assistant create and send a request, check its status, ask again for rejected files, and download the files as a ZIP. It cannot accept or reject a document, and it cannot touch billing, workspace settings, or API keys.

That boundary is a design lesson in itself: the judgment call stays with a human. But the connector can send, and sending a request contacts a real client. That is the consequential write.

What is shipped and what is proposed

To be plain: everything below is a proposal. DokuTrak's connector does not currently implement a confirm-before-send step. Today it creates and sends. The rest of this article describes how I think a tool like that should be shaped.

1. A side-effect-free preview

Split the action in two. prepare builds everything and sends nothing. It returns what would go out: recipient, message content, checklist, and reminder schedule. Because it changes nothing in the world, the assistant can call it as often as it needs.

2. Approval that is enforced, not requested

A preview alone enforces nothing. If the assistant can call send right after prepare, the preview is decoration. Having the model ask "shall I send this?" and treating its own text "yes" as consent is also insufficient, because the model can misread, or be steered by, the very content it is processing.

Approval has to be checked by something the model can't talk its way past. Two designs work:

• A host-side approval gate. The client application shows the preview to the user and blocks the send call until the user clicks approve.
• A server-issued single-use approval token. The server creates a token only after a human approval step outside the model's control. The token is bound to an immutable preview, the recipient, the exact content, and an expiry. send takes the token, not fresh parameters.

Binding matters. If the assistant changes the recipient or edits the body after approval, the token no longer matches and send fails. If the preview expires or any part of it changes, approval is invalidated and the human sees the new version.

"Single-use" needs care, though. It means the token can authorize one side effect, not that a second call must error. If the first call's response is lost and the assistant repeats the request with the same token, the server should return the stored result of the first send, without a second side effect. A retry then gets an answer instead of a puzzling failure.

3. Idempotent retries

Networks fail and assistants retry. Attach an idempotency key to the prepared operation. The first send with that key does the work and stores its result. Any later call with the same key returns that stored result instead of acting again. This should hold even while the first call is still in flight, so two near-simultaneous retries can't both fire. For a client already stressed about their taxes, a duplicate "please upload your documents" message is more than a nuisance.

4. Status lookup by operation key

The hardest case is silence: the assistant calls send, the connection drops, and nothing comes back. Did it go out?

DokuTrak's current connector can check a request's status. I have no evidence that it can look anything up by an idempotency key or a preview ID. So consider a hypothetical timeout in which the assistant never received the request ID. A status check on that ID wouldn't help, because the assistant has nothing to look up. A lookup by operation key would fill that case, since the assistant already holds the key. It would return "not found," "in progress," or "sent," plus the request ID when there is one.

That lookup is for visibility. Because retries are idempotent, the assistant doesn't need the answer before retrying safely. It lets the assistant tell the human what happened rather than guess.

What it might look like

An illustrative sequence, not a shipped API. Names and fields are invented.

# ILLUSTRATIVE ONLY — not a real DokuTrak or Leeway API

preview = prepare_request(client="Dana", checklist=[...])
# -> preview_id, full message text, operation_key, expires_at. Sends nothing.

# Host shows the preview. The user clicks Approve (outside the model).
token = <server-issued, single-use, bound to preview_id + recipient + content + expiry>

result = send_request(approval_token=token, operation_key=preview.operation_key)
# -> success: request_id, status "sent"
# -> timeout: outcome unknown

status = get_operation_status(operation_key=preview.operation_key)
# sent / in_progress / not_found
# Repeating send_request with the same token and key returns the stored result.

The same shape would apply to the hypothetical alert tool: prepare it, show it, get real approval, send once, and check rather than guess.

A closing checklist

If your tool does something you can't undo, ask:

• Can the assistant preview the action without performing it?
• Is approval enforced by the host or the server, not just by the model's own words?
• Is the approval bound to the exact recipient, content, and expiry, and void if any of them change?
• Does a repeated call return the stored result without a second side effect, even while the first is in flight?
• Can the assistant look up what happened using a key it still has after a timeout?
• Are judgment calls (accept, reject, pay, delete) left to a person?

None of this makes an assistant less useful. It makes it the kind of colleague you'd let near your clients: one that shows its draft, and can't press send until you've said yes.

---

About the author
Arthur Teboul is the founder of DokuTrak, client document collection software for US professional-services firms. Clients upload through no-account links, and DokuTrak has an open-source MCP connector.

This is a guest article. The views expressed are the author's own.