Notifications
Clear all
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.
NHIMG editorial — based on content published by Stacklok: Blog insights on MCP tool annotations and trust
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams handle untrusted MCP tool annotations?
A: Treat them as claims, not controls.
Q: Why do MCP tool permissions become riskier when tools are combined?
A: Because the session can create a path that no individual tool reveals on its own.
Q: How do you know if annotation-based governance is actually working?
A: Look for consistent enforcement across verified and unverified servers, plus evidence that session-level decisions change when tool combinations change.
Practitioner guidance
- Verify tool metadata before policy use Require provenance checks, signatures, attestations, and source-code review before accepting MCP annotations as inputs to approval or blocking logic.
- Apply pessimistic defaults to unvetted servers Treat unannotated or externally sourced MCP servers as potentially destructive, non-idempotent, and open-world until the server identity has been verified.
- Evaluate tool combinations as a session Assess whether a read-only tool paired with an open-world tool creates a data movement path, then restrict the full session rather than each tool in isolation.
What's in the full article
Stacklok's full blog covers the operational detail this post intentionally leaves for the source:
- How its curated registry validates build provenance and cryptographic fingerprints before trust decisions are made.
- How annotation accuracy can be checked against source code so policy can rely on declared tool behaviour.
- How the vMCP gateway applies policy to verified metadata in practical deployment scenarios.
- How ToolHive fits into a registry-backed workflow for teams building MCP governance.
👉 Read Stacklok's analysis of MCP tool annotations and trust →
MCP tool annotations and the trust gap in agentic governance?
Explore further
19/08/2026 4:26 pm
Tool annotations are not a trust model. The MCP specification can describe behaviour, but it cannot guarantee it. When an untrusted server can self-assert low-risk attributes, the governance problem becomes one of evidence quality, not metadata format. Platform teams should therefore separate declarative labels from verified behaviour in their control design.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how quickly weak server governance turns into secret exposure.
A question worth separating out:
Q: Who should be accountable for MCP annotation trust?
A: The accountable party is the organisation that chooses to trust the metadata. In practice, platform owners, security architects, and whoever operates the registry or policy layer must own verification standards, because annotations become effective only when someone can prove they were checked.
👉 Read our full editorial: MCP tool annotations need trust, not just metadata
