Public verification
Verify an MCP server before you rely on it.
Who operates this server, what state is published about it, and what that record explicitly does not establish — answered by the surfaces that hold the record, not by this page.
Public Resolver reads and public machine-readable records are never metered, never authenticated and never counted against any allowance. An ECZ-ID matches ^ECZ(-[A-Z0-9]{2,32}){1,4}$, and a real one to try is ECZ-GB-RBS1NW.
How to verify
Four real ways to verify — none of them on this page.
This website does not verify anything. It has no lookup box and it never will, because a page on this site has no authority to tell you what is true about someone else. Here are the four surfaces that do, and what each one is actually for.
You have a server URL, a package or a repository, and you are at a keyboard.
ECZ-ID MCP Verifier — CI and CLI surface
npx -y @ecocitizenz/ecz-id-mcp-verifier --target <target>
You want the check to run on every pull request rather than when someone remembers.
ECZ-ID MCP Verifier — GitHub Action surface
Policy OPEN, PREFER or REQUIRE. Outputs result-state, reason-codes and an action envelope your workflow can branch on.
You are an agent, or you are building one, and the check has to happen mid-conversation.
Trust MCP Server — machine surface
Call resolve_identity over Streamable HTTP. Six of the seven tools are anonymous and read-only.
You already have an ECZ-ID and you just want to read the record.
ECZ-ID Resolver — proof surface
Open the canonical URL and match the identifier format ^ECZ(-[A-Z0-9]{2,32}){1,4}$. No account, no key, no rate limit to negotiate.
If a target has no public ECZ-ID record, every one of those four surfaces reports exactly that and stops. Absence of a record is reported as absence. It is not rendered as failure, risk, or a reason to distrust anyone — which is why there is no FAILED_VERIFICATION state anywhere in the ECZ-ID MCP Verifier.
How to read a record
What each field supports — and what it does not.
The second column is the one that matters. Most bad conclusions come from reading a field as stronger evidence than it is.
| Field | What it tells you | What it does not |
|---|---|---|
| parent | Which organisation operates this MCP server, and whether that organisation has been independently checked. | It does not mean the server was checked. A verified organisation can operate an MCP server nobody has examined. |
| record_type | Which kind of subject this identifier is for — MCP_PASSPORT for one logical MCP server, ECZ_ID_PARENT for the organisation. | It does not describe an endpoint, a deployment or a URL. The subject is the logical server, not the address it happens to answer on today. |
| lifecycle_state | The state published for this identity right now, with the time it was read. | ACTIVE describes the record, not the server's behaviour, its tool surface, its permissions, or whether it is running. |
| reliance.can_rely_on | The short list of things this record is good evidence for. Four items on the parent record shown on this site. | It is not everything a reader might want. Anything absent from the list is unanswered by the record, not answered negatively. |
| reliance.do_not_infer | The list of things this record explicitly does not establish — thirteen items on the parent record, unedited and unreordered. | Skipping it is how people invent claims the record never made. It is the most useful field on the page. |
| is_proof | Always false. | The Resolver never presents itself as a verdict. It publishes evidence for you to weigh under your own policy. |
Reading it correctly
Four rules that stop a record being over-read.
An absent record is not a finding
No public ECZ-ID Passport found is not a safety finding. It means the identifier resolves to no published record — nothing more. Most MCP servers have no ECZ-ID yet.
A record is not a verdict
The record is not proof. It publishes what is currently declared and what evidence exists, with the time it was read. Re-check the live record before you rely on it.
Organisation checked, server not
A VERIFIED or ASSURED Parent does not verify the MCP server. The parent organisation's identity is verified. The endpoint is not. A server linked to a VERIFIED Parent is described exactly that way — linked to a VERIFIED Parent — never as a verified MCP server.
Declared is a statement, not a check
DECLARED does not mean independently verified. It records what an organisation says about itself, with the date it said it — not the outcome of a check.
A badge, a QR code, a screenshot or a card is a pointer to a record, not the record. Only the live Resolver is current. Re-check before reliance. State can change between the moment a badge is drawn and the moment a client connects.
ECZ-ID tells you what is published and by whom. What that is worth in your context is your policy's decision, never ours.
An MCP Passport is not ECZ-ID MCP Assurance. The Passport is identity: who this server is, who operates it, and what is published about it. Assurance is separate, ongoing work performed on evidence, with its own scope and its own price.
The other side of the check
Someone is going to look yours up too.
If you operate an MCP server, publishing a record is what makes this check possible in the other direction. It is free, permanent, and it takes one sign-in.