The MCP spec requires servers to validate tool inputs, implement access controls, rate limit calls and sanitize outputs. Most client side controls are only recommended: confirmation prompts, showing inputs, validating results, timeouts and audit logging. A human in the loop is a should, not a must.
The server side: musts
The tools page of the current draft lists four things a server must do.
- Validate all tool inputs.
- Implement proper access controls.
- Rate limit tool invocations.
- Sanitize tool outputs.
These are short statements. The spec does not say how strict validation must be or what a good rate limit looks like, so a server can meet the letter and still be loose.
The client side: shoulds
For clients the draft says they should prompt for confirmation on sensitive operations, show tool inputs to the user before calling the server, validate tool results before passing them to the model, implement timeouts, and log tool usage for audit purposes. It also says clients must treat tool annotations as untrusted unless they come from trusted servers.
Side by side
| Control | Applies to | Strength |
|---|---|---|
| Validate inputs | Server | Must |
| Access controls | Server | Must |
| Rate limiting | Server | Must |
| Sanitize outputs | Server | Must |
| Human in the loop for tool calls | Client | Should |
| Confirmation for sensitive operations | Client | Should |
| Show inputs before sending | Client | Should |
| Validate results | Client | Should |
| Timeouts | Client | Should |
| Audit logging | Client | Should |
| Treat annotations as untrusted | Client | Must |
What this means for you
If you build a server, treat the four musts as a floor and write tests for each. If you choose a client, ask which of the shoulds it actually implements, because the spec lets a client skip all of them and stay compliant.
If you run agents in production, write your own policy for the gaps:
- Decide which tools need approval and enforce it outside the model.
- Log every call with the identity, tool, arguments and result status.
- Set per agent limits on call volume and loop length.
- Re-check the tool list after every server update.
Why approval cannot rest on the model
The spec also describes a user interaction model in which tools are model controlled. That is why approval and logging cannot be left to the model. They have to be enforced by the client, a proxy or the downstream system.
Safeguard includes policies, gates and guardrails for agent tool use, and a free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through the setup flow and note each point where a server asks for access, then compare those points with the controls in the table.
Click through it at your own pace, or open it full screen.
Quick check
Is human approval mandatory in MCP?
No. The draft says there should always be a human in the loop with the ability to deny tool invocations, which is a recommendation. Enforce approval in your own client or policy layer.
Who is responsible for sanitizing tool output?
The spec makes it a server duty, and clients should also validate results before passing them to the model. Doing both is safer than trusting either.
Sources
Last reviewed: 19 October 2026.
