Questions MCP operators actually ask

Because the question you cannot currently answer is costing you time, and you are answering it by hand.

An MCP server tells a client what it can do. It does not tell anyone who operates it, under what authority, with what evidence, or whether any of that is still true this morning. Today you answer those questions in security questionnaires, in procurement calls, in an email thread with a PDF attached. Every enterprise asks separately, and every answer goes stale the moment you send it.

Publishing a resolvable identity replaces that with a URL. A reviewer opens it. A pipeline resolves it. An agent asks the Trust MCP Server about it. They get a dated, structured answer — including, honestly, the parts that are empty — without contacting you and without waiting for you.

The second reason is narrower and matters more over time: agents are increasingly the thing on the other side of your endpoint, and an agent cannot read your website's About page. It can resolve an identifier.

What this does not do is win you the work. It makes verification possible; the decision stays entirely with the person making it.

No. Nothing in this touches your server's code, its transport, its tool schemas, its auth, or its behaviour.

The identity lives on a record held elsewhere. What you publish is a reference — an identifier and a URL — on surfaces you already control: a page on your own site, your README, a file under /.well-known/ on the host that serves your endpoint, and the websiteUrl in whatever server.json you publish.

You can optionally include the identifier in your server's own initialize response. That is a convenience for hosts that surface it, not a proof step: a relying party still resolves the identifier out of band, because a string your server says about itself is an assertion by your server, and the record is what gets checked.

There is no approval process. 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.

The sequence is: your order automatically starts account setup, setup completes, and your included Passport access activates automatically. Your live ECZ-ID profile becomes available through Resolver after activation. The period starts at activation, not at purchase — an attempted or failed payment starts nothing.

The step that takes you any time at all is the one you perform: publishing the reference. That is editing a page, a README and a file.

A parent ECZ-ID for your organisation — a persistent identifier of the form ECZ-GB-RBS1NW — and a public Resolver page it resolves to, for people (https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW) and for machines (https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json).

Optionally, a child passport for the specific thing you operate, issued under that parent: an API Passport for an endpoint, an Agent Credential for an agent, a Software Supply Chain Passport for your build chain, and so on. A child always resolves back to an accountable parent, which is the point of the model.

On the record: your identity fields with the basis of each one visible, a lifecycle state, a reliance level, a binding state, evidence and ledger receipt states, and seven independent current-state axes. Empty fields are shown as empty rather than omitted.

Yes, and we would rather you did.

Open our own record first: https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW. That is the real projection of the company publishing this page, in whatever state it is actually in.

Then run the ECZ-ID MCP Verifier against anything you like, including us and including your competitors: npx @ecocitizenz/ecz-id-mcp-verifier check --target ECZ-GB-RBS1NW

It is free to use under the ECZ-ID Proprietary Limited-Use License, and it is local-first and read-only. It uploads no source, no secrets, no prompts and no tool payloads, and it emits no telemetry. There is no paid checkout for the Verifier and there never has been.

The parent record identifies an operating organisation, and the profile carries fields such as entity type and jurisdiction. A sole trader can hold one; those fields simply say what is true rather than describing a limited company.

Be aware of the honest trade-off before you start. A record's usefulness comes from what a reader can check on it, and several of the strongest fields — the externally referenced ones such as legal name, company registration number and registered address — come from a company register. Without those, a reader gets a resolvable, dated, self-declared record. That is more than nothing and it is clearly labelled as self-declared, but it is not the same thing, and we are not going to pretend otherwise.

No. It is not certification, not approval, not accreditation, not a compliance finding and not a security assessment. We are not a certification authority and we do not act as one.

Concretely, none of these is true of a record: it does not say your server is safe, it does not say your implementation is correct, it does not say you are compliant with anything, and it does not say anyone should work with you. The record itself publishes a list of things a reader must not infer from it, and that list includes safety, compliance, regulatory approval, insurance and business quality.

What it is: a neutral, resolver-verifiable identity, authority, evidence and current-state layer. It lets a reader check specific things for themselves and see what has actually been checked. A Resolver page does not prove compliance, and it does not make its holder the right choice.

There is also no score. We are not a trust score provider, and there is no rating, no grade, no tier badge and no percentage. The record publishes seven independent current-state axes precisely so that nobody collapses them into a single number — a number would hide the thing a reader needs, which is which specific field is empty.

No, to all three, and none of the surfaces involved is capable of it.

ECZ-ID is not an MCP security scanner. It does not sit in the execution path and it does not allow or block actions. There is no proxy, no gateway, no agent installed on your infrastructure and no inbound connection from us to you.

The ECZ-ID MCP Verifier, which is what a relying party runs, is explicit about its own scope: it does not inspect the artifact contents, manifests or runtime protocol of any target. It classifies a target with regex, and for a valid ECZ-ID it performs a read-only GET against the public machine projection. That is the entire network behaviour. It uploads no source code, no secrets, no API keys, no prompts and no tool payloads, and it emits no telemetry, analytics or beacons.

The Trust MCP Server answers questions about records. It has no knowledge of your endpoint, your tools or your traffic.

No. It is out of band, and there is no code path in which your server participates.

Verification happens between the relying party and the Resolver. They resolve your identifier against resolver.ecocitizenz.org or api.ecocitizenz.com — not against you. Your server is not called, not proxied, not polled and not measured. Add up the request-time cost and it is zero milliseconds and zero additional dependencies, because nothing was added to your request path.

The only artefacts on your side are static: a page, a README line, and a small file under /.well-known/. If you also choose to include the identifier in your own initialize response, that is a few bytes in a response you already send.

This is the practical argument for keeping identity out of band rather than in the protocol. A trust layer that made every call slower would not survive contact with production, and it would put us in your availability path, where we have no business being.

Nothing stops them creating a record and typing your name into it. We are not going to claim otherwise, because it would not be true and you would find out.

What the system does instead is make that claim weak, checkable and traceable rather than invisible and strong. Five things do the work, and it is worth understanding each, because the fifth is the one that actually protects you.

One. Self-declared fields are labelled as self-declared. The record separates Verified, Self-declared, Bound and Referenced information, and a reader can always tell which is which. An impostor's typed-in company name renders as a declaration, not as a check.

Two. The record itself tells readers not to infer identity from it. legal_name appears in the published do_not_infer list on every ECZ-ID. A reader is instructed, by the record, not to conclude that the legal name on it is established. Where a legal name is externally referenced, it carries its provenance — the source, the source identifier and the date it was checked. Ours says Companies House, 17348848, checked 2026-07-31. An impostor cannot produce that for your company number without it pointing at you.

Three. Control cannot be faked into the binding fields. Binding means control over a named thing — a domain, an API, a repository, a wallet, an asset — was demonstrated and can be publicly proven. A record with no demonstrated control publishes binding.state = NO_PUBLIC_PROOF with an empty scopes list and an explicit do_not_infer_control_over list naming domain_control, api_control, repository_control, wallet_control and asset_control. An impostor cannot bind your domain, because binding requires demonstrating control of it.

Four. Contradiction has a name and a consequence. MISMATCH is a canonical result state, and MISMATCH is one of the states machines are told to fail closed on, alongside REVOKED, SUSPENDED, DEGRADED and ACTIVE_ABUSE_FLAGGED. A record whose claims conflict with what a relying party observes does not resolve as neutral; it resolves as a problem. There is also a neutral Request-to-Resolve mechanism — the single write-capable tool on the Trust MCP Server, protected by OAuth2 — which is how a disputed or unresolved claim is raised as a record rather than as an email.

Five, and this is the important one. Direction of discovery. A relying party does not search for you in a directory and hope they picked the right entry — there is no directory, and the Resolver is explicitly not a directory. They arrive at your identifier from a surface you already control: your domain, your README, your registry entry, your contract. An impostor's record has no path from your surfaces to itself. That is why step 3 of the journey is the one you perform, and why publishing the reference in the places you actually own is not administrative tidying — it is the anti-impersonation property of the whole design.

The honest limit: this makes impersonation harder to sustain and easier to expose. It does not prevent someone lying, and no identity layer can. It moves the lie into a place where checking it is cheap.

You update them, and the projection follows. That is the difference between a record and a PDF.

You control the optional profile information and the bindings, and you manage them through TrustOps. ECZ-ID Backend/Core writes the authoritative state; the public Resolver renders a read-only projection of what that state permits. This website is not involved at any point in that loop.

Different fields change differently, and the record shows which is which. Fields you declare — trading name, contact address, sector, activity summary — you edit. Fields that are externally referenced — legal name, company registration number, registered address, incorporation date — change at the source and carry the date they were checked. Referenced information is only ever as current as the source it points at, and the record says so rather than implying freshness it does not have.

Bigger changes have their own shape. A new MCP surface or a new agent is a new child passport under the same parent. An endpoint that moves or retires is a lifecycle change. Ceasing to operate moves the lifecycle state, and REVOKED and SUSPENDED are visible to every relying party immediately, because they re-check at the moment of reliance rather than trusting a cached document.

The honest warning: a reference that resolves to a stale record is worse than no reference, because it is confidently wrong. Maintaining the record is the work. The ongoing TrustOps packages exist for operators who would rather not do that maintenance themselves.

The Resolver page is public. Anyone with the identifier — or with a link to it — can open it, and so can any machine. That is the entire point: a record only nominated people could read would not help the reviewer you have never met.

What is public is what your canonical state permits, and you control a great deal of that. Optional profile information and bindings are managed by you through TrustOps. Some sensitive fields are published only with explicit per-field consent: on our own record, company_registration_number, registered_address and incorporation_date each carry an explicit publication_consent flag. Consent is per field, not all-or-nothing.

What is not public: the confidential Production Evidence Pack from a paid engagement goes to you and stays with you. The Resolver page is an adjunct to it, never a replacement for it. The evidence pack is what your engineers read; the Resolver page is what you can point others at.

What we do not see, ever: your source, your secrets, your prompts, your tool payloads and your traffic. Nothing in this collects them, and the tools involved are documented as not collecting them.

One thing worth deciding before you start: your record is a public statement about your business, and it will be read by people you did not choose. Fill it in with that in mind. It is also as complete and as useful as the information and bindings you choose to maintain — it does not claim to contain everything about your business.

No, and we will not list you.

The Resolver performs intentional resolution of an ECZ-ID. It is explicitly not a directory: arbitrary URLs, repositories, packages, container images and MCP server URLs are not resolvable, and there is no browse view, no ranking and no featured tier. You cannot look up MCP servers and find a list, and neither can anyone else.

That is a deliberate constraint rather than a missing feature: a directory ranks, and ranking is an opinion about who is better. This layer does not hold opinions about who is better; it lets a reader check specific things about a party they already have a reason to be checking.

No. It is designed to work alongside your existing identity provider, gateway, API authorisation, logging and security controls, all of which remain essential sources of operational truth.

ECZ-ID is not an identity provider, not a gateway and not a firewall. It does not authenticate anyone into anything, it does not issue access tokens for your systems, and it does not sit in the execution path. Your OAuth server still authorises calls. Your gateway still enforces policy. Your logs are still your logs.

What it adds is the layer none of those produce: an independently resolvable statement of who operates a thing and what evidence is currently published about it, readable by a party who has no access to any of your systems.

Three things, all on their side, none requiring anything from you at the time.

A reviewer opens the human Resolver URL during diligence and reads the record, including which fields are empty and when each was checked.

A platform team adds the ECZ-ID MCP Verifier's GitHub Action to a pipeline with a local policy of OPEN, PREFER or REQUIRE, and gets a deterministic result state and exit code. The policy is theirs. Nothing about your record forces an outcome in their pipeline — a team running REQUIRE may decline a server with no public proof, and a team running OPEN may simply record the posture.

An agent calls the Trust MCP Server over JSON-RPC and asks resolve_identity or get_current_state. The contract requires the answer to carry the canonical state, when it was checked, a proof link, a re-check action and a local-policy caveat — and it never asserts safety, approval or compliance.

Worth knowing: the verifier has 18 canonical result states and deliberately no state called FAILED_VERIFICATION. A target with no public proof returns NO_PUBLIC_RESOLVER_PROOF_FOUND. Absence of proof is reported as absence, never rendered as failure and never as unsafe. That protects you while your record is still filling up, and it protects operators who have no record at all from being described as dangerous.

Because we left it visible, and linked to it from the top of the page.

NO_PUBLIC_PROOF is the correct value for a record where control over a named thing has not yet been demonstrated and publicly proven. It is not an error and it is not a failure state — it is not among the states machines are told to fail closed on. A brand-new record says the same thing, and so does ours, with reason_code NO_PUBLIC_BINDING_PROOF_AVAILABLE and an empty scopes list.

The alternative would have been to render our own record more flatteringly than yours. A layer that did that would be worthless, and you would have no way to tell until it mattered. Open it and check: https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW