MCP server
@mintid-net/verifier-mcp gives an agent runtime three MCP tools over your own verifier service; a rejection comes back as a result the agent can reason about.
Overview
The tools decide nothing until your agency is a registered, active verifier with its exact origin and request key on chain; Getting started lists those steps.
@mintid-net/verifier-mcp is a Model Context Protocol (MCP) server you run inside your own perimeter, next to the verifier service you already deploy. Registered as a local MCP server in your agent runtime, it exposes three of the contract’s four operations (build information, challenge creation and presentation validation; not checkStatusRoot) as tools that any MCP-capable framework can list and call.
Like @mintid-net/verifier-client, which is its only dependency and its transport, it is transport-only: the cryptography, chain access, replay store and policy all stay in your verifier service, and the package pulls in no external runtime dependency. The single-use value, the session identifier and the ten-second expiry are generated by the verifying core; no tool argument can set them.
The three tools
One tool per operation it carries — no aggregate helpers, no convenience wrappers that could reorder a flow:
| Tool | Contract operation |
|---|---|
| build information | GET /v1/build-info |
| create a challenge | POST /v1/challenges |
| validate a presentation | POST /v1/presentations |
These three are the whole surface: the server exposes three of the contract’s four operations (not checkStatusRoot, the status-root re-check a session built on a decision runs; call it through the TypeScript client or plain HTTP) and nothing else.
The contract is untouched by this package: same request and response shapes, same closed reason-code vocabulary, same decisions as every other client in every other language.
Error semantics (the part that survives the protocol hop)
A rejection is a successful tool result. A presentation that fails — replayed nonce, stale status root, missing predicate — comes back as { accepted: false, reason_code }, so the calling agent can reason about why instead of retrying blindly.
Only transport failures are tool errors: a body the service cannot parse, proven chain state unavailable (fail-closed — retry later, never skip the check), or the service unreachable. Branch on the decision data.
Trust boundary
This server is part of your verifier deployment. Run it inside your perimeter, pointed exclusively at your own service instance: pointing it at anyone else’s service would hand them the acceptance decision, which is your obligation as a registered verifier.
The server persists nothing and logs nothing; your service keeps the only decision record.
The public testnet runs the server over Streamable HTTP in front of its sandbox verifier; its endpoint is in the packages’ network registry (MINTID_NETWORK=testnet) and given on request.
Whose decision it is. Challenges from this endpoint are bound to the testnet’s sandbox verifier, so its decisions belong to the testnet and carry no weight: the credentials it checks come from a KYC sandbox whose outcome the caller chooses. That makes it the right tool for exploring the flow and wiring an agent end to end, with credentials you obtain from the testnet’s sandbox (the public testnet). It is not a way to outsource your own verification. If a decision gates your business, run the server yourself, in front of the service you deploy. Pointing it at anyone else’s service would delegate the decision itself, and the protocol does not allow that. The single-node production chain is never a place to test; admitted verifiers run there under the published admission policy.
Run it yourself
Install it from npm (npm install @mintid-net/verifier-mcp, 0.4.0), or build it from the main project (sdk/mcp/, https://gitlab.com/mintid/mintid) or its read-only mirror (https://gitlab.com/mintid/verifier-mcp), alongside the service it talks to. The same package serves both transports: stdio, spawned by the agent runtime, and Streamable HTTP. The registration lines for Claude Code are the two forms beside this paragraph; the testnet's endpoint comes from the package's network registry (MINTID_NETWORK=testnet or --network testnet) and is given on request.
Authentication over HTTP. Any HTTP port reachable from beyond localhost requires a bearer token. --auth-token-env NAME takes a static token from the environment variable NAME (never from the command line; at least 32 characters); --oidc-issuer URL --oidc-audience AUD accepts JWT access tokens from your OIDC provider, checking the signature against the issuer's published keys, the issuer, the audience and the expiry. Every /mcp request then carries Authorization: Bearer <token>; without a valid one the answer is 401 with WWW-Authenticate: Bearer and a JSON error, and neither the response nor the logs ever carry the token. With neither option the endpoint is open, which is for localhost only. Recommended: the server inside your perimeter next to your service, TLS at the edge, and the token from your secret store or your identity provider. The stdio transport has no authentication: whoever spawns the process owns it.