Give the MCP server you operate a resolvable identity.

Owned by: TrustOps for acquisition and entitlement. ECZ-ID Backend/Core creates and activates the record and writes the canonical state. This website explains and routes.

An MCP server does not have a company. The organisation that operates it does. So the first thing that exists is a parent identity for that organisation: the ECZ-ID Business Passport. It is your organisation's persistent identity foundation and the spine every downstream credential resolves back to.

Every paid MCP service includes a 90-day ECZ-ID Business Passport experience: a machine-readable business profile for the emerging agent and machine economy, with a public Resolver page that people and software can read for themselves.

How the included Passport reaches you

1. Purchase

   Your order automatically starts account setup. There is nothing to apply for and no approval step — setup begins on its own.

2. Activation

   When setup completes, your included Passport access activates automatically.

3. 90-day access

   Your included 90-day period starts at activation. There is no automatic renewal and no automatic charge at day 91 — continuing is a separate decision you make.

4. Resolver profile

   Your live ECZ-ID profile becomes available through Resolver after activation. You control what it says — optional profile information and bindings are managed by you through TrustOps.

There is no gate. Getting the included Passport is frictionless: no eligibility assessment, no qualification, no identity verification and no approval step stands between a successful purchase and an active entitlement.

Which is exactly why holding one proves very little on its own. Payment does not create Declared, Verified, Assured or BOUND status, and does not make anything approved, compliant or safe. Paying does not verify, certify, assure or approve you or your MCP implementation. What you get is a record that exists, resolves, and can start carrying evidence.

Start a Business Passport on TrustOps (external) →

Owned by: you, on your own infrastructure. The ECZ-ID Resolver serves the URL when someone follows it. Nothing is written, registered or submitted to us by publishing a reference.

A record nobody can find is a record nobody uses. Publishing the reference is the step that turns an ECZ-ID from something you hold into something a relying party can act on — and it is entirely under your control, on surfaces you already own.

There is nothing to submit. You are not adding yourself to a directory, and there is no listing to be accepted into. You are publishing a string and a URL, the same way you publish a licence or a security contact.

The four URL shapes

Parent, for people

https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW

The URL a reviewer, an auditor or a customer opens.

Parent, for machines

https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json

The read-only machine projection an automated client fetches.

Child, for people

https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW/API/4F9Q2A

The external child form decomposes: parent, then passport code, then instance suffix — as path segments, never a percent-encoded child identifier.

Child, for machines

There is no documented public child machine endpoint. The ECZ-ID MCP Verifier deliberately does not fabricate one; it returns a human URL for a child and reports the machine projection as unproven rather than inventing a path. Where a machine needs a child, it resolves the parent machine JSON and reads the child representation from inside that body.

The four Resolver URL shapes: parent for people, parent for machines, child for people, and the child machine projection, which has no documented public endpoint.

Where to publish it

1. 1. Your own site, on a page that does not move

   Why: It is the reference a human follows from an email, a questionnaire or a contract, and it is the one that has to still work in two years.

   Example: A /trust or /security page carrying the identifier as text and the human Resolver URL as a link. Text, not an image — an identifier inside a PNG is not machine-readable and not copy-pasteable.

2. 2. Your repository README

   Why: For an open-source MCP server this is where a developer looks first, and it is the surface a reviewer screenshots.

   Example: A short line near the top — Operator identity: ECZ-GB-RBS1NW · https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW — as plain text or a markdown link. If you use a badge, keep the identifier as text as well: a badge image asserts nothing and cannot be resolved.

3. 3. A .well-known file on the host that serves your MCP endpoint

   Why: This is the machine-facing placement, and it is the shape the ECZ-ID MCP Verifier already recognises. A target URL ending in /.well-known/ecz-mcp.json is classified as an MCP server target by the verifier's deterministic classifier.

   Example: https://api.example.com/.well-known/ecz-mcp.json — with the honest limit stated below, in full.

   The honest limit on a .well-known file

   What the verifier does with that file today, precisely: it recognises the URL shape and classifies the target as an MCP server. It does not fetch the file, parse it, or read an identifier out of it — the ECZ-ID MCP Verifier does not inspect the contents, manifests or runtime protocol of any target, by design. A public Resolver lookup runs only for a valid ECZ-ID.

   So the file is a durable, machine-findable place to keep your identifier for humans, crawlers and your own tooling. It is not yet an automatic discovery path into the Verifier. Publish the identifier itself wherever a relying party will actually read it, and expect them to resolve the identifier rather than the file.

4. 4. Your MCP registry entry

   Why: It travels with your server to anyone who discovers you through a registry rather than through you.

   Example: In the server.json you publish, point websiteUrl at the page from placement 1 — the page that carries your identifier and your Resolver link. No other field is named here, because no other field is confirmed.

5. 5. Your MCP server's own initialize response, if you want it in band

   Why: Some hosts will surface it; most will not read it.

   Example: Putting the identifier in your protocol response is a convenience, not a proof step. A relying party still resolves it out of band. A string your server returns about itself is an assertion by your server; the Resolver record is what gets checked.

What a relying party does with the reference

They take the identifier — not your domain, not your package name, not your repository — and resolve it. A person opens the human URL. A machine fetches the parent machine JSON, or asks the Trust MCP Server, or runs the ECZ-ID MCP Verifier in their pipeline. In every case the answer comes from the Resolver, not from you, and it is dated at the moment they asked.

That last part is the reason to publish a reference instead of a document. A PDF says what was true when it was written. A reference says what is true when it is followed.

Owned by: the relying party. They resolve your reference, on their schedule, under their own policy. Neither this website nor any ECZ-ID surface decides what they conclude.

At the end of the four steps above, something specific is true: a person or a machine on the other side of an integration can now ask a question about you and get a dated, structured, re-checkable answer, without contacting you and without waiting for you.

Here is exactly what that changes, and what it does not.

Publishing a resolvable identity makes verification possible. It does not make anyone trust you.

How useful any of that is depends on the information and bindings you maintain. A Resolver page does not prove compliance, and it does not make its holder the right choice — it lets a reader check specific things for themselves and see what has actually been checked.