Not by default. The MCP tools specification says clients must consider tool annotations untrusted unless they come from trusted servers. A tool description is text written by the server's author, and the model reads it. So a label such as read only is a claim to verify, not a security control.
What a tool definition contains
According to the specification, a tool has a name, an optional title, a description, an input schema, an optional output schema and optional annotations describing behavior. The assistant uses these to decide when and how to call the tool.
That means a description influences the model. Whoever controls the server controls what the model reads about each tool.
Why this matters
Three situations come up in practice.
- A careless description. The tool does more than its text says.
- A mislabeled action. OpenAI's documentation warns that a server can mislabel a write action as read only.
- A changed tool. Claude's help center says server developers can change tool behavior without notice. A tool that was fine on the day you approved it can differ later.
The word trusted is doing the work in the specification. Trust has to come from something you can check, such as ownership of the server, a review of its behavior, and a record of what it did.
How to verify instead of trusting
| Claim | Check |
|---|---|
| This tool is read only | Run it with a token that has no write rights and see what happens |
| This tool only touches one project | Test with a token scoped to a different project |
| This tool returns plain data | Inspect the output for embedded instructions |
| This tool has not changed | Re-read the tool list after each vendor release |
What to do in a buyer evaluation
- Get the full tool list with descriptions in writing.
- Ask which annotations the server sets and how they are decided.
- Test the permission boundary with scoped tokens, not by reading text.
- Ask how you will be told about a tool change, and how soon.
- Keep write tools off until you have run them in a test project.
The role of the human prompt
The specification says there should be a human in the loop, with UI that makes clear which tools are exposed and confirmation prompts for operations. When descriptions can be wrong, that prompt is the backstop. Do not click Allow always on a tool you have only read about.
A worked example: a tool that says read only
This is a hypothetical tool for illustration. A connector lists a tool named export_findings with the description: returns a list of findings for a project, read only. A second tool, close_findings, says it marks findings as resolved.
You are reviewing before approval. You do not stop at the descriptions. You create a token with read scopes only and call each tool through the vendor's test environment. The first tool returns data as promised. The second one is refused with a permission error, which is what you want. Then you try the first tool with a project outside the token's scope and it also refuses. Your conclusion rests on observed behavior.
Now the other outcome. Suppose the first tool had quietly created an export file in a shared location. The description would still say read only. That mismatch is what OpenAI's documentation warns about, and why the specification tells clients to treat annotations as untrusted.
Step by step: a description review
- Copy every tool name, title and description into a spreadsheet.
- Add columns for read or write, inputs, and what each returns.
- Highlight any tool whose description is vague or promotional. Descriptions should say what the tool does.
- Highlight any description that contains instructions addressed to the model, such as telling it to call another tool first. That is a warning sign.
- Test each highlighted tool with a scoped token.
- Record results and the date.
- Repeat after each vendor release.
Table: what a description can and cannot tell you
| A description can tell you | A description cannot tell you |
|---|---|
| The intended purpose | Whether the server does exactly that |
| Names of inputs | What the server does with them |
| Whether the author calls it read only | Whether it is read only |
| How the model is likely to use it | Whether the author is trustworthy |
Changes over time
The tools specification allows servers to emit notices when the tool list changes, and Claude's help center warns that developers can change behavior without notice. A description that was accurate in March can be stale in October. Keep the spreadsheet under version control, so a diff shows what changed.
Where hostile text can hide
Descriptions are text that the model reads. A malicious or compromised server can use that text to steer the model. Your review should include a plain read of each description, looking for odd sentences. This is not a technical test, but it catches the obvious cases.
What the buyer should require
A vendor should provide the full tool list in a document you can keep, with changes marked in release notes, and should accept a test plan using scoped tokens. If the vendor treats descriptions as marketing copy, that is a warning about how carefully tools are maintained.
Where Safeguard fits
Safeguard offers an MCP Guardrail for policy on tools agents can call, which is the kind of control that does not depend on a description being honest. You can also review plain output through the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a tool is described to an assistant, then ask how you would confirm that description is true.
Quick check
Who writes a tool description?
The server's author. The assistant reads it when deciding which tool to call.
Can a read only label be wrong?
Yes. OpenAI's documentation notes that a server can mislabel a write action as read only, so verify with scoped tokens.
Should I trust a tool because it comes from a known vendor?
Trust the vendor to the extent your contract and testing support, and still verify behavior with scoped tokens.
Sources
- MCP specification, tools
- Claude Help Center, custom connectors using remote MCP
- OpenAI developer docs, MCP
Last reviewed: 19 October 2026.
