For MCP server publishers

Prove the MCP server is yours.

A name is not a signature. Anyone can publish a package, a container or an endpoint under your company’s name, and the registry entry looks the same either way. A delegation is the statement that has been missing: your domain, proven and then signed, naming the artifact you actually shipped.

Proofproof.holdings · delegation
StatementNº 2026-0184
signed byexample.com — control proven by DNS
authorizespkg:npm/example-mcp
scopemcp:serve · expires in 90 days · revocable
algorithmES256 · signature checked against the published JWKS
readingStatement presentthis domain authorized this artifact — nothing else is asserted
Published on the artifact’s own card

Why the name is not enough

One name, several publishers.

Several entries, one name

Search a well-known product and the results can include a package under the parent company’s namespace, a registry entry from an unrelated vendor with a properly verified domain of its own, a community build, and one more nobody can place. Each is a plausible reading of the same name.

Correct behaviour proves nothing

A substituted server can copy the real code and behave correctly for a dozen releases before its behaviour changes. Working software is evidence about the software, not about who stands behind it.

A signature answers a different question

Build provenance says an artifact came from the pipeline it claims. It does not say the company whose name is on the artifact ever authorized it — those are separate questions, and only the second one is about authority.

How it works

Prove the domain, sign for the artifact.

01

Prove the domain

Show control of the domain your company already stands behind, with the same kind of DNS or HTTP check you use for email. That check mints a signed token; nothing about the artifact is involved yet.

How domain verification works
02

Delegate the artifact

Sign a statement naming one artifact — a package URL or an https endpoint — and the capabilities it is authorized for. The statement is scoped, it expires, and you can revoke it on its own without touching the domain proof or any sibling statement.

Proof of Delegation
03

Publish it where the artifact lives

Put the signed token on the artifact’s own card. A verifier that already knows which domain to expect checks the signature against the issuer’s published keys — those too are fetched over the network, not bundled with the statement. Revocation is checked too, by default: the verifier reads the published status list, and asks the issuer’s status endpoint only when that list cannot answer on its own. If either is unreachable it fails closed — it reports the check as unavailable rather than calling the statement live. Checking whether a delegation was revoked means contacting Proof. If we are unreachable, the verifier says so instead of guessing.

API reference

Where a statement can live

Three places, named in advance.

A statement is structured data, not a badge, so it has to sit somewhere a reader can find without being told. These are the places a reader is expected to look.

The server card’s own metadata

holdings.proof/delegation

A key under the card’s `_meta` object, carrying the signed token.

The registry entry’s publisher block

io.modelcontextprotocol.registry/publisher-provided

The slot a registry publisher controls, with the same key nested inside it.

A declared capability extension, on an A2A agent card

https://proof.holdings/delegation

An entry in `capabilities.extensions` identified by that URI. This is the slot for an A2A agent card, which has no `_meta` object of its own — an MCP server card uses one of the two above.

The boundary

One fact, stated precisely.

What a reader learns

That a domain, proven at signing time, authorized this named artifact for a listed set of capabilities — and that the statement has not been revoked. A reader who already knows which domain to expect learns whether that domain is the one that signed.

What a reader does not learn

Nothing about the code, the maintainers or the quality of the artifact. We do not read anyone’s code and we publish no judgement about anybody. An absent statement is an absent statement — most name collisions are ordinary, and plenty of good software has never published anything.

Where “not found” was looked for

Only in the three places listed above. An answer of “none found” that does not say where it looked is worth nothing, so the places are always named with the answer.

FAQ

Frequently asked questions.

Does this prove the MCP server is safe?

No, and it is not meant to. A delegation is a statement about authority, not about quality: it says a domain authorized this artifact for a listed set of capabilities. It says nothing about what the code does, and we make no judgement about any artifact or the people behind it.

How is this different from signed builds or provenance?

Provenance answers “did this artifact come from the pipeline it claims?” A delegation answers “did the company whose name is on it authorize it?” Both can be true, either can be true alone, and a build signature from an unrelated publisher is still a build signature.

What happens when I revoke?

Revoking one statement leaves the domain proof and every other statement intact, and the revocation reaches any verifier reading the published status list within about a minute. Statements also carry an expiry, so a forgotten one lapses on its own.

Can somebody sign a statement naming my package?

Any domain owner can sign a statement naming any artifact — which is exactly why a verification is only meaningful against the domain you were looking for. Checking a token without pinning the domain you expected tells you that some domain said something; pinning it is what makes the answer about you.

Does a verifier have to call your API?

It reaches our infrastructure at more than one point, and it is worth being exact about which. For the signature, the reference verifier fetches the issuer’s published keys over the network and checks the card you already fetched against them — that key fetch is a live call too, not a bundled certificate. For revocation, by default, the verifier reads the published status list first; only when that list cannot answer on its own does it also ask the issuer’s status endpoint. Either way it fails closed if it cannot get an answer. Turning the revocation check off entirely is possible and means revocation was not checked — which is not the same as knowing nothing was revoked.

Sign for what you actually shipped.

Start with the domain you already stand behind. The first statement takes minutes, and anyone can check it without an account.