Updated 2026-11-03: the dispute retention record a verifier keeps for an agent presentation it accepts. Updated 2026-10-26: the MCP server also runs over Streamable HTTP. Updated 2026-10-19: the operator’s name.
On the agentic web, the unit of consumption is the tool. According to their own announcements, Anthropic’s finance agents ship wired to MCP connectors, and Cloudflare’s Monetization Gateway meters and monetises MCP tools at the edge. When an agent reaches for a tool listing, anything in its workflow has to be a tool. Identity verification is no exception.
The MintID client family now includes a Model Context Protocol (MCP) server. It exposes MintID verification to any MCP-capable framework as three tools over stdio or Streamable HTTP, and it follows the same architecture as the existing clients.
The server exposes only the frozen verifier-service contract
The server exposes only three of the four operations of the frozen verifier-service contract: build info, create challenge, and validate presentation (not the status-root re-check). An agent runtime can drive the full flow from challenge to presentation to decision without custom glue code. The agent framework does not need to learn OpenID4VP or the underlying HTTP contract.
The server is strictly a transport layer. It wraps the existing TypeScript client, which is its only dependency, and adds zero external runtime dependencies. It contains no cryptography and no policy. The verifying core generates the nonce, the session id and the ten-second expiry. No tool argument can carry or change them. The contract itself is untouched. Every client speaks this same versioned contract.
How the MCP server returns rejection reason codes
The part that matters most is what happens when verification fails. In the MintID clients, a rejection is a decision, not an error. Many integrations lose that distinction at the first protocol boundary, where every non-happy path collapses into an exception and the caller learns only that something went wrong.
The MCP server preserves this distinction. A presentation can fail because of a replayed nonce, a stale status root, or a missing predicate. A status root is the small signed summary an issuer publishes on the chain to say which credentials are still valid. When an agent submits a failing presentation, the tool call succeeds and returns a rejection with a reason code from the same closed vocabulary every other client sees. Only transport failures are tool errors. These occur when the service cannot parse a body, or when proven chain state is unavailable and the service fails closed.
An agent that receives a rejection with a named reason code can act on it: ask the holder for a fresher presentation, escalate to a human, decline the transaction, or log a decision. An agent that receives a generic error can only retry blindly, which triggers rate limiters and fraud alerts.
Running the MCP server inside your own infrastructure
Registration is one entry in your agent runtime’s MCP configuration, and the only thing it needs is the address of your own verifier service.
The MCP server runs inside your own perimeter as part of your verifier deployment and points exclusively at your own service instance. There is no MintID endpoint in the path. As Embedded, not hosted explains, the rule is about who decides. The registered verifier, the service registered on the chain to check proofs, makes the decision. The MCP layer only carries it. The MCP server persists nothing and logs nothing. Your verifier service keeps the only decision record and, for an agent presentation it accepts, the dispute retention record, kept for the claim window and never published.
The MCP server wraps a client, so it cannot skip a check
MintID’s multi-language strategy is deliberately conservative. One verification pipeline is embedded in Python, and thin clients delegate to a verifier service you host. The MCP server applies the same rule one layer up by wrapping the TypeScript client. Neither of them verifies anything, so neither can skip an acceptance condition.
What this adds is direct access for agent runtimes. Until now, integrating MintID required a backend engineer to write code against the HTTP contract. Now an agent framework can list verification alongside its other tools, and an autonomous workflow can check whether its counterparty is backed by an accountable human the same way it calls any other tool. This provides a direct tool-call integration for agent KYC.
MintID runs on the single-node production chain, which has been in production since 20 September 2026 and is operated by Conectia. The proof core sits behind the verifier service, and this connector changes nothing about how a proof is checked. It adds the transport, the contract and the decision vocabulary, built and tested. The integration docs say exactly which is which.