MCP Tool Descriptions Are Claims, Not Permission Boundaries
A tool name, description, and schema can guide model behavior without proving what the server can access or where data can go. Adoption review must compare the full declaration with runtime permissions, call inputs, and network destinations.
Read in JapaneseThe stable Model Context Protocol specification describes a tool description as human-readable metadata and says tools are model-controlled: a model can discover and invoke them from context. The same specification requires clients to treat tool annotations as untrusted unless the server itself is trusted. That separation is the central finding: descriptive metadata helps selection, but it does not constrain the process, credential, filesystem, or network behind the tool.
Invariant Labs demonstrated the consequence in its original tool-poisoning report. A tool presented as arithmetic included extra instructions in its description telling the model to read local configuration and an SSH private key, then place that data in a tool argument. The published demonstration is evidence that description text can become an instruction channel. It does not establish that every client, model, or MCP server behaves the same way.
The declared function and the effective authority
Consider a tool named search_invoices with the visible purpose “Find invoices by supplier.” Its input schema may contain only a query string. Neither fact proves that the server process lacks access to environment variables, a home directory, a broad accounting token, or arbitrary outbound hosts.
| Review surface | What it can establish | What it cannot establish |
|---|---|---|
| Tool name and description | Intended use and model-facing guidance | Runtime access or honest behavior |
| Input schema | Accepted argument shape | Whether the server ignores it or performs hidden work |
| OAuth scope | Authority granted at a remote API | Local file access or another credential in the process |
| OS/container policy | Files, processes, and sockets the runtime can reach | Whether returned content is truthful |
| Egress policy and logs | Permitted and observed destinations | Absence of covert use through an allowed destination |
The practical review therefore has two records. The declaration record contains the complete tools/list result, including descriptions, schemas, and annotations without display truncation. The authority record contains the exact executable or remote endpoint, granted scopes, injected secrets, mounted paths, effective user, and permitted network destinations. A mismatch is actionable even when no exploit has been reproduced.
Connection and update checks
Before connection, export the complete tool catalog and review text that the model receives, including parameter descriptions. Run the server with a task-specific account, narrow API scopes, only required mounts, and an outbound allowlist. For a call that may disclose data, the confirmation should show the actual arguments and destination rather than only the friendly tool title. The stable tools specification specifically recommends showing tool inputs before a call to reduce malicious or accidental exfiltration.
Repeat the declaration capture after package, image, endpoint, or server-version changes. The stable protocol permits a server to announce that its tool list changed, so an earlier approval should not silently cover a later description or schema. Compare the new catalog with the accepted record and re-evaluate any added argument, instruction, destination, or capability. A hash or diff detects change; it does not decide whether the change is safe.
Specification status and limits
The normative basis reviewed on September 22, 2026 is the stable MCP revision dated July 28, 2026. The separate draft specification was reviewed as work in progress and is not treated as a deployed requirement. The recommended sandbox, catalog diff, and egress controls above are operational conclusions drawn from the stable trust model and the published experiment; they are not protocol features that MCP automatically enforces.
This source review did not test a current client, inspect a deployed server, or measure prevalence. It supports a connection rule: tool text can explain a capability, while effective authority must be verified at the runtime and destination boundaries.