MCP tool annotations describe how a tool says it behaves, and the specification says clients must treat them as untrusted unless they come from a trusted server. Do not auto approve a tool because its annotation says read only. Decide by the server's trust level and the tool's real effect.
What the specification says
In the MCP tools specification, a tool definition has a name, optional title, description, input schema, optional output schema and optional annotations describing behavior. A warning next to that list says that for trust and safety, clients must consider tool annotations untrusted unless they come from trusted servers.
The same applies to the description. It is text written by the server operator, and it is placed in front of a model.
Why this is a real concern
Suppose your client skips confirmation for tools that claim to be read only. A server you do not control can label a destructive tool that way. The label is just a field in a JSON response.
Three habits follow.
- Never base an approval bypass only on a self reported annotation.
- Treat tool descriptions as untrusted input to the model, since text in them can carry instructions.
- Re-check the tool list after changes. Servers that declare the list changed capability can send a notification when tools change, and the client then fetches the new list.
A trust tier approach
Group servers by how much you know about them.
- Operated by you, reviewed: Example: Internal server, Annotation handling: May inform defaults
- Vendor server, contract and review: Example: Approved external server, Annotation handling: May inform defaults, spot check
- Unknown server: Example: Found online, Annotation handling: Ignore for decisions
Even in the top tier, annotations should be advisory. The real control is the scope of the credential behind the tool.
What to enforce yourself
- Keep an allowlist of servers and tool names, and require review to add to it.
- Pin or record the tool definitions you approved, and flag differences when the list changes.
- Apply approval rules by action type that you determine, not by the label.
- Validate inputs and outputs at the tool boundary, as the specification says servers must and clients should.
What to do with descriptions
Treat a tool description as text the model will read, which means it can try to steer the model. Keep descriptions short in tools you write, and review descriptions from servers you adopt, looking for instructions aimed at the model rather than facts about the tool.
Where Safeguard fits
Safeguard includes an MCP Guardrail and policies that you can use to govern which servers and tools agents may use. Use them to hold your allowlist rather than depending on server supplied labels.
Click through it at your own pace, or open it full screen.
Quick check
Can I trust a read only annotation from a vendor I have a contract with?
You can weigh it more, but the specification says to treat annotations as untrusted unless the server is trusted. Keep credentials narrow so a wrong label cannot do much harm.
Sources
Last reviewed: 19 October 2026.
