In regulated environments, AI agents must prove who they are and exchange verified information with individuals and legal entities. We provide compliant tools to AI agents via the Model Context Protocol so agents can request, verify and use claims—safely.
Agents increasingly act on behalf of people and organizations: they schedule, purchase, sign, and access data. In sectors like finance, health, mobility or public services, actions must be tied to an accountable identity and verifiable attestations (age, role, mandate, risk level, etc.).
EUDI + OIDC4VP allow wallets to present selective, privacy‑preserving claims. MCP makes these flows available to agents through simple tools.
Agents initiate a verifiable presentation, show a deep link / QR, then poll for verification and retrieve claims — all through MCP tools.
start_wallet_verification — create an OIDC4VP request; returns openid4vp:// deeplink and a QR (image block + structuredContent).poll_wallet_verification — check status (pending, verified, denied) and fetch claims.revoke_wallet_flow — acknowledge flow cleanup (TTL handled server‑side).Calls use Authorization: Bearer <token> or X-API-KEY. For public tests, token/key equals the verifier_id.
start_wallet_verificationThe MCP client requests a presentation from a user wallet. The request scope is bound to the verifier_id.
The agent shows the QR or link. The user scans with their wallet and consents to share data.
Agent calls poll_wallet_verification with session_id until status changes from pending.
When verified, the server returns verifiable data and metadata.
wallet_identifier → returns wallet_identifier (DID or JWK thumbprint)email → returns email_address (email)over18 → returns boolean over_18profile → returns family_name, given_name, birth_date# Example poll payloads
{ "status": "verified", "session_id": "...", "wallet_identifier": "did:jwk:..." }
{ "status": "verified", "session_id": "...", "email_address": "user@example.com" }
{ "status": "verified", "session_id": "...", "over_18": true }
{ "status": "verified", "session_id": "...", "family_name": "DOE", "given_name": "John", "birth_date": "1990-01-01" }
Only the fields relevant to the selected demo verifier will be present.
An agent requests a wallet presentation to obtain a wallet identifier and basic identity claims (name, over‑18). The agent then customizes interaction and access based on verified attributes.
Before executing actions (purchase, booking, data access), the agent verifies that the user holds a role or mandate (e.g., company officer) and logs the presentation reference for auditability.
For restricted services, the agent requests an over‑18 attestation without learning the birth date—preserving privacy.
Agents collect a verified email (or other claims) to follow up with users across channels while keeping raw tokens out of the agent context.
Gate downstream APIs (payments, health, mobility) with a short‑lived session that is unlocked only when the presentation is verified.
Record the presentation status and derived claims so human operators can trace what the agent knew when it acted.
Use public test profiles: verifier_id ∈ { 0000, 0001, 0002, 0003 }. The header token can be Authorization: Bearer <verifier_id> (or X-API-KEY: <verifier_id>). Each demo verifier has a default scope bound to it.
# 1) List tools
curl -s https://wallet-connectors.com/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# 2) Start verification (server can generate session_id)
curl -s https://wallet-connectors.com/mcp \
-H 'Content-Type: application/json' \
-H 'X-API-KEY: 0000' \
-d '{
"jsonrpc":"2.0",
"id":2,
"method":"tools/call",
"params":{
"name":"start_wallet_verification",
"arguments":{"verifier_id":"0000", "session_id": "user-1234"}
}
}'
# 3) Poll (use the session_id from step 2)
curl -s https://wallet-connectors.com/mcp \
-H 'Content-Type: application/json' \
-H 'X-API-KEY: 0000' \
-d '{
"jsonrpc":"2.0",
"id":3,
"method":"tools/call",
"params":{
"name":"poll_wallet_verification",
"arguments":{"session_id":"user-1234"}
}
}'
import json, requests
MCP_URL = "https://wallet-connectors.com/mcp"
HEADERS = {"Content-Type":"application/json", "X-API-KEY":"0000"}
# 1) start verification
payload = {
"jsonrpc":"2.0", "id":1, "method":"tools/call",
"params":{"name":"start_wallet_verification", "arguments":{"verifier_id":"0000","session_id":"user-1234"}}
}
start = requests.post(MCP_URL, headers=HEADERS, data=json.dumps(payload)).json()
content = start["result"]["structuredContent"]
print("Deep link:", content["deeplink_url"]) # show to user; also display QR from result.content[0]
# 2) poll until verified
poll = {
"jsonrpc":"2.0", "id":2, "method":"tools/call",
"params":{"name":"poll_wallet_verification", "arguments":{"session_id":"user-1234"}}
}
while True:
res = requests.post(MCP_URL, headers=HEADERS, data=json.dumps(poll)).json()
status = res["result"]["structuredContent"]["status"]
if status != "pending":
print(res["result"]["structuredContent"]) # claims here
break
The MCP server returns result.content (array of blocks) and result.structuredContent (machine JSON).
{
"result": {
"content": [
{"type":"image","data":"<base64png>","mimeType":"image/png"},
{"type":"text","text":"Scan the QR code or open wallet link: openid4vp://....."}
],
"structuredContent": {
"status": "pending",
"session_id": "3e02ac7e-da66-4dd1-9abe-30348dcc728f",
"deeplink_url": "openid4vp://.....?request_uri=https://.../request_uri/abc",
"pull_url": "https://wallet-connectors.com/verifier/wallet/pull/3e02..."
}
}
}
Only the start/poll/revoke actions are exposed to agents.
Raw tokens are not returned; the server exposes derived claims only.
Flows expire automatically in the verifier backend (Redis TTL). No data are stored on servers.
Use the MCP tools above or see /mcp/info for server metadata.