Skip to main content

About ECZ-ID Trust MCP

MCP connects AI systems to tools. It does not tell you who is on the other end.

That is not a flaw in the protocol. It is a different layer.

The Model Context Protocol standardises the connection between an AI application and a tool: the transport, the session, the capabilities, the schemas and the authorisation to call. It was never scoped to standardise the counterparty. ECZ-ID Trust MCP is the layer that makes the counterparty resolvable — identity, authority, evidence, current state, and one machine-readable way to re-check all four.

  • Who operates this server?
  • Who controls the identity behind it?
  • What authority has that operator actually recorded?
  • What evidence supports any of it?
  • Is what I am reading current?
  • Can another machine check it without asking us?

This page explains a category. It sells nothing, and it verifies nothing. Proof is read at the ECZ-ID Resolver, which is a separate surface and the only place in this estate where proof is read. Everything below can be checked there.

See the five answersOpen a real record at the Resolver

The protocol

What MCP standardises, stated accurately

MCP is an open protocol for connecting AI applications to external tools and data. It is a good protocol, and nothing on this page argues otherwise. Describing it accurately is a prerequisite for describing anything that sits above it, so here is what it defines.

Transport and session
How a client and a server exchange JSON-RPC messages — over stdio for local processes, or Streamable HTTP for remote ones — and how a session is established and carried.
Capability negotiation
How a client and a server agree, at connection time, which protocol version is in use and which features each side supports.
Tools, resources and prompts
The primitives a server exposes, their input schemas, and how a client discovers them, lists them and invokes them.
Authorisation
How a client obtains and presents authorisation to call a protected server, using OAuth 2.1-based authorisation with protected-resource metadata. This answers whether a given caller may connect. It was not designed to answer who the operator on the other side is.
Server description and discovery
How a server describes itself, so a client, a catalogue or a registry can find it, install it and start it with the right configuration.

Every one of those is a statement about the connection. None of them is a statement about the counterparty — and none of them was ever meant to be. A wire protocol that also tried to adjudicate who a company is, what it is authorised to do, and whether that is still true this morning would be a worse protocol.

The open questions

Six questions the protocol is not there to answer

These questions are real, they are load-bearing, and every team that puts a third-party MCP server into production answers them somehow. The point of this section is that today they are answered informally, by artefacts that another machine cannot act on, about a moment that has already passed.

Who operates this?

A server name, a package name and a domain are strings. They are chosen by whoever publishes the server, and the protocol has no notion of a legal entity — nor any reason to have one. Registries and catalogues record what a publisher declares, and some verify control of a namespace at publication time; that is a publication-time fact about a name, not a continuing statement about an operator.

TODAYA README, an npm scope, and a company website that looks convincing.

Who controls it?

Control of a domain, a repository, an API, a wallet or an asset is a fact about the world outside the connection. Nothing exchanged during a handshake can establish it, because the handshake only proves that something answered at an address.

TODAYThe assumption that the domain in the URL belongs to the brand in the name.

What authority exists?

Whether an operator is authorised to act for a customer, within which scopes, and whether that authority has since been withdrawn, is a relationship between two parties. It is not visible on the wire, and a token proves only that access was granted at some point to somebody.

TODAYA contract in someone's document store, and a credential nobody has re-examined since it was issued.

What evidence supports it?

The protocol carries a call and a result. It does not carry a durable, independently retrievable record that the call's preconditions were ever established — and it should not, because that is not what a transport is for.

TODAYLogs held by the party you are trying to evaluate.

Is this current?

A connection is a moment. Revocation, suspension, a change of operator, a lapsed authority and a withdrawn credential all happen between moments. Anything captured once and stored describes the moment of capture, not the moment of reliance.

TODAYA PDF, a badge image or a screenshot — each of which was true once.

Can another machine check it?

An answer that only the operator can produce is not checkable; it is testimony. A second machine needs a canonical address it already knows, a versioned schema it already understands, and a state it can act on without a human in the loop.

TODAYAsk the vendor. Wait three weeks for a security questionnaire to come back.

Every substitute above has the same three properties. It is a claim made by the party being evaluated, in a format another machine cannot act on, describing a moment that has already passed. That is the gap. It sits above the protocol, not inside it.

Where the gap sits

The MCP ecosystem chain, and the three links that are rarely resolvable

Follow one agent call from end to end. MCP owns the middle of this chain and owns it well. The first, fifth and sixth links are the ones that usually exist somewhere in an organisation — in contracts, ticketing systems, identity providers and audit logs — without existing as one relationship a third party can resolve at an address.

A six-node chain: operator, then MCP server, then AI agent, then action, then evidence, then current state — with a return edge from current state back to operator labelled independent re-check.

  • OPERATOR
  • MCP SERVER
  • AI AGENT
  • ACTION
  • EVIDENCE
  • CURRENT STATE

INDEPENDENT RE-CHECK — back to the first node, before every reliance

OPERATORECZ-ID
The legal entity that runs the server and stands behind what it does. Not a brand, not a repository, not a domain — a named entity in a named jurisdiction.
MCP SERVERMCP
The declared tool surface: its transport, its capability set, its schemas and its authorisation requirements.
AI AGENTMCP
The client that connects, reads the tool list, and decides to rely on what it finds there.
ACTIONThe operator's own systems
The tool call, its arguments, and its effect on something in the world.
EVIDENCEECZ-ID
What remains afterwards that a third party can retrieve without the operator's cooperation.
CURRENT STATEECZ-ID
What is true at the moment of the next reliance, rather than at the moment the record was written.

Highlighted links are the ones ECZ-ID makes first-class and independently resolvable. The return edge is what turns a line into a loop: without a re-check, every node upstream decays quietly and nothing tells you. ECZ-ID replaces none of the systems that already hold these facts, and it does not sit in the call path — no traffic passes through it.

What the layer adds

Five answers, each one a field you can read

Identity, Authority, Evidence, State and Resolution are not marketing categories invented for this page. Each maps to named fields in the ECZ-ID resolver record, published under a versioned public-projection contract. Each also carries a boundary, published in the same record, stating what it does not prove.

Example values are taken from ECZ-GB-RBS1NW, EcoCitizenz's own parent record, read at 2026-08-23T02:07:25Z. They are a snapshot printed on a page. They are not live, and they are not proof. The live record is the proof, and it may have changed since this page was built.

Identity — who operates this?

An MCP server is published under a name, a package and a domain. All three are strings chosen by the publisher. Identity replaces the string with a record: a named legal entity, in a named jurisdiction, at a canonical address — with every field labelled by where it came from. On this record the legal name, entity type, jurisdiction, registration number, registered address and incorporation date are each classified as externally referenced, with Companies House named as the source and 2026-07-31 recorded as the date it was checked. The trading name, the declared website and the business summary are classified as customer-declared. The record states which is which, inside the record.

Fields in the record

  • resolver_v2.identity.legal_name
  • resolver_v2.identity.trading_name
  • resolver_v2.identity.entity_type
  • resolver_v2.identity.jurisdiction
  • resolver_v2.identity.profile_state
  • resolver_v2.identity.profile_source
  • resolver_v2.identity.profile_validation_state

From ECZ-GB-RBS1NW

identity.legal_name
"ECOCITIZENZ LTD"
identity.trading_name
"EcoCitizenz"
identity.entity_type
"ltd"
identity.jurisdiction
"UNITED KINGDOM"
identity.profile_state
"PROFILE_COMPLETE"
identity.profile_source
"CUSTOMER_DECLARED"
identity.profile_validation_state
"VALID_DECLARED"

What it does not prove

Boundary. The same record's reliance.do_not_infer list opens with legal_name. Provenance is not binding: the record says where a value came from and when it was last checked, and it deliberately stops short of asserting that the entity named here controls the domain, the repository or the API you arrived through. Control is a separate question, and it is answered — or openly not answered — by the binding fields below.

Authority — who controls it, and what has this operator recorded?

Authority on this page always means the authority the operator has recorded — never authority conferred by EcoCitizenz. Two field groups carry it. binding says whether public proof exists that this identity controls a specific thing: a domain, an API, a repository, a wallet, an asset. agent_trust says whether this identity has issued a credential to an agent acting on its behalf. Both are read as states, and both have an honest negative state that is published rather than omitted.

Fields in the record

  • resolver_v2.binding.state
  • resolver_v2.binding.reason_code
  • resolver_v2.binding.scopes
  • resolver_v2.binding.do_not_infer_control_over
  • resolver_v2.agent_trust.status
  • resolver_v2.agent_trust.required_action
  • resolver_v2.agent_trust.human_copy

From ECZ-GB-RBS1NW

binding.state
"NO_PUBLIC_PROOF"
binding.reason_code
"NO_PUBLIC_BINDING_PROOF_AVAILABLE"
binding.scopes
[]
binding.do_not_infer_control_over
["domain_control", "api_control", "repository_control", "wallet_control", "asset_control"]
agent_trust.status
"AGENT_CREDENTIAL_MISSING"
agent_trust.required_action
"issue_agent_credential_child_passport"

What it does not prove

Boundary. Read those values again: they are ours. Our own record publishes NO_PUBLIC_PROOF for binding and AGENT_CREDENTIAL_MISSING for agent trust, and it renders the reason for a human as "This identity has not issued an Agent Credential. Do not infer agent authority from the parent ECZ-ID." That is what an absent answer looks like when it is published as a state instead of being hidden. It is not a finding against the holder, it is not a score, and it is never rendered as failure.

Evidence — what supports this, and can I retrieve it without asking the operator?

Evidence is the difference between a claim and a record. Decisive events produce receipts: hashed with SHA-256 (FIPS 180-4), signed with Ed25519 (RFC 8032) and, where post-quantum signing is active, additionally with CRYSTALS-Dilithium ML-DSA-65 (NIST FIPS 204), then anchored to a ledger the record names. A third party can retrieve them without the operator's cooperation, and that last property is the entire point. Evidence held only by the party being evaluated is testimony.

Fields in the record

  • resolver_v2.evidence.public_receipt_state
  • resolver_v2.evidence.last_public_receipt_at
  • resolver_v2.ledger.ledger_name
  • resolver_v2.ledger.public_receipt_state
  • resolver_v2.ledger.last_public_anchor_at
  • resolver_v2.crypto.signature_mode
  • resolver_v2.crypto.core_verification_state
  • resolver_v2.crypto.resolver_verification_scope

From ECZ-GB-RBS1NW

evidence.public_receipt_state
"PUBLIC_RECEIPT_AVAILABLE"
evidence.last_public_receipt_at
"2026-05-10T21:27:04.319Z"
ledger.ledger_name
"ecozledger"
ledger.last_public_anchor_at
"2026-05-10T21:27:04.319Z"
crypto.signature_mode
"HYBRID_ED25519_ML_DSA_65"
crypto.core_verification_state
"CORE_VERIFICATION_AVAILABLE"
crypto.resolver_verification_scope
"RESOLVER_STRUCTURAL_DISPLAY_ONLY"

What it does not prove

Boundary. The record carries its own warning against reading too much into the cryptography: "Quantum-safe signing protects record integrity only. It does not create identity truth, compliance truth, regulatory approval, insurance, certification, safety, or business quality." The Resolver is equally candid about itself — resolver_verification_scope reads RESOLVER_STRUCTURAL_DISPLAY_ONLY. The Resolver displays structure. Verifying a receipt's hash and signatures against the ledger anchor happens in ECZ-ID Core, not in a browser and not on this website.

State — is what I am reading current?

State is what separates a record from an archive. The public projection publishes seven axes, and they are independent by design. On our record the subject is ACTIVE and, at the very same moment, freshness is UNDETERMINABLE and the verification service is UNAVAILABLE. Nothing averages those into a verdict, because averaging them would hide which axis was weak. A relying party reads the axes that matter to its own decision and sets its own threshold. Every state carries the moment it became effective, and the record carries the moment it was resolved.

Fields in the record

  • resolver_v2.state.lifecycle_state
  • resolver_v2.state.parent_tier
  • resolver_v2.state.verification_state
  • resolver_v2.state.abuse_state
  • resolver_v2.state.reliance_level
  • resolver_v2.public_projection.axes (seven independent axes)
  • resolver_v2.resolved_at
  • resolver_v2.last_state_change_at

From ECZ-GB-RBS1NW

state.lifecycle_state
"ACTIVE"
state.parent_tier
"VERIFIED"
state.verification_state
"PARENT_TIER_VERIFIED"
state.abuse_state
"NONE"
state.reliance_level
"LIMITED_RELIANCE_NO_BINDING"
axes.subject_state
"ACTIVE"
axes.freshness_state
"UNDETERMINABLE"
axes.enrolment_state
"NOT_ENROLLED"
axes.publication_state
"PUBLISHED"
axes.entitlement_state
null
axes.verification_service_state
"UNAVAILABLE"
axes.receipt_verification_state
"NOT_APPLICABLE"
resolved_at
"2026-08-23T02:07:25.801724Z"
last_state_change_at
"2026-08-10T09:06:09.997Z"

What it does not prove

Boundary. parent_tier: VERIFIED is an ECZ-ID state and nothing beyond one. The Trust MCP Server — the layer's MCP server surface — renders the same sentence for machines from its frozen contract: VERIFIED is an ECZ-ID state, not a Microsoft certification. The record's own lifecycle note is just as narrow: 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." And reliance_level reads LIMITED_RELIANCE_NO_BINDING — the record is telling you, in a field, how far it thinks you should lean on it.

Resolution — can another machine check this, without asking us?

Resolution is the answer that makes the other four usable. One identifier, one canonical human address, one canonical machine address, a versioned schema, a versioned disclosure contract and a versioned reason-code vocabulary. Identifiers match ^ECZ(-[A-Z0-9]{2,32}){1,4}$ and run to at most 64 characters. A second machine never has to negotiate with the first, accept a file it was handed, or trust the format of an attachment: it fetches an address it already knows and reads fields it already understands. The record goes further and tells it which fields to use and which states to fail closed on.

Fields in the record

  • resolver_v2.canonical_resolver_url
  • resolver_v2.canonical_machine_json_url
  • resolver_v2.schema_version
  • resolver_v2.public_projection.projection_contract_version
  • resolver_v2.public_projection.public_disclosure_version
  • resolver_v2.public_projection.reason_code_version
  • resolver_v2.machine_policy.machines_should_use
  • resolver_v2.machine_policy.fail_closed_states
  • resolver_v2.machine_policy.recommended_machine_action
  • resolver_v2.machine_policy.high_risk_action

From ECZ-GB-RBS1NW

canonical_resolver_url
"https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW"
canonical_machine_json_url
"https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json"
schema_version
"2.0"
projection_contract_version
"2.1.0"
public_disclosure_version
"pdv-1.0.0"
reason_code_version
"rcv-1.0.0"
machine_policy.recommended_machine_action
"ALLOW_PARENT_IDENTITY_VISIBILITY_ONLY"
machine_policy.high_risk_action
"FAIL_CLOSED_UNLESS_LIVE_BINDING_AND_EVIDENCE_AVAILABLE"

What it does not prove

Boundary. Resolving a record is not endorsement, and the record states that itself: "Public actions are informational only and are not proof of identity, authority, control, or reliance." Resolution tells a machine what is published at this moment. What to do about it is the relying party's policy, and ECZ-ID takes no part in that decision — it is not in the call path and it stops nothing.

A real record, read end to end

ECZ-GB-RBS1NW — our own record, including the fields that say no proof

This is EcoCitizenz's own parent record. We use it here rather than an invented example because a page about verifiable records that demonstrated itself on synthetic data would be demonstrating the wrong thing. Two of the values below are unflattering to us. They are printed anyway, at the same size as the rest.

SNAPSHOT · READ 2026-08-23T02:07:25Z · NOT LIVE

Resolution

ecz_id
ECZ-GB-RBS1NW
record_type
ECZ_ID_PARENT
schema_version
2.0
canonical_resolver_url
https://resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW
canonical_machine_json_url
https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json
resolved_at
2026-08-23T02:07:25.801724Z
last_state_change_at
2026-08-10T09:06:09.997Z
record_provenance_class
CURRENT

Identity

identity.legal_name
ECOCITIZENZ LTD
identity.trading_name
EcoCitizenz
identity.entity_type
ltd
identity.jurisdiction
UNITED KINGDOM
identity.profile_state
PROFILE_COMPLETE
identity.profile_source
CUSTOMER_DECLARED

Authority

binding.state
NO_PUBLIC_PROOF
binding.reason_code
NO_PUBLIC_BINDING_PROOF_AVAILABLE
binding.scopes
[]
agent_trust.status
AGENT_CREDENTIAL_MISSING

Evidence

evidence.public_receipt_state
PUBLIC_RECEIPT_AVAILABLE
ledger.ledger_name
ecozledger
ledger.last_public_anchor_at
2026-05-10T21:27:04.319Z
crypto.signature_mode
HYBRID_ED25519_ML_DSA_65
crypto.resolver_verification_scope
RESOLVER_STRUCTURAL_DISPLAY_ONLY

State

state.lifecycle_state
ACTIVE
state.parent_tier
VERIFIED
state.abuse_state
NONE
state.reliance_level
LIMITED_RELIANCE_NO_BINDING
axes.freshness_state
UNDETERMINABLE
axes.publication_state
PUBLISHED
axes.verification_service_state
UNAVAILABLE

Reliance

reliance.summary
Active ECZ-ID. Re-verify before reliance.
reliance.reverify_before_reliance
true
machine_policy.recommended_machine_action
ALLOW_PARENT_IDENTITY_VISIBILITY_ONLY
machine_policy.high_risk_action
FAIL_CLOSED_UNLESS_LIVE_BINDING_AND_EVIDENCE_AVAILABLE

Two fields on our own record read NO_PUBLIC_PROOF and AGENT_CREDENTIAL_MISSING. They are shown here on purpose. A record that only ever renders good news is a marketing asset, and a layer that hid its holders' gaps would be worth nothing to the people relying on it. Absence of proof is a state. It is published as a state, it is given a reason code, and it is never rendered as failure or as a judgement about the holder.

Open ECZ-GB-RBS1NW at the ResolverRead the machine JSON

Those two addresses are the proof. This page is a printout.

Resolver-first

A projection is not a source of truth — and that is the point

The Resolver looks like the system of record. It is not, and the architecture depends on it not being one. Canonical state is written in ECZ-ID Core. The Resolver is a read-only projection of what Core holds, published under a versioned disclosure contract. It reads. It never writes. Nothing that happens on a public surface can change what Core decided.

ECZ-ID Core / Backend
Writes authoritative state. The only writer in the estate.Not a public surface. You do not read it directly, and nothing you do on a website reaches it as an instruction.
TrustOps
Owns entitlement and commercial state. Authoritative for order and payment status.Publishes no proof. Payment confers no status of any kind, and never has.
ECZ-ID Resolver
The public, read-only projection. The only place proof is read.Never a source. It displays what Core holds; it cannot amend it, and it cannot be argued with.
MCP surfaces and this website
Distribution, interaction and explanation.They create no authoritative state, ever. This page in particular explains and routes; it verifies nothing.

Websites explain. TrustOps operates. Backend truth decides. Resolver proves.

This website explains and sells professional services. Checkout, intake and payment status are handled by TrustOps. Canonical ECZ-ID state is held by the ECZ-ID backend; the public Resolver is a read-only projection of proof. Nothing on this site — including payment — creates or amends authoritative ECZ-ID state.

  1. One address beats one integration

    A relying party needs a canonical address per identifier and a versioned schema behind it — not a bilateral integration with every counterparty it might one day evaluate. Resolution scales because it is the same fetch every time, whoever the operator is.

  2. A surface that cannot write cannot be talked into writing

    The Resolver has no code path that confers status, so there is nothing to socially engineer, nothing to buy and nothing to argue into existence. Separating the reader from the writer removes a whole class of pressure that trust systems usually have to resist by policy.

  3. Separation is what makes withdrawal mean something

    If the surface that publishes a status is also the surface that sells it, withdrawing that status is a commercial decision. Because Core writes and the Resolver only reflects, revocation is a state transition that appears on the public projection whether or not anyone finds it convenient.

The record admits its own limits in the same breath: resolver_verification_scope reads RESOLVER_STRUCTURAL_DISPLAY_ONLY. The Resolver shows you the structure of the evidence. Verifying a receipt against the ledger anchor happens in Core.

The principle

Re-check before reliance. A badge is a photograph of a state, not the state.

This is the operational rule the whole layer exists to make possible, and it is carried in the record rather than in our marketing: reliance.reverify_before_reliance is true, the human summary reads "Active ECZ-ID. Re-verify before reliance.", and every derivative artefact the Resolver produces is flagged is_proof: false.

The shareable summary card
Human share asset. Not proof. Always verify via the live Resolver.
The QR code
QR routes to the live Resolver. The QR alone is not proof.
A printed or PDF snapshot
Printed and PDF snapshots can become stale. Always verify live.

Those notes are not ours to soften: they are fields in the record, published beside the artefacts they describe. The pattern holds for this page too — section six is a printed snapshot of a record, and it says so at the top.

The same principle, for machines

A relying agent does not read prose. The record tells it which fields to act on, and which states must stop the interaction rather than qualify it.

machine_policy.machines_should_use

  • state.lifecycle_state
  • state.reliance_level
  • binding.state
  • evidence.public_receipt_state
  • ledger.public_receipt_state
  • agent_trust.status

machine_policy.fail_closed_states

  • REVOKED
  • SUSPENDED
  • DEGRADED
  • MISMATCH
  • PROOF_UNAVAILABLE
  • PUBLIC_PROJECTION_UNAVAILABLE
  • ACTIVE_ABUSE_FLAGGED
  • UNKNOWN

UNKNOWN is on that list beside REVOKED, and the ordering is deliberate. A machine that cannot determine a state is in the same position as a machine that has determined a bad one. A static artefact answers "was this true when the image was made?" A resolution answers "is this true now?" Only the second question is worth automating.

Boundaries

What ECZ-ID is not

This is not a disclaimer appended for legal comfort. It is the shape of the product. Each line rules out a category ECZ-ID could plausibly be mistaken for, and each exclusion is what keeps the remaining claim narrow enough to be worth relying on. A layer that claimed all nine would be relied on for none of them.

Not an MCP security scanner.

ECZ-ID does not inspect a server for vulnerabilities, does not execute it, and does not rate its code. It records who stands behind it.

Not a certification authority.

No ECZ-ID state means certified. VERIFIED is a tier inside the ECZ-ID lifecycle, and it is never a third party's certification of a product, a company or a control.

Not a trust score provider.

There is no number. The public projection publishes seven independent axes precisely so they cannot be collapsed into one, because a single figure would hide which axis was weak.

Not an MCP marketplace or registry.

ECZ-ID does not list, rank, recommend or gate servers. Holding a record is neither an endorsement nor a review, and nothing is ranked against anything else.

Not an identity provider.

ECZ-ID issues no login, holds no user credentials and authenticates nobody into anything. It is a record about an entity, not an authentication service for one.

Not a gateway.

ECZ-ID is not in the call path. No traffic passes through it, it terminates nothing, and removing it stops no request.

Not a firewall or an enforcement point.

ECZ-ID blocks nothing and permits nothing. It publishes state; what a relying party does with that state is entirely the relying party's policy.

Not a replacement for security controls.

ECZ-ID adds no protection to a system and removes no need for the controls that system already requires. It answers a question those controls were never asked.

Not a compliance requirement.

No rule obliges anyone to hold an ECZ-ID, and holding one satisfies no regulation. Any page that told you otherwise would be selling you something.

ECZ-ID is a neutral, resolver-verifiable identity, authority, evidence and current-state layer. That sentence is deliberately narrow, and every exclusion above is what keeps it true.

The layer and its surfaces

One layer. Five named surfaces. Each does a different job.

"ECZ-ID Trust MCP" is the name of the layer, and it is what this website is. Everything below is a named surface of that layer. Each is listed with the kind of surface it is, because several of these names are close enough to be mistaken for one another — including two that are near-anagrams.

ECZ-ID Trust MCP

The layer — and this website

Where
https://mcp.ecocitizenz.com
What it does
The layer, and this website. Explains the layer and routes you to the surface you actually need.
What it does not do
Creates no authoritative state and performs no verification.

Trust MCP Server

Machine surface — a hosted MCP server

Where
https://trust-mcp.ecocitizenz.com/mcp
What it does
Machine surface — a hosted MCP server. Distribution and interaction only; it writes no truth.
What it does not do
Writes no truth. Its one protected tool opens a neutral Request-to-Resolve record; it confers no status.

ECZ-ID MCP Verifier

CI and command-line surface — an npm package and a GitHub Action

Where
https://www.npmjs.com/package/@ecocitizenz/ecz-id-mcp-verifier
What it does
CI and command-line surface. Checks a target against public resolver proof, free to use under the ECZ-ID Proprietary Limited-Use License.
What it does not do
There is deliberately no failure state for missing proof. Absence is reported as absence — NO_PUBLIC_RESOLVER_PROOF_FOUND, never a verdict against the target.

ECZ-ID MCP Trust

Editor surface — a VS Code extension

Where
https://developers.ecocitizenz.com/mcp-trust
What it does
Editor surface — a VS Code extension. Inventories the MCP configuration on your own machine and shows what changed.
What it does not do
It reads your local configuration. It does not verify servers, and it is not the Trust MCP Server — the layer's MCP server surface.

ECZ-ID Resolver

Proof surface — the public read-only projection

Where
https://resolver.ecocitizenz.org
What it does
Proof surface — the public, read-only projection of the record. Never a source of truth.
What it does not do
Never writes, and is never a source of truth.

TrustOps

Commercial surface — entitlement and order state

Where
https://trustops.ecocitizenz.com
What it does
Commercial surface — entitlement and order state. Authoritative for order and payment status; it publishes no proof.
What it does not do
Publishes no proof. Payment creates no ECZ-ID status.

Two of those names sit close together on purpose, so this site never uses either without saying which surface it means. ECZ-ID Trust MCP is the layer. The Trust MCP Server is its machine surface. ECZ-ID MCP Trust is the VS Code extension. Nothing has been renamed.

Next

Where to go from here

You are building with MCP

Check a target against public resolver proof from your pipeline or your terminal, with the ECZ-ID MCP Verifier — the layer's CI and command-line surface. It is free to use under the ECZ-ID Proprietary Limited-Use License.

For developers

You operate an MCP server

Make the operator behind your server resolvable, so the teams evaluating you have an address to check instead of a questionnaire to send.

For MCP providers

You govern what agents rely on

Set a policy for what your agents must be able to resolve before they rely on a third-party server, and for which states must stop an interaction rather than qualify it.

For enterprise

If you would rather have this assessed or implemented for you, EcoCitizenz sells four fixed-scope MCP engagements with published prices, published scope and published exclusions. Services and pricing

The entity behind this page

Who we are, disclosed the way we ask everyone else to disclose it

A page arguing that operators should be resolvable would be difficult to take seriously if you could not resolve the operator who published it. So: this website is published by the company named below, its details are on our own resolver record with Companies House recorded as the source, and you can re-check them there rather than take them from this page.

Registered company disclosure

Legal name
ECOCITIZENZ LTD
Company number
17348848
Incorporated
20 July 2026
Registered office
66 Paul Street, London EC2A 4NA, United Kingdom
Jurisdiction
England and Wales, United Kingdom
Our ECZ-ID
ECZ-GB-RBS1NW

Publishing our own record does not make us an authority, and it is not offered as a credential. It makes us checkable, which is the only claim on this page we would ask you to hold us to.

Re-check ECZ-GB-RBS1NW at the Resolver