The MCP tools specification gives servers four duties on every tool call: validate all inputs, implement access controls, rate limit invocations, and sanitize outputs. Clients have their own list. Treating these as a fixed checklist at the tool boundary keeps a tricked model from turning a helpful tool into a hole.
The server list
The security considerations section of the MCP tools specification says servers must:
- Validate all tool inputs.
- Implement proper access controls.
- Rate limit tool invocations.
- Sanitize tool outputs.
It is short, and each line hides real work.
Validating inputs
A tool declares an input schema in JSON Schema. The schema checks shape, such as types and required fields. It does not check meaning. A string field named path still accepts a traversal sequence, and a url field still accepts an internal address.
So validate twice. Use the schema for shape, then add code for meaning: allowed directories, allowed hosts, length limits, and a refusal when anything is off. Arguments come from a model that may have read hostile text, so treat them as untrusted, which is the same advice OWASP gives for any model output.
Access controls
Decide who may call each tool before the call arrives. The identity should come from a validated token, not from the request body or a session ID. Check the caller against the specific resource, such as this record or this repository, not only against the tool name.
Authorization belongs in the tool or the system behind it. OWASP says to enforce authorization in downstream systems instead of relying on the model to decide.
Rate limiting
Set limits per caller and per tool. Expensive and destructive tools deserve tighter limits than lookups. A limit gives a mistake or a loop a ceiling, which also helps with cost. Return a clear error so the client can back off.
Sanitizing outputs
Tool output goes into the model's context. Anything in it can act as an instruction to the model. Remove secrets and fields the task does not need, strip or neutralize markup that your client might render, and keep error messages free of internal details such as stack traces and addresses.
The client side
For completeness, the specification says clients should prompt for confirmation on sensitive operations, show tool inputs to the user before calling the server, validate results before passing them to the model, implement timeouts, and log usage for audit. A good server and a careful client cover each other's gaps.
Error handling that helps
The specification separates protocol errors, such as an unknown tool or invalid arguments, from tool execution errors that are returned in the result with an error flag. Use protocol errors for malformed requests and execution errors for things that failed while running. Keep both free of sensitive detail.
A pre release checklist
- Each argument has a schema and a meaning check.
- The caller identity comes from a validated token.
- Authorization is checked against the resource.
- Limits exist per caller and per tool.
- Outputs are filtered, and errors are plain.
- A test sends hostile arguments and confirms refusal.
Where Safeguard fits
Safeguard includes SAST code scanning, which can help you find injection style flaws in the tool code itself, and an MCP Guardrail for governing which tools agents may reach.
Quick check
Is a JSON Schema enough input validation?
No. A schema checks types and shape, not whether a path or address is acceptable. Add meaning checks in code.
Sources
- MCP tools specification, security considerations and error handling
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 19 October 2026.
