Machine surface

The Trust MCP Server

A hosted MCP server that answers questions about ECZ-ID records.

This is one named surface of the ECZ-ID Trust MCP layer, not the layer itself. It exposes seven tools over Streamable HTTP: six are anonymous and read-only, and one is protected by OAuth2. Everything it returns is derived from the public resolver projection, and nothing it does writes canonical state.

There is no console on this page and nothing here calls the endpoint. This is documentation of a machine surface, written for a person deciding whether to point a client at it.

See the seven tools Reference documentation at the ECZ-ID Developer Gateway

The endpoint

One address, one transport, two protocol revisions

Everything below is a statement about the connection. It is deliberately specific, because a reader deciding whether to integrate needs facts they can check against their own client rather than an adjective.

Endpoint: https://trust-mcp.ecocitizenz.com/mcp
Transport: Streamable HTTP, carrying JSON-RPC 2.0.
Protocol revisions: The Trust MCP Server accepts protocol 2026-07-28 and negotiates the session version with the client; a client that offers 2025-11-25 is served on 2025-11-25.
Contract: The ECZ-ID Trust MCP Contract, frozen at milestone MS-032 on 19 August 2026. Frozen means the tool set, the argument schemas and the claims wording do not move without a new contract.
Provider neutrality: The contract is provider-neutral. It names no cloud, no marketplace and no authorisation vendor as a requirement, and a different deployment may substitute its own authorisation server while serving the same contract.

Two request headers are load-bearing on this deployment. Accept must list both application/json and text/event-stream, or the request is answered with 406. This deployment also requires the Mcp-Method header on the request. It is not part of the MCP HTTP transport; a client that does not send it will not receive this response shape.

How to connect

Point an MCP client at the endpoint above, over Streamable HTTP, speaking JSON-RPC 2.0. For the six anonymous tools there is nothing to install, no account and no key — any client that can address a remote MCP server can address this one, and the seventh tool answers 401 until a bearer token is supplied. Reading the response is a separate step from making the call, and the reliance boundary published in the payload still governs what may be inferred from it.

Runnable connection instructions — a working call, and host configuration

The tool boundary

Seven tools. Six anonymous and read-only, one protected.

The split is the whole design. Six tools read what is already public and need no token, so a relying client can ask its questions without an account, a contract or a conversation. One tool is protected, and even that one writes no truth.

resolve_identity

Access: anonymous
Read-only: yes
Required arguments: ecz_id
What it does: Resolves an ECZ-ID to its current published state, the moment it was checked, the public proof link and the re-check action. Never asserts safety, approval or compliance.

get_current_state

Access: anonymous
Read-only: yes
Required arguments: ecz_id
What it does: Returns the narrow current state derived from the resolver projection, with no risk, safety or compliance inference attached to it.

get_resolver_link

Access: anonymous
Read-only: yes
Required arguments: ecz_id
What it does: Builds the deterministic public proof and re-check URL for an identifier. It makes no network call, so it cannot itself be a source of staleness.

explain_status

Access: anonymous
Read-only: yes
Required arguments: ecz_id
What it does: Renders a status in the approved neutral wording, deterministically and without a language model. Where evidence is absent it says so, and it never says unsafe.

find_product

Access: anonymous
Read-only: yes
Required arguments: none
What it does: Takes optional context flags and routes to the single best next ECZ-ID action. It returns one action rather than a ranked list, because ranking would make this a recommendation surface.

get_install_instructions

Access: anonymous
Read-only: yes
Required arguments: product
What it does: Returns the official install and usage routes for a named ECZ-ID product. This tool is the estate's own machine-readable install index, and no page may contradict it.

create_request_to_resolve

Access: OAuth2 bearer
Read-only: no
Required arguments: target_type, target_descriptor, requested_evidence_category, consent_mode
What it does: Opens a neutral Request-to-Resolve record. That record is not authoritative ECZ-ID state, it confers no status on anyone, and creating one is not a verification, an application or an approval.

Every tool the Trust MCP Server exposes, with its access model, whether it is read-only, its required arguments and what it does.
Tool	Access	Read-only	Required arguments	What it does
resolve_identity	anonymous	yes	ecz_id	Resolves an ECZ-ID to its current published state, the moment it was checked, the public proof link and the re-check action. Never asserts safety, approval or compliance.
get_current_state	anonymous	yes	ecz_id	Returns the narrow current state derived from the resolver projection, with no risk, safety or compliance inference attached to it.
get_resolver_link	anonymous	yes	ecz_id	Builds the deterministic public proof and re-check URL for an identifier. It makes no network call, so it cannot itself be a source of staleness.
explain_status	anonymous	yes	ecz_id	Renders a status in the approved neutral wording, deterministically and without a language model. Where evidence is absent it says so, and it never says unsafe.
find_product	anonymous	yes	none	Takes optional context flags and routes to the single best next ECZ-ID action. It returns one action rather than a ranked list, because ranking would make this a recommendation surface.
get_install_instructions	anonymous	yes	product	Returns the official install and usage routes for a named ECZ-ID product. This tool is the estate's own machine-readable install index, and no page may contradict it.
create_request_to_resolve	OAuth2 bearer	no	target_type, target_descriptor, requested_evidence_category, consent_mode	Opens a neutral Request-to-Resolve record. That record is not authoritative ECZ-ID state, it confers no status on anyone, and creating one is not a verification, an application or an approval.

Claims discipline is in the tool descriptions themselves

The strongest available evidence that the layer's anti-overclaim posture is real rather than marketing is that it is encoded at the protocol level, where no page editor can soften it. These four lines are quoted from the frozen contract.

resolve_identity — Never asserts safety, approval or compliance.
get_current_state — No risk/safety/compliance inference.
explain_status — VERIFIED is an ECZ-ID state, not a Microsoft certification. Absence of evidence renders the approved neutral wording — never “unsafe”. No LLM.
get_resolver_link — No network call.

The one protected tool

What the token proves, and what it does not

One tool of the seven requires a bearer token. Everything about how that token is obtained is a deployment choice, and the contract says so — which is what keeps this surface provider-neutral rather than tied to one identity vendor.

Scheme: OAuth2 bearer token, presented in the Authorization header. A missing token is answered with 401 and a WWW-Authenticate challenge.
Scope: api://16aef5c0-300c-471a-a6da-be4a822ac471/RequestToResolve.Create
Protected Resource Metadata: RFC 9728 metadata is published and live. The 401 challenge advertises the unsuffixed location, /.well-known/oauth-protected-resource, while the RFC 9728 path-derived location for this resource is the /mcp-suffixed variant. Both return 200. Neither is stale; this deployment simply chooses to advertise the shorter one.
Authorisation server: This deployment uses Microsoft Entra as its authorisation server. Entra is a deployment profile and is explicitly not part of the canonical contract: another operator may substitute any RFC 9728-compliant authorisation server and serve the same contract unchanged.

Platform authentication is not ECZ-ID verification

A token proves that a caller was authorised by an authorisation server to make a request. It says nothing about identity, authority, control or reliance, and the server's own challenge message states as much. An authorisation failure is never an ECZ-ID judgement about anybody, and a successful call is never an endorsement of anything.

create_request_to_resolve is the only tool that changes anything, and what it changes is not canonical. It opens a neutral Request-to-Resolve record, which is not authoritative ECZ-ID state. Canonical state is written in ECZ-ID Core and nowhere else; the Resolver publishes a read-only projection of it; this server reads that projection. No tool on this surface writes truth.

You want the schemas

Reference documentation for every ECZ-ID interface lives at the ECZ-ID Developer Gateway, which is a separate host and the canonical place for schemas.

ECZ-ID Developer Gateway

You want to check a target from CI

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

For developers

You want to read a real record

The ECZ-ID Resolver is the proof surface, and the only place in this estate where proof is read. Everything this server returns can be checked there.

Open ECZ-GB-RBS1NW at the Resolver

This page documents one surface. The layer it belongs to, and the other surfaces of that layer, are explained on the layer page. What ECZ-ID Trust MCP is