Skip to main content

Use cases

What people who build, publish and rely on MCP servers use ECZ-ID for.

Each job below names who has it, what goes wrong without it, the steps with ECZ-ID, what serves each step — and what ECZ-ID does not do. Every step starts from the same free MCP Passport.

Get a FREE MCP Passport (continues on trustops.ecocitizenz.com)

Use case 1

Publish an MCP server to registries with an identity anyone can re-check

Who has it: MCP server providers listing a server in the MCP Registry, a marketplace or their own documentation.

A registry entry says a server exists. It does not say which organisation operates it, and every registry, marketplace and README carries its own copy of the claim, so a reader has nothing to re-check.

With ECZ-ID

  1. Get one free MCP Passport for the logical server — not one per listing, endpoint or deployment.
  2. Use the free Publish Kit for the server's well-known file and its MCP Registry listing.
  3. Bind the public places the server already appears: the registry listing, the repository, the documentation.
  4. Point readers at the live Resolver record, which anyone can open with no account.

A listing and an ECZ-ID are separate things: an ECZ-ID does not approve a listing, and a registry does not verify an operator.

What serves it

Use case 2

Decide which MCP servers your organisation allows

Who has it: Platform, security and procurement teams in organisations adopting MCP.

Teams connect agents to MCP servers faster than a review board can keep up, and an allow-list built from names and URLs drifts as servers change hands, endpoints and tools.

With ECZ-ID

  1. Ask that each server you allow resolves to an accountable operator: an MCP Passport linked to that organisation's Business Passport.
  2. Re-check each server's public posture with the free MCP Verifier, and write allow / warn / require into your own policy.
  3. For the servers you operate yourself, state posture rules under your own authority with MCP Policy, evaluated by TrustOps and exportable from your console.
  4. Follow changes on the records you rely on, and re-check before reliance; your gateway keeps enforcing.

ECZ-ID never decides for you. Local policy decides, posture rules are evaluated rather than enforced, and nothing here replaces your identity provider, gateway or firewall.

What serves it

Use case 3

Pre-check a high-risk tool call before an agent makes it

Who has it: Agent and platform builders whose agents call tools that act: payments, data changes, deployments.

An agent calls whatever tool it is pointed at. By the time anyone reads the log, the call has happened, and nobody re-checked who operates the server that exposed the tool.

With ECZ-ID

  1. Before the call, run the free MCP Verifier against the server: one canonical result state with its reason codes, from public surfaces only.
  2. With Intent Control, evaluate the proposed call against the server's authority, its Intent and your policy, and keep the EVALUATED decision with its basis.
  3. Keep the receipts the activity produces with ECZ-ID Receipts.
  4. Let your runtime decide whether to proceed.

A decision is EVALUATED unless an inline enforcement point reports mediating the call, and no public proof found is not a finding about the server.

What serves it

Use case 4

Find out who is accountable for a third-party MCP server

Who has it: Anyone relying on an MCP server they do not operate: platforms, integrators and enterprise buyers.

A server URL, a package name or a registry entry does not tell you which organisation answers for the server — or whether that has changed since you last looked.

With ECZ-ID

  1. Resolve the server's ECZ-ID on the public Resolver: its operator, the operator's Business Passport tier and the server's bindings, live.
  2. Read the same record as machine-readable JSON in your own tooling.
  3. Follow it with Free Watch, which follows up to three ECZ-IDs, or a paid Watch plan.
  4. If the server has no ECZ-ID, share resolver guidance with its operator.

A record is what an operator has published, with its tier: DECLARED is not VERIFIED, and nothing on a record says a server is safe.

What serves it

Use case 5

Move an MCP server to the current protocol and a stateless posture

Who has it: Providers whose MCP servers were built against an earlier protocol revision or a stateful session design.

A server that depends on session state or an older transport is hard to scale, hard to distribute and hard for a reviewer to reason about, and migrating it under load is where outages happen.

With ECZ-ID

  1. Run the free Config Check on the configuration you ship; nothing leaves your machine.
  2. Start with the MCP Readiness Audit: configuration, identity and session posture, stateless-readiness findings and a prioritised written report.
  3. Book the Stateless Migration Sprint: a migration plan, implementation support and verification of the migrated deployment against the agreed scope.
  4. Read the RufRoot briefing on stateless MCP before you scope it.

An engagement does not create or change an ECZ-ID, and the protocol's own specification stays the authority on what the current protocol requires.

What serves it

Use case 6

Answer a customer's MCP security and procurement review

Who has it: MCP providers selling into organisations with security questionnaires and procurement reviews.

Every customer asks the same questions about the server, its tools, its operator and its evidence, in a different format, and each answer is assembled from scratch.

With ECZ-ID

  1. Hold a free MCP Passport, so the reviewer can re-check the operator and the server on the Resolver.
  2. Assemble the server, tool, operator and security evidence once with the MCP Security & Customer Assurance Kit.
  3. Track the binding state, tool-list fingerprint and drift of production targets with an MCP Assurance plan, and export its evidence pack.
  4. Strengthen the organisation behind the server with a VERIFIED or ASSURED Business Passport where the customer asks for it.

The kit supports evidence preparation; it is not a penetration test, an independent audit or a certification, and buying it creates no ECZ-ID verification.

What serves it

Use case 7

Notice when a production MCP server changes

Who has it: Operators of production MCP servers whose tools, endpoints or bindings change between releases.

A tool set can change shape between one release and the next. Without a tracked fingerprint, a quiet change looks the same as no change — to you and to every customer relying on the server.

With ECZ-ID

  1. Hold a free MCP Passport for each production MCP server.
  2. Track each target's binding state, tool-list fingerprint and drift with MCP Assurance, or across more targets with MCP Assurance Plus.
  3. See which of your servers need attention now with PulseGuard, and keep identity and lifecycle history with LedgerCore.
  4. Let customers re-check the Resolver rather than a copy of it.

Tracking is not certification and does not verify the machine; a plan's Business Passport tier is set only when its checks pass.

What serves it

Use case 8

Review an agent and the MCP servers it calls, together

Who has it: Teams shipping agents that call their own and third-party MCP servers, and the enterprises that buy them.

An agent, the MCP servers it calls and the APIs behind them are reviewed separately, by different people, so nobody sees the path from the agent's operator to the tool that acts.

With ECZ-ID

  1. Identify each part with its own free Passport: the agent, each MCP server and the API behind it, all linked to one Business Passport.
  2. Assure the connected stack with the Agentic Stack Assurance Bundle, keeping every identity distinct.
  3. Where authorization must follow the enterprise, design it with the EMA / ID-JAG Design & Pilot.
  4. State what each part is authorised to do with ECZ-ID Intent.

Each identity stays distinct: an agent's Passport never stands in for a server's, and an assurance bundle does not verify any of them.

What serves it

Use case 9

See what the MCP servers in a developer workspace declare

Who has it: Developers who add MCP servers to their editor and agent configuration.

An MCP entry is a command, some arguments and an environment block. Nothing in the editor shows which credential-shaped variables a server is handed, or what changed since yesterday.

With ECZ-ID

  1. Install MCP Trust Community, free and local-first, with no account.
  2. Run the check: every MCP server the workspace declares is inventoried from configuration only.
  3. Re-scan to see what changed; add MCP Trust Pro only for what it adds.
  4. For a server with an ECZ-ID, re-check its live Resolver record before relying on it.

MCP Trust reads configuration and proves nothing on its own; a software subscription is not a Passport.

What serves it

Use case 10

Evidence an MCP-based service for regulated customers

Who has it: Providers whose MCP servers serve financial-sector, AI-regulated or software-supply-chain-sensitive customers.

A regulated customer must evidence its ICT suppliers, its software composition and its counterparties, and asks the MCP provider for evidence in the shape its regulator expects.

With ECZ-ID

  1. Give the server and its operator a resolvable identity with a free MCP Passport.
  2. Evidence the ICT service for DORA-regulated customers, and what is in the software you ship with SBOM.
  3. Make the counterparty relationship easier to identify with DCI.
  4. Read the EU AI Act Article 50 briefing for agent transparency.

These products support evidence; none is a regulator's approval or a compliance determination, and holding one does not make you compliant with anything.

What serves it

Every one of these starts from the free MCP Passport

Free · Permanent · No card. One logical MCP server, one Passport.

Get a FREE MCP Passport (continues on trustops.ecocitizenz.com)Every MCP product

Keep going

Where next on ECZ-ID MCP

Create free MCP Passport (continues on trustops.ecocitizenz.com)