SEP-3140: Signed Capability Declarations & Trustworthy Trust Labels - #3140

This SEP proposes an additive mechanism for MCP servers to make their declared capabilities — the tools/list, prompts/list, and resources/list outputs a client feeds to a model — authenticatable, integrity-protected, versioned, and labeled with a trustworthy, standardized risk vocabulary.

It introduces (1) a content hash + version on each declaration, (2) a signed capability manifest (JWS) bound to a discoverable publisher identity, (3) a standardized, signature-covered trust label block (effect / egress / data-sensitivity / reversibility), and (4) change semantics for notifications/*/list_changed that let a client detect and re-gate material changes ("rug pulls").

A secondary, optional section proposes a secure-by-default posture for authentication.

The goal is to convert the spec's current unactionable guidance — "clients MUST consider tool annotations untrusted unless they come from a trusted server" — into something any MCP client can actually verify and enforce. The gap is inherent to the protocol and affects every client — interactive / human-in-the-loop and autonomous alike; autonomy makes it acute, but a human approver cannot verify authenticity or detect a silent change either.

Motivation and Context

The gap

MCP tool declarations are model-facing instructions in all but name: a model reads a tool's description, inputSchema, and annotations to decide when and how to invoke it. Yet the protocol delivers these with no authenticity, no integrity, and no trustworthy risk labeling. The specification acknowledges the danger but delegates it without providing a mechanism:

• "descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server."
• "clients MUST consider tool annotations to be untrusted unless they come from trusted servers."

There is no protocol mechanism to establish that a server is "trusted," to verify that a declaration is authentic, or to detect that it changed. The MUST is therefore unsatisfiable: the implementer has been assigned a trust decision the protocol renders unverifiable.

Two concrete attack classes follow directly:

• Tool poisoning — a malicious or compromised server embeds directives in a description; the model treats them as instructions (indirect prompt injection).
• Rug pull — a server declares benign tools, is approved, then emits notifications/tools/list_changed and silently swaps in malicious definitions. There is no version, hash, or re-consent contract to catch this.

Why this belongs in the protocol, not the implementer

The natural objection is "let the client/host handle it." That fails for this specific class:

• TLS is insufficient. TLS + a trusted-URL allow-list protect the transport and authenticate the server domain, but they do not establish author/publisher provenance. A compromised or malicious trusted server, a tampering registry/marketplace, or a stdio/proxy hop (no TLS-to-origin) all serve poisoned declarations that TLS then faithfully protects end-to-end.
• Free-form annotations cannot back a security decision. They are attacker-controlled and explicitly untrusted, so a host cannot use them to gate anything (reliance on them is CWE-807).
• Interoperability requires a standard. Without a common provenance + label format, every host invents incompatible heuristics and no server can portably declare "I am authored by X" or "this tool egresses data." A per-host solution does not compose across the open ecosystem MCP is built for.

In short: provenance and trustworthy labeling of what a server declares is the one security property that neither the host nor OAuth can synthesize on their own — it requires a protocol primitive.

Who is affected: every client — a human in the loop does not close the gap

This is a protocol-level gap that affects every MCP client, not only autonomous ones:

• Interactive / human-in-the-loop clients are exposed too. MCP's safety model leans on a human able to deny a tool invocation ("there SHOULD always be a human in the loop with the ability to deny tool invocations"). But a human approver sees only the rendered description / annotations; they have no way to verify that the declaration is authentic, unmodified, or unchanged since they approved it. A poisoned description reads as legitimate, and a silent list_changed rug pull happens after approval. Human review therefore does not mitigate these attacks — it is the same unverified text either way.
• Autonomy makes it acute, not different. Removing the human removes even the chance to notice something odd, and the model's control flow is the (unverified) declaration text. Autonomous operation is the sharpest case, but it is an amplifier of a universal gap, not its source.

Authenticated declarations + machine-enforceable labels help any host: they surface verifiable provenance and risk to a human reviewer, and enable policy (risk-graduated approval, egress control, information-flow constraints) where there is no human. Both modes benefit from the same primitive.

Goals and Non-Goals

Goals

• Let a client cryptographically verify the authenticity and integrity of a server's declared capabilities before exposing them to a model.
• Let a client detect and re-gate material changes to declarations (anti-rug-pull).
• Provide a standardized, signature-covered risk/sensitivity vocabulary a host can enforce policy against.
• Be fully additive and backwards-compatible (capability-negotiated; unsigned servers keep working).
• Reuse existing MCP/OAuth infrastructure (canonical server URI, Protected Resource Metadata, JOSE).

Non-Goals

• Guaranteeing a signed server is honest. Signing establishes provenance, integrity, and accountability (like code/package signing), not good behavior. A signed-but-malicious publisher becomes identifiable, revocable, and attributable — which is the point.
• Enforcing cross-server information flow at runtime — that is unavoidably the host's job. This SEP supplies the labels the host enforces against; it does not attempt enforcement in the protocol.
• Replacing the Security Best Practices guidance; this complements it.

How Has This Been Tested?

Breaking Changes

No. The proposed changes are fully backward compatible and the MCP server integrations secure moving forward.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality) - more specifically a SEP
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Note:Extends / complements (does not replace): the Server Card WG, Tool Annotations IG, Tool Scopes WG, the Registry, ext-auth, and the Security Best Practices.

Relationship to existing work

This SEP is deliberately additive and complementary to work already underway in several MCP groups; it extends and composes with them rather than replacing any.

• Server Card Working Group — a "server card" is server-published identity and metadata, and is the natural carrier for this SEP's publisher identity and signing-key discovery. Where a server card exists, the signed capability manifest SHOULD reference/align with it rather than introduce a competing identity document; this SEP adds the integrity / signature layer over that identity.
• Tool Annotations Interest Group — the trust block is a signed, standardized subset of tool annotations. This SEP builds on the annotations model by adding cryptographic integrity and a closed, host-enforceable vocabulary; it does not replace free-form annotations (which remain untrusted-by-default).
• Tool Scopes Working Group — scopes describe what a tool is authorized to do; trust labels describe the risk / sensitivity a host gates on. The two are orthogonal and composable; this SEP aligns its label vocabulary with tool-scopes work rather than duplicating it.
• Registry — the MCP registry is the natural root of trust for publisher identity and key history; this SEP recommends registry alignment (publish / verify publisher keys) instead of a parallel trust store.
• ext-auth — identity / authorization extensions align with the secondary secure-by-default posture and the publisher-identity model.

Alignment with MCP design principles

• "Servers should be extremely easy to build." Signing is optional and can be produced by a small SDK helper or at publish time by a registry; unsigned servers keep working unchanged.
• "The host process enforces security boundaries." This SEP gives the host verifiable inputs (authenticated declarations and labels) to enforce against; it does not move enforcement into the protocol.
• "Servers should be highly composable." A standard provenance + label format is precisely what lets independently-authored servers be composed safely by one host.

Key design decisions

A signed manifest (JWS) rather than per-field signatures. One signature transitively authenticates every declaration through its contentHash, keeping messages small and verification a single operation.
Reuse of RFC 9728 Protected Resource Metadata for key discovery. No new discovery surface is introduced; the publisher JWKS and identity sit beside the existing authorization_servers and inherit the SSRF protections MCP already requires.
Binding to the RFC 8707 canonical server URI. Prevents replay of an otherwise-valid manifest against a different server (audience confusion).
Closed, enumerated trust labels (unknown ⇒ most-restrictive). A host can make a deterministic policy decision instead of parsing free text; this is what makes the labels usable for gating — whether surfacing risk to a human reviewer or enforcing policy without one.
Hashes in the manifest rather than full declaration bodies. Compactness; full-body signing is offered as a stricter option (see Open questions).