ECZ-ID Trust MCP · The trust layer for the MCP economy
An MCP client will connect to whatever it is pointed at. ECZ-ID Trust MCP is the layer that records who operates that server, what authority has actually been bound to them, what evidence is published, and what the current state is — as a public record anyone can re-check. Your policy still decides. ECZ-ID resolves.
Neutral layer. Public resolver record. Re-check before reliance.
Websites explain. TrustOps operates. Backend truth decides. Resolver proves.
The problem
MCP made tool access easy. It did not make the operator behind a tool knowable. A client is handed a URL, a transport and a token. Nothing in the protocol says which organisation runs that endpoint, what they were authorised to do, or whether whatever was true at integration time is still true this morning.
None of that is a flaw in MCP. MCP is a protocol for connecting to tools, and it does that well. It was never designed to answer who is on the other end — which is why that answer has to live somewhere else.
The chain
The agent still decides. The client still connects. The server still answers. ECZ-ID Trust MCP is the record that runs alongside that path, resolvable by anyone, before the call or long after it.
Decides to use a capability. Holds no independent view of who provides it.
Holds the server configuration and opens the connection.
Answers. Its URL is a location, not an identity.
Records identity, authority, evidence and current state against an ECZ-ID. Writes nothing into the call.
Publishes a read-only projection of that record at one canonical URL for people and one for machines.
What a relying party actually reads — each with a current state, and each stating what it does not mean.
ECZ-ID does not sit between the client and the server. It is not a gateway, a proxy, a firewall or an execution control, it never allows or blocks a call, and removing it changes nothing about whether an MCP request succeeds. Highlighted links are the records ECZ-ID makes first-class. In most estates those relationships already exist — scattered across contracts, ticketing, identity systems and audit logs — but not as one thing an outside party can resolve.
The layer
A trust layer that will not say what it is not is just a claim. So this is the boundary, stated first, in the same place and at the same size as the proposition.
Identity · Authority · Evidence · Current state · Resolution
Five things, each a field on a published record rather than a description of one. The field paths below are the real paths in the resolver's schema 2.0 payload — the same strings a machine reads.
Who the operator is, as a published record with stated provenance rather than a line in a README.
A published legal name is an externally referenced field with a named source and a date it was checked. It is not proof that this operator controls the domain, the endpoint or the repository you are about to call.
What has actually been bound, what scopes exist, and — stated on the record itself — what control must not be read into it.
This identity has not issued an Agent Credential. Do not infer agent authority from the parent ECZ-ID.
Whether a public receipt exists, how many, and which ledger it is anchored to.
A receipt anchored on ecozledger shows that a record has not been altered since it was anchored. It does not make the thing recorded true, approved, safe or well-run.
The state now, on seven independent axes, with the time each one became effective. Not one verdict standing in for all of them.
ACTIVE means the record is currently enabled and has not been suspended, revoked, cancelled, lapsed or expired. It is not identity verification, control binding, compliance, insurance or business quality.
One canonical URL a person can open, one a machine can parse, and a fixed identifier format so neither has to guess.
The Resolver renders a read-only projection. Canonical state is held by ECZ-ID Backend/Core. A projection is never the source, and a page on this website is not a projection.
Those two lists are published on every record as machine_policy.machines_should_use and machine_policy.fail_closed_states. They are a recommendation the record makes about itself, not an instruction ECZ-ID enforces. What your system does with a fail-closed state is your policy, made by you, in your own code.
Live proof
Everything above describes a record shape. This is a real one: the ECZ-ID for the company that operates this website. What follows is a dated transcript, typed by hand and published as a quotation. It is not a live feed, and this page does not fetch it. The live record is one click away, and the live record is the only thing that counts.
Legal name, company number, incorporation date and registered office are classified on the record as externally_referenced, sourced from Companies House and checked on 31 July 2026, and published with explicit consent. That classification is the point: the record says where each field came from, so a reader never has to assume we checked it ourselves.
Active ECZ-ID. Re-verify before reliance.
reliance.can_rely_on
reliance.do_not_infer
This identity has not issued an Agent Credential. Do not infer agent authority from the parent ECZ-ID.
Read what this record does not say. Its binding state is NO_PUBLIC_PROOF. Its agent trust is AGENT_CREDENTIAL_MISSING. Its freshness is UNDETERMINABLE. We publish it unedited, on our own homepage, because a layer that only ever shows its strongest record is a marketing surface. The value of a record is that it tells you where it is weak before you find out the hard way.
This is a transcript, captured at the time shown. A transcript can become stale. It is not proof. Always verify live.
Three ways in
The same record serves three different jobs. Start from the one you actually have.
Check a target before you wire it in.
Run the ECZ-ID MCP Verifier from a terminal or as a GitHub Action in CI. It reports one of eighteen result states — and there is deliberately no FAILED_VERIFICATION among them, because the absence of a public record is an absence, not a failure, and rendering it as one would punish every honest operator who has not published yet.
Make the server you operate identifiable.
Publish an ECZ-ID for the entity behind your MCP server, bind the things you can actually demonstrate, and give every enterprise reviewer one URL to check instead of a questionnaire and a fortnight of email. Nothing you publish becomes an approval, and nothing you leave unpublished becomes a mark against you.
Govern what your agents are allowed to rely on.
Read the fields the record tells machines to read, apply your own fail-closed policy in your own code, and keep a record of what each decision was based on. ECZ-ID decides nothing on your behalf. It makes the basis of your decision resolvable by someone who was not in the room.
The full picture — what the layer records, what it refuses to record, and why About ECZ-ID Trust MCP
Structured access for automated clients and interoperable systems.
The authorization server is a deployment profile, not part of the contract. The current deployment uses Microsoft Entra; another operator of this contract may substitute their own. The contract is provider-neutral by design, and it is frozen — a tool name or a field cannot change under you without a new version.
| Tool | Access | Writes | What it does |
|---|---|---|---|
| resolve_identity | anonymous | no | Resolves an ECZ-ID and returns its canonical state, when it was checked, a proof link, a re-check action, and the caveat that local policy decides. Never asserts safety, approval or compliance. |
| get_current_state | anonymous | no | Returns the narrow, resolver-derived current state and nothing else. |
| get_resolver_link | anonymous | no | Builds the deterministic public proof and re-check URL for an ECZ-ID. Makes no network call. |
| explain_status | anonymous | no | Renders a status in approved, claims-safe wording. Deterministic — no model is involved. Absence of evidence renders the neutral wording, never “unsafe”. |
| find_product | anonymous | no | Routes to the single best next ECZ-ID product action for a stated situation. |
| get_install_instructions | anonymous | no | Returns install and usage instructions for a named ECZ-ID product. |
| create_request_to_resolve | OAuth2 bearer | yes — a neutral request record | Creates a neutral Request-to-Resolve record. Requires scope RequestToResolve.Create. It records that someone asked; it does not create, amend or imply any state about the subject. |
This website does not verify anything. It has no lookup box and it never will, because a page on this site has no authority to tell you what is true about someone else. Here are the four surfaces that do, and what each one is actually for.
You have a server URL, a package or a repository, and you are at a keyboard.
npx -y @ecocitizenz/ecz-id-mcp-verifier --target <target>
You want the check to run on every pull request rather than when someone remembers.
Policy OPEN, PREFER or REQUIRE. Outputs result-state, reason-codes and an action envelope your workflow can branch on.
You are an agent, or you are building one, and the check has to happen mid-conversation.
Call resolve_identity over Streamable HTTP. Six of the seven tools are anonymous and read-only.
You already have an ECZ-ID and you just want to read the record.
Open the canonical URL and match the identifier format ^ECZ(-[A-Z0-9]{2,32}){1,4}$. No account, no key, no rate limit to negotiate.
If a target has no public ECZ-ID record, every one of those four surfaces reports exactly that and stops. Absence of a record is reported as absence. It is not rendered as failure, risk, or a reason to distrust anyone — which is why there is no FAILED_VERIFICATION state anywhere in the ECZ-ID MCP Verifier.
Where the layer meets delivery
Nothing above this line is a product you have to buy. The Resolver is public. The Verifier is free to use under the ECZ-ID Proprietary Limited-Use License. Six of the seven Trust MCP tools are anonymous and read-only. What follows is different: four fixed-scope engagements that do the implementation work, with the price and the full scope published before you commit, and no sales call in between.
Everything above this line works without paying us. Everything below is work we do for you, at a published price.
EcoCitizenz delivers the engagement. TrustOps — the commercial and entitlement surface — reviews the order and owns payment and order state. Paying for an engagement buys implementation work. It does not create, amend or imply any ECZ-ID state.
Services
Every service publishes its scope, deliverables, acceptance criteria and price before you pay. Start online through TrustOps — no sales call required.
Start here
£395
Paid in full at checkout
A fixed-scope, human-reviewed assessment of one MCP implementation — what will hold in production, what will not, and what to change first.
£1,950
£1,170 at checkout + £780 on acceptance
A bounded, hands-on migration of one existing MCP implementation to a stateless, deployment-safe architecture — implemented, tested and documented.
from £3,500
£1,750 at checkout; balance per written scope
Enterprise-managed authorization (EMA) and identity-assertion grant (ID-JAG) design for MCP — cross-app access, token exchange and identity boundaries, piloted against your identity provider.
£6,500
£2,600 at checkout; 30% + 30% at agreed milestones
A complete, evidence-backed MCP pilot for one enterprise use case — discovery to handover, with the documentation security and procurement actually ask for.
Your delivery schedule is confirmed during intake. Payments and order status are handled by TrustOps. If EcoCitizenz declines an engagement before commencement, payments are refunded in full.
Already have an MCP configuration in front of you? The free Config Check reads it in your browser — nothing you paste leaves your machine, nothing is executed, and no endpoint is contacted without your explicit consent. It checks configuration. It does not resolve identity, and it is not part of the trust layer above. Run the free Config Check
Vendor-neutral. Published prices. Human-reviewed deliverables.
Included, not sold separately
Every paid engagement 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.
Purchase
Your order automatically starts account setup. There is nothing to apply for and no approval step — setup begins on its own.
Activation
When setup completes, your included Passport access activates automatically.
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.
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.
90-day experience included with every paid engagement. See how Resolver proof works (external). See the technical documentation for ECZ-ID evidence-state definitions or the field classes in detail.
Continuation, not part of the fixed-price services
A fixed-scope engagement ends. Your MCP surface keeps changing. These ongoing ECZ-ID packages are operated by TrustOps and exist so the proof you can point people at stays current after we hand over — they are a continuation route, not part of the fixed-price services above.
ECZ-ID MCP Verifier™
Free
Resolve a Passport, inspect what a page actually asserts, and see the basis of each field.
Anyone checking a provider before they rely on it.
ECZ-ID MCP Assurance™
£199/month
Keep your MCP provider identity and evidence current and independently resolvable, with the lifecycle operations that hold it accurate as your surfaces change.
Providers whose customers re-check them.
ECZ-ID MCP Assurance Plus™
£499/month
Extend that evidence posture across broader MCP surfaces and targets, within the entitlements the canonical product defines.
Providers operating several surfaces or targets.
ECZ-ID MCP Policy™
£1,499/month
Publish machine-readable buyer-side acceptance policy for MCP surfaces — what your organisation will and will not accept from what it consumes, stated under your own authority.
Buying organisations consuming third-party MCP surfaces.
The four professional services above are fixed-scope engagements with published totals and milestones — they are not subscriptions, never convert into one, and buying an engagement never enrols you in a package.
These packages are acquired and operated through TrustOps — see the ongoing packages on TrustOps (external).
Resources
Two executive briefings we wrote for the questions our customers were already being asked. Both are free, neither is gated, and both are written to be forwarded to a security or procurement reviewer without editing.
Security briefing
What CVE-2026-59726 teaches MCP operators about authentication, authorisation and evidence — and the per-request identity and logging controls enterprise buyers now expect under the MCP 2026-07-28 stateless request model.
For engineering and security leads running an MCP server.
8 pages · 6-minute read · primary sources · free, no email required
Regulatory briefing
What Article 50 requires from 2 August 2026, what it explicitly does not require, and how agent operators and MCP providers can publish transparency evidence a customer can re-check independently.
For AI-agent operators, MCP providers and enterprise buyers.
8 pages · executive briefing · free, no email required
FAQ
Five of them are about the layer and what it refuses to claim. The rest are about scope, price and what happens after you pay.
Yes. Every service publishes its fixed price and full scope, and no call is required. Checkout is hosted by TrustOps — you review your order before any payment step. You can ask us anything by email first.
TrustOps confirms your order and opens the intake form for your service. You provide the agreed inputs (for example repository access and your intended client list), we validate scope, and we confirm your start date with you during intake. If we conclude the engagement is not a fit before commencement, the amount paid is refunded in full.
Engagements are delivered by EcoCitizenz. EcoCitizenz may use appropriately vetted specialists or subcontractors to support delivery; EcoCitizenz remains responsible for the agreed deliverables, and any specialist access to your systems or confidential information is disclosed and governed by the engagement terms.
No. The professional services on this site are fixed-price engagements and are never discounted — the published price is the price everyone pays. Any platform credit offered elsewhere in the EcoCitizenz ecosystem applies to eligible TrustOps subscription payments only, never to these engagements.
If you are unsure, start with the MCP Readiness Audit (£395). It produces a severity-ranked findings report and remediation plan, and it tells you precisely whether a Migration Sprint, identity work or an Enterprise Pilot is worth buying. The free scanner also maps its findings to a recommended next step.
Check an MCP server before your agents do, publish an identity for the one you operate, or read a real record for yourself — ours is public, including the parts of it that are weak. If you would rather have the implementation work done, the four engagements above have published prices and full scope, and the audit is where most teams start.
Websites explain. TrustOps operates. Backend truth decides. Resolver proves.
Quick routes