MCP readOnlyHint Does Not Remove Side Effects or Disclosure Risk
readOnlyHint describes whether a tool claims to modify its environment. It does not enforce that claim or rule out data disclosure, external requests, billing, audit records, or effects caused by composition.
Read in JapaneseIn the stable MCP schema, readOnlyHint: true means a tool claims that it does not modify its environment. The same schema calls every tool annotation a hint and says clients should not make tool-use decisions from annotations supplied by an untrusted server. The official MCP Blog sharpens the distinction: annotations can inform confirmation and policy, but they do not provide enforcement, sandboxing, or resistance to prompt injection.
“Read-only” is therefore narrower than “no security-relevant effect.” A read call can disclose private records to the model, send a query to an external service, consume quota, add a provider audit entry, populate a cache, or return untrusted content that influences a later write. Some of these are normal and documented effects. The adoption error is treating the annotation as proof that none can occur.
One lookup, several observable effects
Assume find_customer is marked readOnlyHint: true. It accepts an email address and returns a CRM profile. The CRM record may remain unchanged, yet the request still crosses boundaries.
| Effect | Compatible with a read-only claim? | Separate control |
|---|---|---|
| Return a private customer record | Yes | Field-level access and output minimization |
| Send the email address to a remote CRM | Yes | Destination and data-transfer policy |
| Create an access or billing log | Often yes | Retention, audit, and cost review |
| Write a local cache or telemetry record | Depends on declared environment semantics | Runtime observation and filesystem policy |
| Trigger a later email tool with returned text | The lookup itself may be read-only | Cross-tool approval and data-flow control |
| Delete or update the CRM record | No | Server-side authorization plus runtime test |
The table separates the annotation’s intended dimension from privacy, egress, and composition. openWorldHint can add useful context about interaction with external entities, but it is also a hint. Neither field should grant network access or skip a required data-transfer decision by itself.
Evidence for a trusted read path
Start with the complete tool definition and identify who operates the server, how the artifact is delivered, and which version is running. Compare the readOnlyHint claim with the implementation contract and provider API methods. Give the server a credential that lacks update and delete scopes, even when the description says it only reads. Restrict filesystem writes and outbound destinations at the runtime when the environment supports those controls.
Test with a dedicated account and synthetic record. Observe provider audit logs, network destinations, local file changes, queue activity, and charges before and after one call. Repeat a call only when the test itself is safe; readOnlyHint does not imply idempotence, which has a separate hint. Verify an error case as well, because retries and fallback routes may use different code paths. These are recommended checks; this source review did not execute them against a server.
For user approval, display the record category, fields requested, account, and destination. A label such as “read-only search” omits the disclosure decision. When returned content may drive a subsequent write tool, place a new confirmation at that transfer rather than carrying the lookup approval forward.
Stable requirements, draft proposals, and limits
The normative basis reviewed on September 22, 2026 is the stable MCP revision dated July 28, 2026 and its versioned schema. The official March 2026 post lists additional annotation SEPs as Draft or Proposal. Those ideas may help future clients describe trust and sensitivity, but they are not treated here as stable requirements or available controls. The current readOnlyHint remains descriptive metadata.
This review establishes annotation semantics and a verification method. It does not claim that a named server mislabels tools, that all reads create the effects listed above, or that a clean test proves every future call safe.