This server exposes OIDC4VCI credential issuance capabilities to an AI agent via MCP, letting it inspect offers, discover issuer metadata, orchestrate issuance flows, and request credentials while keeping wallet/signing operations and credential contents out of the agent's context.
Inspect credential offers – Parse and validate an OIDC4VCI Credential Offer URI, returning the issuer, requested credential configuration IDs, and available grants.
Fetch credential issuer metadata – Retrieve and validate a Credential Issuer's well-known metadata, including credential endpoint, authorization servers, and supported credential configurations.
Describe issuance flows – Determine which grant-based flow applies to a credential offer and list the ordered steps needed to obtain the credentials.
Initiate issuance sessions – Start an issuance session; for pre-authorized code grants it completes the token exchange immediately, while authorization code grants pause waiting for user authorization.
Check issuance status – Get the current state of a previously started issuance session by session ID.
Request credentials – Complete the credential request for a session that has an access token, using the wallet adapter to generate proof of possession and handing the issued credential to the wallet without ever returning its contents to the agent.
Provides an agent-facing orchestration layer for OpenID for Verifiable Credential Issuance (OIDC4VCI) flows, enabling inspection of credential offers, discovery of credential issuer metadata, and initiation and tracking of credential issuance while keeping wallet-sensitive operations separate.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-oidc4vci Inspect this credential offer and explain what it's asking for."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project explores how the Model Context Protocol (MCP) can be used to expose capabilities from an OpenID for Verifiable Credential Issuance (OIDC4VCI) ecosystem to an AI agent. It targets OIDC4VCI 1.0 (final specification).
The goal is not to replace a wallet, nor to give an LLM access to private keys or unrestricted credentials. Instead, the project investigates a more constrained architecture:
An MCP server acts as an agent-facing orchestration layer for understanding and progressing through an OIDC4VCI credential issuance flow, while security-sensitive operations remain under the control of dedicated components such as the wallet or credential holder.
The project starts from a concrete scenario:
A user receives an OIDC4VCI Credential Offer and wants an AI agent to help understand what is being offered and guide or orchestrate the issuance process.
OIDC4VCI defines a protocol for issuing Verifiable Credentials to a wallet or credential holder. A typical flow involves a Credential Offer, a Credential Issuer and its metadata, an Authorization Server, authorization or pre-authorized flows, credential requests, proofs and cryptographic key binding, and credential delivery and storage — a significant amount of structured information for a user to parse on their own.
An AI agent can potentially help by understanding a credential offer, explaining what's being offered, discovering supported credential configurations, determining the required issuance flow, identifying what's needed next, and orchestrating non-sensitive protocol interactions.
The central question this project explores is:
How can OIDC4VCI capabilities be exposed to an AI agent through MCP without compromising the security boundaries of wallets and cryptographic key material?
For the full system design, see Architecture.
Related MCP server: Cheqd MCP Toolkit
AI Agent ──MCP──▶ OIDC4VCI MCP Server ──▶ Credential Issuer / Authorization Server
│
▼
Wallet Boundary
│
▼
Key Management / Proofs / User AuthorizationThe MCP server acts as an intermediary between the AI agent and the OIDC4VCI ecosystem — it should not automatically become a wallet. Sensitive operations (keys, proofs, consent) stay behind an explicit wallet boundary, never in the LLM context.
Full details, component responsibilities, data flows, tool contracts, and security requirements live in docs/ARCHITECTURE.md.
Feature | Status |
Credential Offer, by value or by reference | Supported |
Pre-Authorized Code Grant | Supported |
Authorization Code Grant | Supported |
PKCE (RFC 7636, | Supported |
Pushed Authorization Requests (RFC 9126) | Supported, auto-detected from Authorization Server metadata |
DPoP (RFC 9449) | Supported, auto-detected from Authorization Server metadata |
Rich Authorization Requests / | Supported, replaced by a |
Transaction Code ( | Supported |
Nonce Endpoint / | Supported |
| Supported |
| Not yet |
Deferred Credential Issuance | Supported |
Multiple credential configurations per offer | Supported — one Credential Request per configuration, one per tool call |
Signed (JWT) Credential Issuer Metadata | Supported — signature verified against the |
Credential Request/Response Encryption | Not yet |
Batch Credential Issuance | Not yet |
Notification Endpoint | Not yet — |
See docs/ARCHITECTURE.md for the design reasoning behind each of these.
This project is under active development. Here's what's implemented today.
Credential Offer inspection. inspect_credential_offer resolves a Credential Offer by value or by reference (credential_offer_uri), validates it against OIDC4VCI 1.0, and returns the issuer, requested credential configuration IDs, and grants. See src/mcp_oidc4vci/credential_offer.py.
Credential Issuer metadata discovery. get_credential_issuer_metadata fetches and validates a Credential Issuer's metadata from its well-known endpoint (correctly inserting the well-known path segment ahead of any path component in the issuer identifier, per spec), verifies the returned credential_issuer matches what was requested, and returns the credential endpoint, authorization servers, and supported credential configurations. It transparently handles either the unsigned JSON or the signed-JWT metadata representation (RFC 7515), verifying the JWS signature against the x5c certificate conveyed in the JOSE header — see Architecture for exactly what "verified" does and doesn't mean here (no certificate chain-of-trust validation is performed). See src/mcp_oidc4vci/credential_issuer_metadata.py.
Issuance flow orchestration. describe_issuance_flow, initiate_issuance, and get_issuance_status run on top of an in-memory IssuanceSessionStore. For the pre-authorized code grant, initiate_issuance completes the full Token Request end to end — OAuth Authorization Server discovery via RFC 8414, then the token exchange, including a DPoP proof of possession when the Authorization Server requires one. For the authorization code grant, it resolves the Authorization Server's metadata and leaves the session ready for begin_authorization. See src/mcp_oidc4vci/issuance.py, src/mcp_oidc4vci/authorization_server_metadata.py, src/mcp_oidc4vci/token_request.py, and src/mcp_oidc4vci/dpop.py.
Authorization code grant. begin_authorization builds the Authorization Request URL (PKCE, RFC 7636, S256; authorization_details naming the requested credential configurations, RFC 9396 — replaced by each configuration's own scope, when one is available, for an Authorization Server that doesn't support Rich Authorization Requests) for a human to open and complete — pushing its parameters first via Pushed Authorization Requests when the Authorization Server requires it, transparently to the caller — and submit_authorization_result exchanges the resulting code/state for an access token, rejecting a mismatched state before ever making a Token Request. This server has no HTTP endpoint of its own to receive the browser redirect, so the code/state are supplied back explicitly rather than captured automatically — see Architecture for why. Both grants converge on the same ready_for_credential_request state from here. See src/mcp_oidc4vci/authorization_request.py, src/mcp_oidc4vci/pushed_authorization_request.py, and src/mcp_oidc4vci/pkce.py.
Wallet boundary. WalletAdapter (a Protocol with generate_proof and receive_credential) backs request_credential, which completes a Credential Request for a ready_for_credential_request session: fetch issuer metadata, get a fresh nonce if the issuer needs one, ask the wallet for a signed proof (a real EC-signed openid4vci-proof+jwt, never signed by this server), send it — DPoP-bound if the session's access token is — and hand the issued credential to the wallet, whose contents never reach the agent. The spec's Credential Request only ever names one credential configuration, so an offer requesting several gets one Request per configuration: request_credential handles one per call and returns to ready_for_credential_request (not completed) while more remain, for the caller to call it again. If the issuer defers issuance instead of responding immediately, the session moves to awaiting_deferred_credential and poll_deferred_credential checks back later, reusing the same authentication, response handling, and one-at-a-time rule. The bundled MockWalletAdapter makes both grants work end to end for local testing. See src/mcp_oidc4vci/wallet.py, src/mcp_oidc4vci/credential_request.py, and src/mcp_oidc4vci/nonce.py.
Manual wallet handoff. request_wallet_proof / submit_wallet_proof split the Credential Request into two tool calls for when the proof must come from something other than the in-process MockWalletAdapter — a real wallet, or a human signing by hand — without needing any blocking-wait or webhook machinery: the handoff happens through the session, the same way initiate_issuance → get_issuance_status already does. request_credential (the automatic path) is unchanged and still there for fast, fully-automated testing. See Architecture for the design reasoning.
Shared data models live in src/mcp_oidc4vci/models.py, with tests in tests/ (99% coverage, 273 tests).
Python — implementation language.
uv — dependency management, virtual environments, and running the project.
FastMCP — high-level Python framework for building the MCP server and its tools.
MCP Python SDK — the underlying official protocol SDK that FastMCP builds on.
MCP Inspector — interactive tool for testing and debugging the MCP server's tools during development.
# Install uv if you don't have it
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install dependencies
uv sync
# Run the MCP server through the MCP Inspector for interactive testing
uv run fastmcp dev inspector src/mcp_oidc4vci/server.py:mcp
# Lint, type-check, and run the test suite
uv run ruff check .
uv run mypy src
uv run pytestscripts/sign_proof.py signs a spec-shaped proof JWT the same way MockWalletAdapter does, but as a separate process — useful for exercising request_wallet_proof / submit_wallet_proof (see Architecture) when there's no real wallet app on hand:
uv run scripts/sign_proof.py --audience https://issuer.example.com --nonce abc123Pass its output straight to submit_wallet_proof's proof_jwt argument.
This server has no HTTP endpoint of its own to receive a browser redirect (see Architecture), so completing this grant needs a real Authorization Server, a client_id/redirect_uri registered with it, and a browser: call begin_authorization, open the returned authorization_url, authenticate, and copy the code/state query parameters from wherever the browser lands after the redirect into submit_authorization_result.
Architecture — components, design principles, wallet boundary, data flow, MCP tool contracts, security requirements.
Describe the steps required to obtain the credential(s) offered by a Credential Offer.
Resolves the offer and returns which grant-based flow applies and its ordered steps.
| Name | Required | Description | Default |
|---|---|---|---|
| credential_offer | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for disclosing behavior. It states that the tool 'resolves' the offer and returns the applicable flow, which implies a read/analysis operation rather than a mutating one. It does not address side effects, permissions, or edge cases, but the 'Describe' framing makes the operation's non-destructive nature reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is two short sentences with no waste; the first sentence states the purpose and the second adds detail about the output (grant-based flow and ordered steps). It is concise and front-loaded, though the first sentence is slightly redundant with the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the core purpose and result well. However, it lacks explicit usage boundaries, mentions no sibling alternatives, and does not clarify the credential_offer input format. Without annotations, these gaps leave the agent with some uncertainty about when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter, so the descrition must compensate. It mentions that the input relates to a 'Credential Offer', but it does not explain the expected string format, encoding, source, or any constraints on credential_offer. This is insufficient for an agent to confidently construct the parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Describe' and names the resource: the issuance flow for a Credential Offer. It further clarifies the output by saying it returns which grant-based flow applies and its ordered steps. However, it does not explicitly differentiate this from sibling tools like inspect_credential_offer or initiate_issuance, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs the ordered steps to obtain credentials from an offer, but it does not explicitly state when to use this tool instead of siblings such as inspect_credential_offer, initiate_issuance, or request_credential. It offers no exclusions, prerequisites, or alternative-routing guidance, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and validate a Credential Issuer's metadata from its well-known endpoint.
Returns the issuer's credential endpoint, authorization servers, and the credential configurations it supports.
| Name | Required | Description | Default |
|---|---|---|---|
| credential_issuer | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool fetches over a well-known endpoint and performs validation, and it states the returned data. However, it does not clarify what 'validate' means in practice, what happens on invalid metadata, or whether any external network/auth considerations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The main action is front-loaded, and the return-value sentence adds necessary detail without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, and the description covers the core action and returned fields. It is incomplete regarding parameter format and validation failure behavior, but for a basic metadata fetch it is close to adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the undocumented 'credential_issuer' parameter. The description implies the parameter identifies the issuer whose metadata is fetched, but it never explicitly explains the expected format (e.g., URL, identifier). This is enough for a single obvious parameter but not fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch and validate') and names the resource ('Credential Issuer's metadata') plus the well-known endpoint location. It also lists the concrete return contents (credential endpoint, authorization servers, credential configurations), which clearly distinguishes this tool from siblings like get_issuance_status or inspect_credential_offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need issuer metadata), but it gives no explicit guidance, no contexts to avoid, and does not mention any sibling alternative. An agent must infer usage from the tool name and general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current state of a previously started issuance session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Return the current state' signals a read-only status check, which is the main behavioral trait, but it does not explain what happens for invalid or expired session IDs, or whether the state is refreshed or cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word contributes meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter status lookup, the description is minimally adequate, especially since an output schema exists. However, it lacks explicit guidance on where session_id comes from, when to call the tool, and how errors are surfaced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly references the session parameter by saying 'previously started issuance session.' It does not explicitly state that session_id is the identifier returned from initiate_issuance, nor describe its format or expected provenance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('current state of a previously started issuance session'), making the tool's core purpose unambiguous. It is distinct from siblings like initiate_issuance and request_credential, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously started' implies the tool should only be used after an issuance session has been initiated, which gives some contextual guidance. However, it does not explicitly state when to use this tool versus alternatives or mention related tools like inspect_credential_offer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an issuance session for a Credential Offer.
For the pre-authorized code grant, completes the token exchange immediately and the
session ends ready_for_credential_request or failed. For the authorization code
grant, the session is left waiting_for_user_authorization, since completing it requires
a wallet-driven redirect not yet implemented. tx_code is the transaction code obtained
from the user out-of-band, if the offer requires one.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_code | No | ||
| credential_offer | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses immediate token exchange for pre-authorized grants, terminal states ready_for_credential_request or failed, the waiting_for_user_authorization state for the authorization code grant, the unimplemented redirect, and the out-of-band nature of tx_code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences, front-loaded with the action and then expanding only into necessary flow-specific behavior. Every sentence adds operational value, with no filler or repetition of schema types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex issuance flow, the description covers the two grant types, their outcomes, the current implementation limitation, and the tx_code input. Since an output schema exists, return-value details are already handled outside the description, and nothing essential to invoking the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, so the description must compensate. It explains tx_code well ('transaction code obtained from the user out-of-band, if the offer requires one'), but credential_offer remains only implicitly defined as the offer that starts the session, with no format or origin details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Start an issuance session for a Credential Offer.' It further clarifies the operation by describing distinct grant-type behaviors and resulting session states, making it unmistakable from siblings like get_issuance_status or request_credential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'Start an issuance session' and details what happens for each grant type, but it never explicitly contrasts with sibling tools or states when not to use it. The guidance is mostly behavioral rather than decision-oriented, leaving alternatives unmentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse and validate an OIDC4VCI Credential Offer URI.
Resolves the offer (by value or by reference) and returns its Credential Issuer, requested credential configuration IDs, and available grants.
| Name | Required | Description | Default |
|---|---|---|---|
| credential_offer | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral burden. It does disclose useful behavior: it resolves the offer 'by value or by reference' and returns specific data. But it says nothing about validation failure modes, networking behavior, or side effects, which matters for a resolve/validate operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main action is front-loaded, and the second sentence adds the behavioral and output details an agent needs. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and an output schema, so the return shape is already covered. The description adds the key resolution distinction and output highlights. Minor gaps are validation behavior and explicit exclusions, but overall an agent can invoke this correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only says credential_offer is a string. The description compensates by explaining it is a Credential Offer URI and that it can be resolved by value or by reference, giving the agent meaningful semantic context for the sole parameter beyond the raw type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Parse and validate an OIDC4VCI Credential Offer URI') and then lists the concrete outputs (Credential Issuer, configuration IDs, grants). This makes it clearly distinct from the sibling issuance-and-status tools, which focus on different stages of the protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended trigger is inferrable: an agent should use this when it has an OIDC4VCI Credential Offer URI to inspect. However, the description never explicitly says when to prefer this over siblings or when not to use it, so the usage guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete the Credential Request for a session that has an access token.
Generates a key proof of possession through the wallet adapter — this server never signs anything itself — and hands the issued credential to the wallet for safekeeping. Its contents are never returned to the agent.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. It discloses the proof-of-possession generation through the wallet adapter, the server's deliberate non-signing role, and the critical constraint that the issued credential's contents are never returned to the agent. These are non-obvious behaviors an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first names the action and precondition, the second adds the key behavioral details. Every clause carries information; no filler or repetition. It is well front-loaded for an agent scanning the tool list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers the main action, important side effects, and the session precondition. It does not explicitly place itself in the issuance flow relative to siblings, but the access-token condition and 'completes' wording give enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must supply parameter meaning. It adds that session_id refers to a session that already has an access token, which is useful, but it does not say where that session_id comes from (e.g., initiate_issuance) or provide format/source details. This is minimal compensation for a schema with a bare string parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Complete the Credential Request for a session that has an access token.' It also clarifies the outcome (credential handed to wallet) and highlights a distinguishing behavior (server never signs; contents never returned), which sets it apart from sibling inspection and initiation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear precondition — the session must already have an access token — which implicitly tells the agent when in the flow to call it. It does not explicitly compare it against siblings like get_issuance_status or inspect_credential_offer, so it misses the full 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct phase of the OIDC4VCI flow, but inspect_credential_offer and describe_issuance_flow both resolve an offer and could be confused by an agent deciding whether to inspect contents or get next steps. The remaining tools have clearly separate boundaries.
All six tools use a consistent snake_case verb_noun pattern, e.g. get_, inspect_, describe_, initiate_, and request_. There is no casing or verb-style mixing, making the set highly predictable.
Six tools is well-scoped for an OIDC4VCI issuance server, covering offer inspection, metadata, flow analysis, initiation, status, and credential request. Each tool earns its place with no redundant or superfluous additions.
The toolset covers the pre-authorized code issuance path well, but the authorization-code grant is left in waiting_for_user_authorization with no tool to complete the user-authorization redirect or exchange the authorization code. This is a notable dead end for standard OIDC4VCI authorization-code flows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Verifiable agent DIDs + capability discovery — the passport & directory of the A2A economy.
Neutral W3C DID/VC identity and reputation oracle for AI agents (did:key/did:web, eddsa-jcs-2022).
Command your AI agents: verifiable passports, credential injection, full audit, revoke in 60s.
W3C DID issuance and verification for autonomous AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bernatmarcilla/mcp-oidc4vci'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
