Topic starter
19/08/2026 3:50 pm
TL;DR: Tool annotations in MCP are only useful for governance when their claims are trustworthy, because untrusted servers can still misrepresent read-only, destructive, idempotent, or open-world behaviour, according to Stacklok’s analysis. That makes provenance, verification, and session-level policy the real control surface, not the annotation syntax itself.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Tool annotations are becoming the risk vocabulary for agentic systems. That matters more than it might seem.”.
Key questions
Q: What breaks when MCP tool annotations are treated as trustworthy without verification?
A: Policy breaks because annotations are only hints unless the declaring server has been proven trustworthy.
Q: Why do MCP tool risks increase when multiple tools are used in the same agent session?
A: Risk increases because a safe-looking tool can become dangerous when paired with another tool that can move data externally.
Q: How should teams decide whether to trust MCP tool metadata from a server?
A: Teams should trust metadata only when the server has passed provenance verification, signature checks, and annotation validation against its source code.
Practitioner guidance
- Validate annotation claims against source code Require provenance checks, signature verification, and source-to-artifact matching before any tool annotation is allowed to influence policy decisions.
- Treat unvetted servers as pessimistic by default Keep destructive, non-idempotent, and open-world assumptions in place until the server has been verified through a trusted registry or internal review.
- Apply session-level policy to tool combinations Evaluate whether a read-only tool becomes risky when paired with open-world communication or other external reach in the same session.
Bottom line: MCP tool annotations are useful only when their claims are verified against provenance and source code, not when they are accepted as self-certifying labels.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:26 pm
Trustworthy tool annotations are a supply chain problem before they are a policy problem. MCP makes metadata the language of tool governance, but language is not evidence. If a server can declare itself read-only while behaving destructively, then the control surface has already shifted upstream to provenance, signing, and verification. Practitioners should treat annotation trust as part of the identity supply chain, not as a UI or schema concern.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between tool annotations and tool trust in agentic governance?
A: Tool annotations describe claimed behaviour, while tool trust is the verified confidence that those claims match reality. An annotation can say a tool is read-only, but trust only exists when provenance and code review confirm that it cannot mutate state or reach outside its intended boundary.
👉 Read our full editorial: MCP tool annotations need trust, not just metadata