Skip to main content

ECZ-ID Trust MCP · The trust layer for the MCP economy

Give every MCP server and tool an identity that can be independently resolved.

One public ECZ-ID for each MCP server, linked to the organisation that operates it — so every tool a client discovers resolves to a server and an accountable operator. Anyone can open the current record and re-check it before relying on it. OAuth, your identity provider, MCP authorization and your runtime controls keep their jobs; ECZ-ID resolves who is behind them.

Get a FREE MCP Passport (continues on trustops.ecocitizenz.com)

The MCP Passport is free — no card, and not a trial. Professional services and products are separate.

Verify an MCP serverConnect to Trust MCPAdd your MCP identityBuild with ECZ-ID

Neutral layer. Public resolver record. Re-check before reliance.

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

Free · Permanent · No card

Get a free MCP Passport.

A persistent, canonical ECZ-ID for your MCP server — a public identity that resolves live, with a badge, a QR code and a Publish Kit. One sign-in. Nothing to pay.

  • It records that your MCP server exists and that your organisation claims it.
  • It is self-declared. It does not say your server is verified, assured, safe or approved.
  • It is not MCP Trust, not an assurance product, and not for sale.
Get a FREE MCP Passport (continues on trustops.ecocitizenz.com)Sign in — Manage from your ECZ-ID account (opens in a new tab — trustops.ecocitizenz.com)

In TrustOps’ own words, from the free MCP Passport door.

Included free

  • A permanent ECZ-ID for this MCP server
  • A live public Resolver page
  • A canonical machine-readable record
  • A website badge and a QR code
  • Publish Kit for your server’s well-known file and MCP Registry listing
  • Manage from your ECZ-ID account

Nothing is published until you confirm it.

One MCP server, one Passport

For example, your company’s MCP server has one Passport; each tool inside it, and each endpoint or deployment, is not a new Passport.

A new tool, endpoint, deployment or replica is not a new Passport.

The problem

An MCP client connects to whatever it is pointed at.

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.

An endpoint is not an operator.
A URL tells an agent where to send bytes. It does not say which legal entity stands behind them, in which jurisdiction, or whether anyone has ever said so on the record.
Configuration is copied, not checked.
Server entries travel through READMEs, gists, screenshots, forum answers and agent-generated config files. Provenance does not travel with them, and by the third copy nobody remembers where the first one came from.
Authority gets assumed from access.
A token that works proves a credential was accepted. It does not record what the holder was authorised to do, on whose behalf, or whether that authority is still in force.
Evidence is private, so outsiders cannot use it.
The operator's logs sit inside the operator's own systems. The people who most need them — a customer, their auditor, their insurer — are exactly the people who cannot read them.
State is a moment, and moments expire.
Whatever an approval was based on may not hold at the next call. Without a record that can be re-checked from outside, a change of state is something you find out about afterwards.

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.

Use cases

Serious MCP jobs, each with what serves it

Publishing to registries, allow-listing servers, pre-checking a tool call, knowing who answers for a third-party server, migrating to the current protocol.

All MCP use cases

Operator · Server · Tool

Accountability a client can resolve, not assume.

MCP tells a client what a server can do. It does not tell the client who stands behind it. ECZ-ID publishes that chain as records anyone can open — the operator, the server, and the tools the server exposes.

  1. Which organisation is accountable?

    Operator

    The organisation that operates the server, published once as its Parent record — with the provenance of each field and the date it was checked.

    Resolved by: Parent record (ECZ-ID Business Passport)

    A named operator is not an approved operator. Parent verification verifies the organisation, never the server.

  2. Which MCP server is this, whatever its URL?

    Server

    One MCP Passport for one logical MCP server. Endpoints, versions, deployments and registry listings are bindings on that record, not new identities, so the identity does not move when the URL does.

    Resolved by: MCP Passport (free)

    A binding shows a declared relationship. It does not grant, prove or imply authority to act.

  3. Who answers for this tool?

    Tool

    Every tool a client finds through tools/list is exposed by a server. The tool resolves through that server's MCP Passport to the operator accountable for both — the chain a reviewer, a host or an agent can follow before a call is made.

    Resolved by: The exposing server's MCP Passport

    Resolving who answers for a tool says nothing about whether the tool is safe. Tool-surface risk is assessed by review, not by identity.

Current public proof

Proof that is current when you check it — and checkable by anyone.

  • Current, not cached

    The Resolver publishes the record's current state, with the time it was read. The badge is drawn from that state when it is requested, never from a copy on this site.

  • Independently re-checkable

    A human page and a machine JSON record for every ECZ-ID, with no account and no API key. A relying party never has to take this site's word — or the operator's — for it.

  • Honest about absence

    No public ECZ-ID found is not a finding. It means the identifier resolves to no published record — nothing more.

Current proof comes from the Resolver. Verify current state before relying on it.

The binding chain

How an MCP server is bound to an accountable identity.

Six links, each one something a relying party can open or re-check. The chain runs from the organisation through the server to what it exposes — and it stops short of authorising anything.

  1. Organisation / operator

    Parent record — free DECLARED; VERIFIED and ASSURED optional

    The organisation accountable for the server. One Parent carries every Passport the organisation holds.

  2. MCP Passport

    A free child ECZ-ID under the Parent

    One MCP Passport for one logical MCP server. It links the server to its operator and does not move when the server's URL does.

  3. MCP server

    Bindings, and /.well-known/ecz-mcp.json on the host

    The places the server already appears — the host that serves the endpoint, its repository, its registry entry, its documentation — are recorded as bindings. On the host, the identifier is published at /.well-known/ecz-mcp.json.

  4. Tools and capabilities

    Exposed by the server, discovered through tools/list

    Tools resolve through the server that exposes them. A tool does not receive a separate Passport merely because it is a tool.

  5. Resolver

    The public record, for people and machines

    Anyone opens the current record on the public Resolver, with no account, and re-checks it before relying on it. The identifier is what resolves — not the file.

  6. Graph, Watch and evidence

    Graph Intelligence · Watch · LedgerCore

    Relationships to the agents that call the server and the APIs and packages around it; change signals when the record moves; lifecycle evidence kept with its time.

What the manifest file does, precisely

The ECZ-ID MCP Verifier recognises a URL ending in /.well-known/ecz-mcp.json and classifies the target as an MCP server. It does not fetch or parse the file, and a public Resolver lookup runs only for a valid ECZ-ID. Publish the identifier where a relying party will read it, and expect them to resolve the identifier rather than the file.

What the file contains, and how it names the operator, is defined on the ECZ-ID Developer Gateway, which publishes the canonical MCP declaration example. This site does not restate its fields.

The canonical MCP declaration example on the Developer Gateway (opens in a new tab — developers.ecocitizenz.com)

Identity is not runtime authorisation

Resolving who operates a server grants no permission to call it or any of its tools. OAuth, your identity provider, MCP authorization and your runtime mediation still decide every call; ECZ-ID replaces none of them.

The full provider journey, step by step

Parent + seven families

A free identity for every MCP server, and for the organisation behind it.

An MCP server rarely stands alone: agents call it, an API sits behind it, a plugin or a package distributes it, a workload runs it. Each is its own subject with its own free Passport, and every Passport links to the same Parent.

Get a FREE MCP Passport (continues on trustops.ecocitizenz.com)

Free · Permanent · No card

Passport identity is free. Capacity, monitoring, evidence, assurance and specialist services are separate.

Other free starts

Free Watch, MCP Trust Community and the Free Trust Check

Free tools from the same estate, as TrustOps lists them today. None of them creates an ECZ-ID, and none is proof on its own: each points you back to the Resolver.

What every free Passport includes, and how the Parent and seven families fit together

The chain

Where the layer sits — and where it deliberately does not.

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.

  1. AI AGENT

    Decides to use a capability. Holds no independent view of who provides it.

  2. MCP CLIENT

    Holds the server configuration and opens the connection.

  3. MCP SERVER

    Answers. Its URL is a location, not an identity.

  4. ECZ-ID TRUST LAYER

    Records identity, authority, evidence and current state against an ECZ-ID. Writes nothing into the call.

  5. RESOLVER

    Publishes a read-only projection of that record at one canonical URL for people and one for machines.

  6. IDENTITY + AUTHORITY + EVIDENCE

    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 neutral record, and eight things it is deliberately not.

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.

What ECZ-ID Trust MCP is

  • A neutral identity, authority, evidence and current-state layer for MCP.
  • A public record with a canonical URL for a person and a canonical URL for a machine, resolvable by anyone, without an account.
  • A vocabulary that publishes its own limits. Every record states what may be relied on and what must not be inferred, in the record itself.
  • Read-only in public. Authoritative state is written only by ECZ-ID Backend/Core; the Resolver renders a permitted projection of it and is never the source.

What it is not

  • Not an MCP security scanner. It inspects nothing, probes nothing and executes nothing.
  • Not a certification authority. There is no ECZ-ID certificate and no approval to be granted.
  • Not a trust score. There is no rating, grade, percentage or traffic light anywhere in the record.
  • Not a marketplace or a directory of approved servers. Presence is not endorsement, and absence is not a finding.
  • Not an identity provider. It does not issue, hold, replace or resell your credentials.
  • Not a gateway, a proxy or a firewall. It is never in the execution path.
  • Not a replacement for your security controls. It is designed to sit alongside them.
  • Not a compliance requirement. No regulation names ECZ-ID, and using it makes you compliant with nothing.

Identity · Authority · Evidence · Current state · Resolution

What the layer actually records.

Five things, each published on the record itself rather than described about it. ECZ-ID Core defines what each one means and the ECZ-ID Developer Gateway documents exactly how a machine reads it — this page explains them, and links there for the field names.

  1. Identity

    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.

  2. Authority

    What the operator has recorded about who acts on its behalf — and, read beside it but never as authority, what has been bound and 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.

  3. Evidence

    Whether a public receipt exists and how many — and the record states whether, and when, its evidence was anchored.

    A receipt shows what was recorded and when. It does not make the thing recorded true, approved, safe or well-run.

  4. Current state

    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.

  5. Resolution

    One canonical URL a person can open and one a machine can parse, for an identifier whose format is defined by ECZ-ID Core and documented on the ECZ-ID Developer Gateway — 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.

Field reference on the Developer Gateway

What a machine should read

Each record tells machines which states to fail closed on and which parts of the record to read. Read the current lists from the live record, never from a copy — including any copy on this website.

Read the current lists in the live machine record

Those lists 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.

Beside your stack, not in its path

ECZ-ID replaces none of the controls you already run.

ECZ-ID complements OAuth, your identity provider, MCP authorization and runtime mediation such as gateways and policy enforcement. It replaces none of them and stays outside the execution path.

  • OAuth

    Its job: Issues and checks the tokens that let a client call a protected server.

    What ECZ-ID adds: Publishes which server and which operator the token is presented to. It issues no tokens.

  • Your identity provider

    Its job: Authenticates your people and workloads and federates them.

    What ECZ-ID adds: Publishes the organisation and the machine identities others can resolve. It authenticates nobody.

  • MCP authorization

    Its job: Decides, per the protocol, whether a given caller may connect and what it may call.

    What ECZ-ID adds: Adds who operates the server on the other side of that decision. It grants and denies nothing.

  • Runtime mediation

    Its job: Gateways, proxies and policy enforcement points allow, block and log calls in the path.

    What ECZ-ID adds: Gives your policy a public record to read. It sits outside the execution path and blocks nothing.

Live proof

A real record you can resolve right now.

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, copied from the record 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.

Transcript of ECZ-GB-RBS1NW, captured 2026-10-08T13:41:54Z. Not proof.

ECZ-ID
ECZ-GB-RBS1NW
Record type
ECZ_ID_PARENT
Lifecycle state
ACTIVE
Parent tier
VERIFIED
Reliance level
PARENT_IDENTITY_ONLY
Binding state
NO_PUBLIC_PROOF
Agent trust
AGENT_CREDENTIAL_MISSING
Receipts
0 public · 1 recorded
Profile state
PROFILE_COMPLETE
Freshness
UNDETERMINABLE
Legal name
ECOCITIZENZ LTD
Company number
17348848
Incorporated
20 July 2026
Registered office
66 Paul Street, London EC2A 4NA, United Kingdom
Jurisdiction
United Kingdom
Transcript captured
2026-10-08T13:41:54Z

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 Verified parent ECZ-ID. No public binding or evidence proof on this record.

What you may rely on

reliance.can_rely_on

  • record_existence
  • active_parent_state
  • current_parent_tier
  • public_resolver_visibility

What you must not infer

reliance.do_not_infer

  • legal_name
  • domain_control
  • api_control
  • repository_control
  • wallet_control
  • asset_control
  • agent_authority
  • insurance
  • regulatory_approval
  • safety
  • compliance
  • business_quality
  • live_operational_monitoring

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.

Open the live record on the ResolverRead the machine record (JSON)

Proof & evidence

Resolve before reliance

Verify an ECZ-ID (opens in a new tab — resolver.ecocitizenz.org)
  • The Resolver is the live public proof: anyone re-checks a record there, with no account.
  • The machine-readable record is a deterministic projection of the same record, for tools and agents.
  • A badge or a QR code is a route back to the live proof, never proof on its own.

Deterministic and local-first

Tools that give the same answer twice, and keep your data where it is.

The tooling around the layer is built to be predictable and private: rules rather than models where a verdict would matter, and your configuration kept on your own machine.

  • In-browser

    Config Check

    Reads a pasted MCP configuration passively, in your browser. Nothing you paste is uploaded or executed, and no endpoint is contacted without your explicit consent.

    How Config Check works

  • CI and command line

    ECZ-ID MCP Verifier

    Classifies a target with rules, not a model, and returns a canonical result state and exit code under your own OPEN, PREFER or REQUIRE policy. Offline runs make no network call, and it uploads no source, secrets or telemetry.

    How ECZ-ID MCP Verifier works

  • Editor

    ECZ-ID MCP Trust

    A VS Code extension that inventories the MCP configuration on your own machine and shows what changed. It publishes nothing about your servers.

    How ECZ-ID MCP Trust works

  • Machine surface

    Trust MCP Server

    Seven tools; six are anonymous and read-only. Proof URLs are built without a network call, and status wording is rendered by rules, without a language model.

    How Trust MCP Server works

ECZ-ID Developer Trust

ECZ-ID MCP Trust and the ECZ-ID MCP Verifier are part of ECZ-ID Developer Trust. Documentation lives on the Developer Gateway, which this site links to rather than copies; Pro tier prices come from the TrustOps commerce registry, and each tier TrustOps sells is bought through TrustOps' own checkout.

ECZ-ID Developer Trust on the Developer Gateway (opens in a new tab — developers.ecocitizenz.com)Which Developer Trust product fits what you are building

OBSERVED · UNMANAGED · ENFORCED

Three different things. The layer observes and publishes; your policy enforces.

OBSERVED
A state the layer has seen and published on a record — with its time and its basis. A fact about a record, readable by anyone.
UNMANAGED
An MCP server in use — found, say, by local-first inspection of a configuration — that no accountable operator has bound to an identity and no policy of yours covers. A gap to close, not a finding against the server.
ENFORCED
An allow or deny decision made in a runtime: your gateway, your client policy, your pipeline. ECZ-ID never claims enforcement it does not perform.
  • Identity is not approval.
  • DECLARED is not VERIFIED.
  • OBSERVED is not ENFORCED.
  • UNMANAGED is not a finding.

Three ways in

Whichever end of the connection you are on.

The same record serves three different jobs. Start from the one you actually have.

  • Developers

    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.

    Build with ECZ-ID

  • MCP providers

    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.

    Add your MCP identity

  • Enterprise

    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.

    See the enterprise view

The full picture — what the layer records, what it refuses to record, and why About ECZ-ID Trust MCP

MACHINE INTERFACE

Structured access for automated clients and interoperable systems.

InterfaceManifestResolve

The Trust MCP Server, in facts

Endpoint
https://trust-mcp.ecocitizenz.com/mcp
Transport
Streamable HTTP
RPC
JSON-RPC 2.0
Protocol
2026-07-28 (primary) · 2025-11-25 (legacy)
Contract
The ECZ-ID Trust MCP Contract — frozen at milestone MS-032 on 19 August 2026, provider-neutral
Tools
6 anonymous read-only · 1 OAuth2-protected
Authorization
OAuth2 bearer · scope RequestToResolve.Create · RFC 9728 Protected Resource Metadata

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.

The seven tools of the Trust MCP Server, with the access model, whether each one writes, and what it does
ToolAccessWritesWhat it does
resolve_identityanonymousnoResolves 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_stateanonymousnoReturns the narrow, resolver-derived current state and nothing else.
get_resolver_linkanonymousnoBuilds the deterministic public proof and re-check URL for an ECZ-ID. Makes no network call.
explain_statusanonymousnoRenders a status in approved, claims-safe wording. Deterministic — no model is involved. Absence of evidence renders the neutral wording, never “unsafe”.
find_productanonymousnoRoutes to the single best next ECZ-ID product action for a stated situation.
get_install_instructionsanonymousnoReturns install and usage instructions for a named ECZ-ID product.
create_request_to_resolveOAuth2 beareryes — a neutral request recordCreates 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.

Four real ways to verify — none of them on this page.

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.

  • ECZ-ID MCP Verifier — CI and CLI surface

    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>

    ECZ-ID MCP Verifier on npm

  • ECZ-ID MCP Verifier — GitHub Action surface

    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.

    The Action, in the ECZ-ID MCP Verifier repository

  • Trust MCP Server — machine surface

    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.

    The Trust MCP Server endpoint

  • ECZ-ID Resolver — proof surface

    You already have an ECZ-ID and you just want to read the record.

    Open the canonical URL for the identifier. The identifier format is defined by ECZ-ID Core and documented on the ECZ-ID Developer Gateway. No account, no key, no rate limit to negotiate.

    The ECZ-ID Resolver

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

The layer is free to read. Getting your MCP surface onto it is work you can buy.

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.

Fixed-scope services — available now, published prices, full scope up front

Professional services

Fixed-scope MCP professional services. Published prices. Full scope before you commit.

Every service publishes its scope, deliverables, acceptance criteria and price before you pay. Start online through TrustOps — no sales call required.

Start here

MCP Readiness Audit

£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.

  • Teams with a working MCP server or integration that has not yet faced production traffic, security review or procurement.
  • Engineering leads who need an independent, vendor-neutral view before committing to a rollout.
Start the audit — £395Continues on trustops.ecocitizenz.com for order review before any payment step.
Full scope, exclusions and deliverables

Stateless Migration Sprint

£1,950 total

£1,170 at checkout + £780 on acceptance

TrustOps also names this engagement MCP Protocol Migration & Modernisation Sprint — the same engagement, bought as the Stateless Migration Sprint: £1,950 total. One-off engagement, paid in stages; £1,170 due now, then 1 later milestone.

A bounded, hands-on migration of one existing MCP implementation to a stateless, deployment-safe architecture — implemented, tested and documented.

  • Teams with a working MCP server built on session-bound or legacy patterns that block horizontal scaling, serverless deployment or client upgrades.
  • Teams that need the migration done, not just described — brownfield work on your existing code, in your repository.
Start the migration — £1,170Continues on trustops.ecocitizenz.com for order review before any payment step.
Full scope, exclusions and deliverables

EMA/ID-JAG Design & Pilot

from £3,500 total

£1,750 at checkout, then 1 later milestone 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.

  • Platform and security teams rolling MCP out inside an organisation with an existing identity provider (for example Okta, Microsoft Entra ID or Ping).
  • Teams that need per-user, per-agent authorization boundaries rather than shared static credentials.
Start the identity pilot — £1,750Continues on trustops.ecocitizenz.com for order review before any payment step.
Full scope, exclusions and deliverables

Enterprise MCP Pilot

£6,500 total

£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.

  • Organisations that need MCP evaluated and piloted properly: architecture, identity, governance and evidence — not a demo.
  • Teams whose security and procurement functions must sign off before production use.
Start the enterprise pilot — £2,600Continues on trustops.ecocitizenz.com for order review before any payment step.
Full scope, exclusions and deliverables

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.

Start the £395 Readiness AuditChoose a service

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.

Side-by-side comparison

Readiness Audit

£395
Best for
Independent assessment before production
Payment
100% upfront, paid in full
Code changes
No — report & plan
Real-client testing
Compatibility assessment
Evidence Pack
Audit edition
Typical duration
5 working days

Migration Sprint

£1,950 total
Best for
Hands-on migration of an existing server
Payment
Paid in stages: £1,170 due now, then 1 later milestone (£780 on acceptance)
Code changes
Yes — in your repo
Real-client testing
Named clients verified
Evidence Pack
Migration edition
Typical duration
10 working days

Identity Design & Pilot

from £3,500 total
Best for
Enterprise identity & authorization design
Payment
Paid in stages: £1,750 due now, then 1 later milestone
Code changes
Pilot implementation
Real-client testing
Agreed pilot clients
Evidence Pack
Identity edition
Typical duration
Design ~10 working days; pilot per scope

Enterprise Pilot

£6,500 total
Best for
Full pilot with procurement-grade evidence
Payment
Paid in stages: £2,600 due now, then 2 later milestones (30% + 30%)
Code changes
Pilot implementation
Real-client testing
Named clients verified
Evidence Pack
Enterprise edition
Typical duration
Fixed in written scope

Operate this Passport

Operate the MCP servers you run: MCP Assurance, Assurance Plus and Policy

Three MCP plans operated by TrustOps, over production MCP targets that are your own free MCP Passports. What each plan operates is TrustOps' own description.

Authority & intent

State what a server may do, and evaluate each tool call against it

Intent states the authorised boundary; Intent Control evaluates a proposed action against it; the combined plan does both; Receipts keeps what the activity produces. Every decision is EVALUATED unless an inline enforcement point reports mediating the action.

Products

Turn MCP evidence into something a customer can use.

The flagship kit is the direct MCP product. Workflow bundles cover problems that span several entity types, and DCI, DORA and SBOM solve the business problem above the identity.

Flagship · MCP specialist kit

ECZ-ID MCP Security & Customer Assurance Kit

  • Paid · Open

A practical MCP evidence product for vendors and internal platform teams that have to answer the same security, identity and procurement questions for every customer — who operates the server, which tools it exposes, how authorisation is configured, what has been observed and what is actually enforced — without rebuilding the pack for each review.

  • MCP identity and operator evidence: the server's MCP Passport, its Parent record and the bindings a reviewer can re-check on the Resolver.
  • A tool-surface review structure: tool inventory, schemas, input validation, destructive-action safeguards and the provenance of tool descriptions.
  • Authorisation and deployment evidence prompts: how OAuth-based MCP authorization, transport and session state are configured — documented, not replaced.
  • An OBSERVED-versus-ENFORCED register, so every control is stated as either a published observation or an enforcement your own runtime performs.
  • Customer-facing assurance artefacts: a review pack, questionnaire-to-evidence mapping and a Resolver proof page to point reviewers at.

The kit is an evidence product, not a certification of MCP security.

Scope and boundariesBuy Company — ECZ-ID MCP Security & Customer Assurance Kit (continues on trustops.ecocitizenz.com)

Workflow bundles

DCI, DORA and SBOM — the business problem above the identity

Each sits on the same free MCP Passport and shared ECZ-ID infrastructure. None is required to hold a Passport, and each states its evidence boundary.

Operate the estate: the same products for every Passport family

The same products and entitlements serve all seven Passport families. There is no MCP edition — only MCP examples.

  • Scale

    AEC

    An MCP server you actively manage in production, with live bindings and current state, counts as one active entity — in the same pool as your agents, APIs and other identities.

  • Current state

    PulseGuard

    For an MCP server: its record's lifecycle and binding state evaluated on demand, with the basis shown, so an operator sees which servers need attention before a customer's re-check does.

  • Evidence

    LedgerCore

    For an MCP server: when its binding or operator changes, the lifecycle event is kept with its time, so a customer's reviewer can see what was recorded and when.

  • Relationships

    Graph Intelligence

    For an MCP server: the path from the server to its operator, the agents that call it, the API behind it and the package that ships it — each a distinct identity.

  • Change awareness

    Watch

    For a team whose agents rely on third-party MCP servers: follow each server's ECZ-ID, see what changed, and re-check the Resolver when its operator, binding or state has changed.

  • Retained receipts

    Receipts

    For an MCP server: keep the receipts its ECZ-ID activity produced, so a customer's reviewer can see what was recorded about the server, and when.

  • Authorised objective

    Intent

    For an MCP server: record the objective and the constraints its tools may act within, authorised by your organisation's owner or administrator.

  • Action evaluation

    Intent Control

    For an MCP server: evaluate a proposed tool call against the server's Intent and your policy before the call is made, and keep the EVALUATED decision.

  • Boundary and evaluation, one plan

    Intent + Intent Control

    For an MCP server: state what its tools may act on, then evaluate each proposed tool call against that boundary and your policy before the call is made.

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal.

All MCP products, including the platform capabilities

Included, not sold separately

Included with every paid MCP service

Every paid engagement includes 90-day access to the ECZ-ID Business Passport — 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. TrustOps states the inclusion in its own words; for the MCP Readiness Audit: “Included: 90 days of Verified ECZ-ID Business Passport plan access.” Plan access is a commercial entitlement, not record state: TrustOps holds the entitlement, while the public record is written by ECZ-ID Core and published by the Resolver.

  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.

90-day experience included with every paid engagement. See how Resolver proof works (opens in a new tab — resolver.ecocitizenz.org). See the technical documentation for ECZ-ID evidence-state definitions or the field classes in detail.

Continuation, not part of the fixed-scope services

After delivery: an ongoing evidence posture

A fixed-scope engagement ends. Your MCP surface keeps changing. These ongoing ECZ-ID packages are operated by TrustOps and track the binding state, tool-list fingerprint and drift of your production MCP targets, with an exportable evidence pack, after we hand over — they are a continuation route, not part of the fixed-scope 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

    Track one production MCP target: its binding state, tool-list fingerprint and drift, with a daily re-check and an exportable evidence pack.

    Providers whose customers re-check them.

  • ECZ-ID MCP Assurance Plus™

    £499/month

    Track up to 5 production MCP targets — binding state, tool-list fingerprint, drift and linked repository / package relationships — with an exportable evidence pack.

    Providers operating several production MCP targets.

  • ECZ-ID MCP Policy™

    £1,499/month

    Express posture rules over up to 10 production MCP targets under your organisation’s own authority, evaluated by TrustOps and exportable from your console.

    Organisations that need posture rules over their MCP targets, under their own authority.

The four professional services above are fixed-scope engagements with published prices 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 (opens in a new tab — trustops.ecocitizenz.com).

Resources

MCP briefings, free to read

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.

All resources

FAQ

The questions buyers actually ask

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.

Can I buy without a sales call?

Yes. Every service publishes its price and full scope — a fixed price, or, where it is shown as “from”, a published minimum with the final scope and price confirmed in writing — 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.

What happens immediately after I pay?

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.

Who actually does the work?

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.

Are there discounts or promotional codes?

No. The professional services on this site are fixed-scope engagements and are never discounted — the published price is the price everyone pays, and a price shown as “from” is the same published minimum for everyone, with the final total following the scope confirmed in writing. Any platform credit offered elsewhere in the EcoCitizenz ecosystem applies to eligible TrustOps subscription payments only, never to these engagements.

Which service should I start with?

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.

All questions, including refunds, VAT and access

Resolve first. Rely after.

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.

Get a FREE MCP Passport (continues on trustops.ecocitizenz.com)Verify an MCP serverStart the £395 Readiness Audit

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

Keep going

Where next on ECZ-ID MCP

Create free MCP Passport (continues on trustops.ecocitizenz.com)