Skip to content
ECZ-ID Agents
Free Passport

Agents and MCP

An agent and the MCP server it calls are two different subjects.

One decided to make the call. The other answered it. They are frequently run by different organisations, and even when they are not, they answer different questions — so each holds its own identity, with its own operator on the record.

Public Resolver reads and public machine-readable records are never metered, never authenticated and never counted against any allowance.

Two subjects

Two records, because they answer two questions.

Publishing one identity for both would collapse the only distinction that matters when something goes wrong: which party operated which piece.

The agent

ECZ-GB-XXXXXX::AGENT_PASSPORT-YYYYYY

Who operates the thing that decided to make the call?

One logical agent, linked to the organisation that runs it. Its record says nothing about the servers it happens to call, and it should not.

The MCP server

ECZ-GB-XXXXXX::MCP_PASSPORT-YYYYYY

Who operates the thing that answered it?

One logical MCP server, linked to the organisation that runs it. Its record says nothing about which agents call it, and it should not.

The identifiers above use the placeholder form and are not real records. The type is carried inside the identifier itself, so a reader can tell an agent record from a server record before resolving either one.

Reviewing the agent and its MCP servers together?

Assure the connected agent stack rather than one component in isolation. The ECZ-ID Agentic Stack Assurance Bundle packages the evidence for an agent, the MCP servers it calls and the APIs behind them as one review. Bundling evidence does not merge the identities of the underlying entities.

See details

Subject law

One MCP Passport is one logical MCP server operated by your organisation.

Read this before you count how many Passports you need. Over-counting almost always comes from treating a tool, an endpoint or a deployment as a subject in its own right — which splits one server across several records and leaves a reader unsure which one is the server.

One Passport each

  • One logical MCP server

    The thing you would name in a sentence when you tell someone what you run. That is the subject, and it gets one permanent identifier.

  • A genuinely different server

    A second server with a different purpose, a different team behind it or a different operator is a different subject. It gets its own Passport and its own record.

Not a separate Passport

  • The tools inside the server

    A server exposing forty tools is one server. Tools are a surface of the thing, not forty separate things your organisation operates.

  • The endpoints it answers on

    Several endpoints, transports or hostnames pointing at one logical server are bindings of that server, not additional identities.

  • Deployments, replicas and regions

    Running the same server in three regions behind a load balancer does not make three servers. It is one subject, deployed three times.

  • Versions and releases

    A new release of the same server keeps the same identity. The ECZ-ID is the thing that survives the version number, which is most of its usefulness.

One Agent Passport is one logical AI agent operated by your organisation. The MCP family works the same way: the server is the subject, and its endpoints are bindings of it. Bindings, versions, replicas, endpoints and deployments never consume AEC and never become a second Passport. Identity is free. A Passport is never metered, and issuing one consults no entitlement.

Before you wire it in

Four steps, and the two that stop you over-reading the result.

A server you are about to hand tool calls to is a party in your system. Resolving its identity tells you who that party is — and, just as usefully, what the record refuses to claim about it.

  1. Ask for the ECZ-ID

    It is a short string the operator can publish anywhere — documentation, a manifest, a repository, a listing. If there is not one, that is the end of this route, not a verdict.

  2. Resolve it yourself

    Open the public record. No account, no API key, no login, and nothing recorded against you for looking.

  3. Read the operator, not the colour

    The record names the organisation that stands behind the server, and says whether that organisation has been independently verified. That is the field worth your attention.

  4. Read what it does not establish

    Every record lists what it does not establish. That list is what stops a reader inventing a claim the record never made.

No record is not a finding

No public ECZ-ID Passport found is not a safety finding. It means this identifier resolves to no published record — nothing more. Most software has no ECZ-ID yet.

A record is evidence, 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. Re-check before reliance. State can change between the moment a badge is drawn and the moment an agent acts.

The organisation is the subject of verification

A VERIFIED or ASSURED Parent does not verify the agent. The parent organisation's identity is verified. The machine is not. An agent linked to a VERIFIED Parent is described exactly that way — linked to a VERIFIED Parent — never as a verified agent. The same rule applies to an MCP server.

The decision stays yours

ECZ-ID tells you what is published and by whom. What that is worth in your context is your policy's decision, not ours.

Resolve an ECZ-ID now

Agents and MCP

Does your agent use an MCP server?

An agent and the MCP server it calls 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.

You use someone else’s MCP server

Look it up before you wire it in. If it publishes an ECZ-ID you can see who operates it and what state the record is in; what you do with that is your policy. If it does not, that is not a finding against it — most servers have no ECZ-ID yet.

Look up an MCP server

You operate the MCP server yourself

Give it its own FREE MCP Passport. Same organisation, same Parent, a separate identity for a separate thing, with its own operator on the record.

Get a FREE MCP Passport

Adjacent Passports are suggested, never issued for you. If your agent also exposes an MCP server or an API, you choose whether to give those an identity too.

If you operate the server

A FREE MCP Passport, for the server you operate.

£0. No card required. Permanent, and issued only if you ask for it.

A permanent identifier for the server

One ECZ-ID for one logical MCP server, published against the organisation that operates it. It does not change if your capacity, your tier or your hosting does.

Endpoints are bindings, not Passports

Several endpoints, transports or hostnames for one logical server are recorded as bindings of that server. They never become a second Passport, and public reads of the record are never counted against anything.

The same public record shape

A human page and a machine-readable record at stable addresses, readable by a counterparty who has no account with you and no access to your infrastructure.

Adjacent Passports are suggested, never issued for you. If your agent also exposes an MCP server or an API, you choose whether to give those an identity too. An MCP Passport is a separate door, taken with a separate click, and holding an Agent Passport neither creates one nor obliges you to.

Get a FREE MCP PassportThe MCP category property(opens in a new tab — mcp.ecocitizenz.com)

Where next

Where next.

Get a FREE Agent Passport

£0 · No card required · Permanent, not a trial.