Free MCP Passport · £0 · no card
Give your MCP server a persistent, resolver-verifiable identity.
A permanent ECZ-ID for one logical MCP server, linked to the organisation that operates it and published on a resolver anyone can read. It costs nothing, it never expires, and no card is involved at any point.
Identity is free. A Passport is never metered, issuing one consults no entitlement, and there is no card, no trial clock and no expiry on it.
One Passport, one server
What one Passport covers
Before you count anything, this is what a single Passport is the identity of.
- One MCP Passport is one logical MCP server operated by your organisation.
- Versions, regions, replicas and environments of that server are not separate Passports. They are deployments of one server, and they draw on your managed-endpoint allowance rather than on a second identity.
- Every MCP Passport is linked to the organisation that operates the server — its Parent. That relationship is the point: an endpoint identity with no accountable operator behind it answers nothing worth asking.
Two records, one relationship: the MCP Passport identifies the server, and the ECZ-ID Business Passport identifies the organisation that operates it. The Business Passport is the Parent; the MCP Passport is the child that points at it.
Included
Everything the free Passport gives you.
Eleven things, none of them a trial and none of them removed later. Each one is granted by a frozen contract; nothing is listed here that this property cannot point at.
- A permanent ECZ-IDOne persistent identifier for the server. It does not change when you add capacity, move down a tier, let something lapse or cancel.
- An operator relationshipThe server is published against the organisation that runs it, so the record answers who is accountable and not only what the endpoint is called.
- A free DECLARED Parent if you need oneIf your organisation has no ECZ-ID yet, a DECLARED Parent is created during the same flow at no charge. If you already have one, it is reused rather than duplicated.
- A public Resolver recordA human-readable page anyone can open without an account, an API key or a login. Nothing about reading it is metered.
- A machine-readable recordThe same record as JSON on a stable schema, for policy engines, gateways, clients and other agents deciding what to do before they connect.
- Current public stateLifecycle state and the time it was read, published on the record itself rather than asserted in a badge image.
- A badge and a QR codeDrawn by the badge service from the record's current state, so a stale copy cannot be pinned to a README and left there.
- The Publish KitThe share link, the machine URL, the badge and the embed for your repository or server manifest, in one place.
- Capacity you do not have to buy to hold the identityThe Passport exists and resolves whether or not you use any AEC — ECZ-ID Active Entity Capacity. AEC is the capacity to actively MANAGE entities in production, it is one pool across your whole estate, and it never makes an identity more verified.
- Re-check on demandCurrent state is evaluated when someone actually asks — opening the record, re-checking from the Publish Kit — rather than on a schedule you did not ask for.
- Adjacent Passport discoveryIf the thing you operate is also an agent, an API, an SDK or a workload, the flow tells you those can have identities too. You choose. Nothing is issued for you.
What never consumes Active Entity Capacity
- The number of tools inside a server never consumes capacity.
- Ephemeral replicas never consume capacity.
- Someone verifying your public record never consumes capacity.
The number of tools your server exposes never consumes capacity, ephemeral replicas never consume any, and public verification of your record never consumes any.
Boundaries
And exactly what it is not.
These sit here, next to the offer, rather than in a legal page. A reader deciding whether to publish an identity for their server needs the limits in the same eyeline as the benefits.
It is not a verification of your server
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.
It inspects nothing
Holding a Passport inspects nothing. It does not probe your endpoint, read your configuration or execute anything, and it reports no finding about the server it names.
It is not a certification
There is no scheme, no seal and no approval to be granted. An ECZ-ID makes a server identifiable and re-checkable, never approved.
A DECLARED Parent is not a checked one
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.
An ECZ-ID does not make an MCP server safe, certified, approved or compliant, and holding one does not make you compliant with anything. ECZ-ID tells you what is published and by whom. What that is worth in your context is your policy's decision, never ours.
What you walk away with
A public record anyone can resolve, and re-check.
Two addresses, both public, neither needing an account or an API key. One for people, one for machines. Reading either is never metered.
For people
resolver.ecocitizenz.org/p/ECZ-GB-XXXXXX::MCP_PASSPORT-YYYYYY
A readable page: the server, its operator, current state, and what the record does not establish.
For machines
api.ecocitizenz.com/api/p/ECZ-GB-XXXXXX::MCP_PASSPORT-YYYYYY.json
The same record as JSON on a stable schema, for gateways, policy engines, clients and other agents.
What the record carries
Example values
- ecz_id
ECZ-GB-XXXXXX::MCP_PASSPORT-YYYYYY
The server's permanent identifier. The type is inside the identifier.
- record_type
MCP_PASSPORT
One of seven canonical record types, derived from the identifier itself.
- identifier_kind
mcp_endpoint
What the declared identifier is. For this family, an endpoint.
- parent
{ ecz_id, parent_tier, independently_verified, tier_meaning }
The operator, and whether the ORGANISATION has been independently verified. Never the server.
- lifecycle_state
ACTIVE
Current published state, with as_of alongside it.
- public_bindings
[ { locator_class, locator, provenance } ]
What this server is declared to be, and how that was established.
- is_proof
false
The Resolver says so itself. The record is evidence to weigh, never a verdict.
- recheck_before_reliance
true
Always present. State can change after you read it.
- do_not_infer
[ safety, compliance, certification, mcp_assurance, … ]
The things this record explicitly does not establish. Read it before you decide anything.
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.
Re-check before reliance. State can change between the moment a badge is drawn and the moment a client connects.
Example identifiers on this page use the placeholder form ECZ-GB-XXXXXX::MCP_PASSPORT-YYYYYY and are not real records.
Endpoint, and identity
Your MCP server already has an endpoint. An ECZ-ID gives it an identity that outlives the endpoint.
An endpoint is an address. It tells a client where to connect, and nothing about who is behind it or whether this is still the same server it was last quarter. Addresses also move: a host migrates, a URL is retired, a deployment is replaced — and every reference anyone held to it quietly stops meaning what it meant. An ECZ-ID names the server itself, so the address becomes something the identity has rather than something it depends on.
What MCP gives you
The protocol does the connection work, and does it well.
- An address a client can be pointed at.
- A transport, and a session with it.
- A tool and capability surface the client can enumerate.
- Its own authentication and authorisation on that connection.
What an ECZ-ID adds
None of these is something the protocol sets out to answer.
- A persistent logical identity for the server, not for one address.
- The operator relationship — the organisation accountable for it.
- A public Resolver record anyone can open without an account.
- Machine-readable current public state, on a stable schema.
- Bindings: the endpoints, repositories and deployments claimed under it.
- Published evidence, and the date each piece of it was established.
- A re-check, at the moment someone actually needs one.
ECZ-ID works alongside the MCP specification, your transport, your OAuth and your native IAM. It does not replace any of them and it changes nothing about how a client connects.
ECZ-ID stays outside the execution path. It does not broker a client's calls, hold your credentials, or sit between a client and the server it is pointed at.
One Passport. Many bindings.
The enduring logical MCP server is the subject. Everything else attaches to it — which is why replacing a deployment or moving a host does not cost you an identity, and does not cost anyone else the reference they already hold.
MCP Passport
One enduring logical MCP server
- ECZ-IDThe permanent identifier for this logical server. (Identity)
- Operator — the ParentThe organisation accountable for running it. (Identity)
- Endpoint AAn address the server answers on today. (Binding)
- Endpoint BAnother address, or the one that replaces the first. (Binding)
- RepositoryWhere the source is declared to live, where that is claimed. (Binding)
- DeploymentAn environment or region under management. (Binding)
- Public evidenceWhat has been established, and when it was established. (Evidence)
Related, and separate
- Agent relationshipsAgents that call it. A separate subject, with its own Passport and its own operator — never folded into this one.
- API relationshipsAn API surface the same organisation operates, if there is one. Also a separate family.
One MCP Passport is one logical MCP server operated by your organisation.
Versions, regions, replicas and environments of that server are not separate Passports. They are deployments of one server, and they draw on your managed-endpoint allowance rather than on a second identity.
Endpoints, deployments and versions are normally bindings and evidence under one Passport, not Passports of their own. That is what stops an estate of forty deployments becoming forty identities nobody can reconcile.
What happens when something encounters it
This is the sequence an agent, a platform or a reviewer actually runs. Every step is something they do, and the last one is theirs alone.
- 01An agent or platform encounters the MCP serverIt has an address, and a reason to connect to it.
- 02It discovers an ECZ-IDWhere the server, its manifest, its repository or its tooling exposes one.
- 03It resolves that ECZ-IDOn the public Resolver, with no account, no key and nothing metered.
- 04It reads a persistent identityThe subject is the logical server, so the record survives the address changing.
- 05It reads the operatorThe organisation accountable for it, and that organisation's tier.
- 06It reads current published stateLifecycle state, and the time that state was read.
- 07It reads whatever evidence existsBindings and their provenance — and, just as usefully, what the record explicitly does not establish.
- 08It re-checks before it relies on any of itRe-check before reliance. State can change between the moment a badge is drawn and the moment a client connects.
- 09It applies its own reliance policyECZ-ID tells you what is published and by whom. What that is worth in your context is your policy's decision, never ours.
Nothing in that sequence makes a server trusted, and no step in it grants approval. It ends where it should end: with the party taking the risk deciding what the evidence is worth to them.
Two identities, resolved independently
An agent holds an Agent Passport. The MCP server it calls holds an MCP Passport. Each resolves on its own, each names its own operator, and neither inherits anything from the other — which is the point, because they are frequently run by different organisations.
The agent
Agent Passport
One logical agent, published against the organisation operating it. Free and permanent, on its own allowance.
The MCP server
MCP Passport
One logical server, published against the organisation operating it. Free and permanent, and it resolves whether or not you use any capacity.
Resolving one tells you nothing about the other. If the same organisation operates both, that shows up because both records name the same Parent — not because either identity absorbed the other.
Where it becomes discoverable
An ECZ-ID becomes discoverable wherever compatible tooling exposes or consumes it. It is not a protocol every client already speaks, and publishing one does not make every agent on the internet aware of it — the surfaces below are the ones that read or carry it today.
- Your server's own metadataThe identifier published alongside the manifest or configuration you already ship.
- The Publish KitThe share link, machine URL, badge and embed, generated for you when the Passport is issued.
- Repository and READMEA badge drawn from current state rather than a static image that goes stale.
- CI and the command lineThe ECZ-ID MCP Verifier resolves a record from a pipeline or a terminal.
- Editor toolingECZ-ID MCP Trust reads what a workspace declares, locally, and reports it to you.
- The Resolver, directlyA human page and a machine JSON endpoint, both public and neither metered.
How it happens
Four steps, no approval step among them.
There is no eligibility assessment, no qualification, no identity check and no operator approval anywhere in this flow, because issuing a Passport consults no entitlement.
Step 1
Open the door
One link to TrustOps. There is no form on this website, no email capture and no interstitial between the button and the door.
Step 2
Sign in once
One sign-in. If your organisation has no ECZ-ID yet, a free DECLARED Parent is created in the same flow; if it has one, that Parent is reused.
Step 3
Name the server
You declare the endpoint and what to call it. That declaration is published as yours, dated, and marked as self-declared rather than checked.
Step 4
Publish and share
The ECZ-ID exists immediately, with a public Resolver page, a machine-readable record, a badge, a QR code and the Publish Kit.
MCP and agents
Does this MCP server serve an AI agent?
An MCP server and the agent that calls it are two different things, run by two parties who may not be the same. Each can hold its own identity, with its own operator on the record.
An agent you did not build calls your server
Resolve it before you decide what it may reach. If it publishes an ECZ-ID you can see who operates it and what state the record is in. If it does not, that is not a finding against it — most agents have no ECZ-ID yet.
You operate the agent yourself
Give it its own free Agent Passport. Same organisation, same Parent, a separate identity for a separate thing — on its own allowance, and taking nothing from your MCP endpoints.
The whole Agent line, explained
Adjacent Passports are suggested, never issued for you. If the thing you operate is also an agent, an API, an SDK or a workload, you choose whether to give those an identity too.
Before you go
Three sentences worth more than the offer above.
- Identity is free. A Passport is never metered, issuing one consults no entitlement, and there is no card, no trial clock and no expiry on it.
- An ECZ-ID is permanent. It does not change when you add capacity, move down a tier, let something lapse, cancel, or buy nothing at all.
- 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.
An ECZ-ID is permanent. It does not change when you add capacity, move down a tier, let something lapse, cancel, or buy nothing at all. 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.