Reading and changing

Reads run straight away. Every tool that changes data — every POST, PUT, PATCH and DELETE — asks the person first, and does nothing until they say yes.

What the person sees

When a client calls a changing tool, the server sends it an MCP elicitation (elicitation/create, form mode) in the middle of the call. The client shows the person the exact request:

text

Confirm a change to Pawsitive Future

Approve a claimed voucher and credit the clinic (deferred EFT)
POST /api/claims/c-4471/approve
Runs as you@yourorg.org, with your own permissions.

Sent with it:
{ ... the JSON body, when there is one ... }

Nothing changes unless you tick the box and confirm.

There is one box, Make this change, unticked.

What each answer does

Answer	Result
Box ticked, confirmed	The request runs, with the same URL and body that were shown.
Declined, cancelled, or the dialog closed	Nothing runs. The tool returns `isError: true`.
Submitted with the box unticked	Treated as declined.
No answer within 90 seconds	The change is abandoned and nothing runs.
The client cannot show a form	The write is refused outright.

Why it can be relied on

The model cannot answer it. The dialog goes to the person's client and the answer comes back from there; the model never sees either.
What is shown is what runs. The message is built from the same resolved URL and body the call then sends, inside the same tool call. There is no second request that could carry different arguments past an approval.
It fails closed. A client that did not declare form elicitation support cannot ask, so its changes are refused rather than run unconfirmed.
The window closes before the connection can. The load balancer drops a connection idle for 120 seconds, so an unanswered confirmation expires at 90. A change that ran after that would succeed with nobody told.
Long requests are flagged. The dialog shows the first 4,000 characters and says how many more are not shown. Decline if you have not seen enough.

It is only as good as the client that shows it. A client that auto-accepted confirmations would defeat it, the way a browser that auto-clicked "Allow" would defeat a consent screen.