How do I use idm-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@idm-mcp Mint a DID for my AI agent and issue a verifiable credential granting it tool access." 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.

idm-mcp

by fcapub

Overview Schema Related Servers Score Discussions

Python

Hybrid

IDM MCP Server

A mock identity-management MCP server for decentralized identity. It exposes tools to mint DIDs, issue signed W3C-style Verifiable Credentials (VCs), and verify them — over the Model Context Protocol.

Status: mock / proof-of-concept. State is held in memory (not persistent), the issuer signing key is regenerated on every restart, and several fields are simplified for demonstration. See Limitations.

Features

get_did — mint a did:ietf:<uuid> identifier + record from an agent's public key.
resolve_did — look up a DID document by DID, or list all registered DIDs.
get_vc — issue an Ed25519-signed Verifiable Credential for a subject DID, and store it.
verify_vc — verify a credential's issuer signature and validity window.
resolve_vc — look up a credential by its id, or list all issued credentials.
list_credentials — list all credentials issued to a subject DID.
ping / echo — trivial health/echo tools used to smoke-test the MCP plumbing.

The server acts as its own credential issuer: at startup it generates an Ed25519 keypair and mints its own DID (by calling get_did with entity_type="IDM"). Credentials are signed with that issuer key, which stays in-process and is never returned by any tool.

Related MCP server: Agent Identity MCP Server

Requirements

uv
Python 3.12 (pinned via .python-version)
Node.js / npx — only needed for the MCP Inspector (mcp dev)

Dependencies (mcp[cli], cryptography) are managed by uv and installed on first run.

Setup

This project uses uv. Dependencies are declared in pyproject.toml and pinned in uv.lock — together these replace a requirements.txt.

After installing uv once, clone or unzip the project and run:

uv run python main.py

uv run automatically creates the virtual environment, installs the exact locked dependencies, and even fetches Python 3.12 (pinned in .python-version) if it's missing — no manual venv creation or activate step. Run uv sync first if you'd rather install dependencies without starting the server.

Prefer plain pip? Export a requirements file from the lockfile, then install the old way:

uv export --format requirements-txt --no-hashes > requirements.txt
# recipient: python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt

Running

# Run the server (default transport: stdio)
uv run python main.py

# Serve over Streamable HTTP instead (http://127.0.0.1:8000/mcp)
uv run python main.py --transport streamable-http

# Develop / test interactively with the MCP Inspector (opens a browser UI)
uv run mcp dev main.py

The transport is chosen with --transport {stdio,streamable-http} (default stdio) — no code edits needed.

Using it from Claude Code

Pick one — the launch command states the transport, so there's nothing in the code to keep in sync:

Option A — stdio (Claude Code launches the server for you):

claude mcp add idm-mcp -- uv --directory /path/to/idm_mcp run python main.py --transport stdio

Option B — streamable-http (you run the server yourself, then register the URL):

uv run python main.py --transport streamable-http
claude mcp add --transport http idm-mcp http://127.0.0.1:8000/mcp

Generating a keypair

The tools operate on an Ed25519 keypair that the agent owns. To generate one, run:

uv run python keygen.py
# Public Key: <64 hex chars>
# Secret Key: <64 hex chars>

The public key (hex) is what you pass as pk to get_did. Keep the secret key with the agent — it is never sent to the server.

Tools

`get_did(entity_type, pk, pktype, description="", protocol="", transparency="")`

Creates a DID record from an agent's public key.

Param	Required	Description
`entity_type`	yes	Kind of entity, e.g. `"AIagent"`, `"toolbox"`.
`pk`	yes	Raw Ed25519 public key as hex (64 chars, from `keygen.generate_raw_keys()`).
`pktype`	yes	Key algorithm label, e.g. `"ed25519"`.
`description`, `protocol`, `transparency`	no	Optional metadata recorded on the record.

Returns the DID record, including its id (the DID).

`resolve_did(did="")`

Looks up a DID document by DID, or lists all registered DID documents.

Param	Required	Description
`did`	no	The DID to resolve. If omitted, returns a list of all registered DID documents.

Returns the matching DID document (when a DID is given) or a list of all documents (when omitted). Raises if the DID is unknown.

`get_vc(subjectID, content, keyType, signType, usage)`

Issues and stores a Verifiable Credential for a subject DID.

Param	Required	Description
`subjectID`	yes	The subject's DID (as minted by `get_did`).
`content`	yes	What the credential grants, e.g. `"callTools"`.
`keyType`	yes	Recorded as the proof's cryptosuite value, e.g. `"Ed25519"`.
`signType`	yes	signature scheme, e.g. "asy"; Reserved (currently unused; only asymmetric signing is performed).
`usage`	yes	Intended use, e.g. `"authorization"`.

The credential is signed by the issuer key over a canonical serialization (sorted-key compact JSON, with proof empty at signing time).

`verify_vc(vc)`

Verifies a credential's issuer signature and its validity window.

Param	Required	Description
`vc`	yes	The Verifiable Credential (as returned by `get_vc`) to verify.

Rebuilds the exact signed bytes (proof reset to ""), checks the Ed25519 signature, then confirms the current time is within validFrom/validUntil. Returns {"valid": bool, "issuer": ..., "subjectId": ..., "reason": ...} — with a distinct reason for a bad signature, an expired credential, or one not yet valid.

Verifies any issuer whose DID is registered (via get_did) — it resolves the issuer's public key from its DID document (resolve_did + multibase decode). This confirms the credential is authentic for its claimed issuer.

`resolve_vc(vc_id="")`

Looks up a Verifiable Credential by its id, or lists all issued credentials.

Param	Required	Description
`vc_id`	no	The VC id to resolve. If omitted, returns a list of all issued credentials.

Returns the matching VC (when an id is given) or a list of all VCs (when omitted). Raises if the id is unknown.

`list_credentials(subject)`

Lists all Verifiable Credentials issued to a subject DID.

Param	Required	Description
`subject`	yes	The subject DID (`credentialSubject.id`) whose credentials to list.

Returns a list of that subject's credentials (an empty list if it holds none — a filter query, so an unknown subject is not an error).

Example flow

An MCP client — an agent, Claude Code, or the MCP Inspector — calls the tools in sequence. The agent supplies its own Ed25519 public key (hex) when requesting a DID (see Generating a keypair).

get_did — request a DID for the agent:

{ "entity_type": "AIagent", "pk": "4bb0…3c6f", "pktype": "ed25519",
  "description": "AIassistant", "protocol": "MCP", "transparency": "6GPDL" }

→ returns a DID record whose id is e.g. did:ietf:ebc391….

get_vc — issue a credential for that DID as the subject:

{ "subjectID": "did:ietf:ebc391…", "content": "callTools",
  "keyType": "Ed25519", "signType": "asy", "usage": "authorization" }

→ returns a signed Verifiable Credential.

verify_vc — pass the credential back to check its signature:
```
{ "vc": { "...": "the credential returned by step 2" } }
```
→ { "valid": true, "issuer": "did:ietf:…", "subjectId": "did:ietf:ebc391…" }

The quickest way to try this by hand is uv run mcp dev main.py, which opens the MCP Inspector where you can call each tool and paste results between steps.

Agent Skills

The repo also ships Agent Skills (under .claude/skills/) — playbooks that teach an AI agent how to obtain and use decentralized identity. A skill provides the workflow; the MCP server (or a bundled script) provides the capability.

Skill	What it does	Needs the server?
`agent-identity-local`	Generate a keypair and mint a DID document locally (self-sovereign). Bundles a self-contained script that runs with just `uv` (or `python` + `cryptography`).	No — fully standalone / portable
`agent-identity-idm`	Obtain a DID by calling the server's `get_did`; reuses an existing keypair or generates one, then stores the wallet.	Yes (`idm-mcp`)
`agent-credential`	Establish identity and apply for capability Verifiable Credentials (`get_vc`) — one DID, many VCs.	Yes (`idm-mcp`)

Each skill manages a local wallet (agent_wallet.json) holding the agent's keypair, DID, and credentials. The secret key stays with the agent and is never sent to the server.

To use a server-dependent skill, register the MCP server with your client (see Using it from Claude Code). agent-identity-local needs nothing but uv.

Project structure

idm_mcp/
├── main.py         # FastMCP server + the get_did / get_vc / verify_vc tools
├── keygen.py       # Ed25519 key generation + sign/verify primitives (hex-encoded keys)
├── pyproject.toml  # uv project + dependencies
├── README.md
└── .claude/
    └── skills/     # Agent Skills (agent-identity-local, agent-identity-idm, agent-credential)

Limitations

This is a mock, not production identity infrastructure:

In-memory only — the DID and VC registries and the issuer key live in process memory and are lost on restart.
Local registry, no external resolution — verification works only for issuers whose DIDs were registered with this server; there is no global/ external DID resolution.
signType is unused, and pktype is not validated (only ed25519 is actually handled; pk is validated to be a 32-byte Ed25519 key).
Canonical JSON signing, not full JSON-LD Data Integrity canonicalization.

Available Tools

8 tools

echoA

Echo back the provided message. Useful for testing argument passing.

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies a safe, side-effect-free operation. With no annotations, it sufficiently covers expected behavior for a simple echo.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with front-loaded purpose and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with output schema, the description is complete enough to guide use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter 'message' is clarified as the input to echo, but schema description coverage is 0%, and the description adds no further constraints or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool echoes back a message. Distinct from siblings which handle DIDs, VCs, and ping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states usefulness for testing argument passing, providing clear context for when to use it. No exclusion or alternative needed due to simplicity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_didA

Create a DID (Decentralized Identifier) record for an agent from its public key.

Required:
    entity_type: the kind of agent/entity, e.g. "AI Agent" or "Toolbox".
    pk:          the agent's raw Ed25519 public key as a hex string
                 (64 hex chars, as produced by keygen.generate_raw_keys()).
                 Validated: must decode to 32 bytes, else ValueError.
                 Stored in the DID document as publicKeyMultibase.
    pktype:      the public key algorithm label, e.g. "ed25519"; recorded
                 as the verification method's type.

Optional metadata (recorded as top-level fields on the returned record):
    description:  human-readable description, e.g. "AIassistant".
    protocol:     protocol the agent speaks, e.g. "MCP".
    transparency: transparency-log reference, e.g. "6GPDL".

Returns the DID record dict: containing its "id" (the DID).

ParametersJSON Schema

Name	Required	Description	Default
`pk`	Yes
`pktype`	Yes
`protocol`	No
`description`	No
`entity_type`	Yes
`transparency`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses validation (pk must decode to 32 bytes), return value (DID record dict with 'id'), and storage behavior (values stored in document). However, it does not mention whether the operation is idempotent or what happens on duplicate keys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with bold headings for required and optional sections, making it scannable. It is somewhat verbose but each sentence adds value. Slight reduction could improve conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers what is returned (DID record dict with 'id'). It also explains validation and metadata recording. Missing are error states (e.g., duplicate key) and permission requirements, but overall it is fairly complete for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description fully compensates. It adds crucial meaning for each parameter: pk format and validation, pktype algorithm label, and metadata fields' purpose. This goes well beyond the schema's empty titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a DID record', which is a specific verb+resource, but the tool name 'get_did' is misleading as it implies retrieval rather than creation. This could confuse the agent, especially given sibling 'resolve_did' which actually retrieves. The description does not explicitly differentiate from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists required and optional fields with clear sections, implying usage context. However, it does not explicitly state when to use this tool versus alternatives like 'resolve_did', nor does it specify prerequisites or conditions for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_vcA

Issue a Verifiable Credential for a subject DID and store it.

Parameters:
    subjectID: the DID of the subject the credential is about
               (as minted by get_did).
    content:   what the credential attests/grants, e.g. "callTools".
    keyType:   recorded as the proof's cryptosuite value, e.g. "Ed25519".
    signType:  signature scheme, e.g. "asy";
               (reserved; only asymmetric (Ed25519) signing is performed,
               so this value is not currently used.)
    usage:     intended use of the credential, e.g. "authorization".

The credential is signed by the server's issuer key over a canonical
serialization (sorted-key compact JSON with proof="").

Returns the stored Verifiable Credential.

ParametersJSON Schema

Name	Required	Description	Default
`usage`	Yes
`content`	Yes
`keyType`	Yes
`signType`	Yes
`subjectID`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers signing by issuer key, canonical serialization, and the reserved signType, providing good behavioral details beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear parameter list followed by behavioral notes. Every sentence adds value, though slightly long for a concise tool definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description mentions return value. It covers input and signing behavior but lacks details on storage location, errors, or permission requirements, which is acceptable given tool complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates fully by explaining each parameter with concrete examples (e.g., 'callTools', 'Ed25519') and clarifying purpose, adding significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it issues a Verifiable Credential for a subject DID and stores it, with relation to get_did. This distinguishes it from siblings like resolve_vc or verify_vc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage for authorization and references get_did for subjectID, but does not explicitly state when to use or avoid, nor compare to alternatives like list_credentials.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_credentialsA

List all Verifiable Credentials issued to a subject DID.

Parameters:
    subject: the subject DID (credentialSubject.id) whose credentials to list.

Returns a list of VCs whose credentialSubject.id matches `subject`
(an empty list if the subject holds none).

ParametersJSON Schema

Name	Required	Description	Default
`subject`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description clarifies the return: a list of VCs matching the subject DID, or empty if none. This discloses the behavioral outcome. It does not mention side effects or auth needs, but since this is a read-only list, the description is sufficiently transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences for purpose and parameter, plus a note on return. No unnecessary words, and the main action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (single parameter, list output), the description covers what it does, parameter explanation, and return value. It is complete for an agent to use correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description adds critical meaning: subject is the 'subject DID (credentialSubject.id)'. This clarifies the parameter semantic beyond the schema's bare type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all Verifiable Credentials issued to a subject DID', specifying the action (list), resource (VCs), and scope (by subject). It distinguishes from sibling tools like get_vc or resolve_vc by focusing on listing multiple credentials for a given subject.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing VCs of a specific subject but does not explicitly mention when to use vs. alternatives (e.g., get_vc for a single VC). No exclusions or alternative conditions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pingA

Health check. Returns 'pong' so a client can confirm the server is alive.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description clearly states the tool returns a fixed response ('pong') for health checking. Since there are no annotations, the description adequately covers the expected behavior for a simple, side-effect-free tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, containing no unnecessary words. It is front-loaded with the key action ('Health check') and delivers value efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, simple return value), the description is complete. It explains the input, behavior, and output. The presence of an output schema further reduces the need for description detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so the description does not need to add parameter details. Baseline is 4 for zero parameters, and the description is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it is a health check that returns 'pong', clearly indicating the tool's purpose and resource. It is easily distinguishable from sibling tools which relate to DIDs and credentials.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for connectivity verification but does not provide explicit guidance on when to use it versus alternatives like 'echo' or when not to use it. No exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_didA

Resolve a DID to its DID document, or list all registered DID documents.

Parameters:
    did: the DID to resolve, e.g. "did:ietf:...". If omitted/empty, returns
         a list of every DID document currently registered.

Returns the matching DID document (dict) when a DID is given, or a list of
all DID documents when none is given. Raises ValueError if the DID is unknown.

ParametersJSON Schema

Name	Required	Description	Default
`did`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behavioral traits: it returns a dict for a specific DID, a list of documents when no DID is given, and raises ValueError for unknown DIDs. Since no annotations are provided, the description carries the full burden and does so effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear front-loaded sentence followed by a brief parameter explanation and return values. Every sentence adds value without unnecessary wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 (implied), the description adequately covers return types, error behavior, and parameter semantics. It is complete for the level of complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the schema: it explains the did parameter's role, gives an example format, and describes the special behavior when omitted. With 0% schema coverage, this compensation is strong.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: resolve a DID to its document or list all DIDs. It specifies the verb 'resolve' and the resource 'DID document', and distinguishes between the two behaviors based on the parameter. This differentiates it from siblings like get_did.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool (to resolve a specific DID or list all DIDs). It does not explicitly state when not to use it or mention alternatives, but the dual behavior is well explained.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_vcA

Resolve a Verifiable Credential by its id, or list all issued credentials.

Parameters:
    vc_id: the VC id to resolve. If omitted/empty, returns a list of every
           issued credential.

Returns the matching VC (dict) when a vc_id is given, or a list of all VCs
when none is given. Raises ValueError if the vc_id is unknown.

ParametersJSON Schema

Name	Required	Description	Default
`vc_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that it returns a dict or list depending on input, and raises ValueError for unknown vc_id. No side effects are mentioned, but for a read-like operation this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear front-loaded first sentence. The parameter explanation is integrated without being overly verbose. It earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter, the description covers the dual behavior, error condition, and return types. It is complete enough for the agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description adds significant value. It explains the vc_id parameter's meaning, its default behavior, and the return type for each case, which is beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the dual functionality: resolve a VC by ID or list all issued credentials. The verb 'Resolve' is specific and the resource is 'Verifiable Credential'. It distinguishes itself from siblings like 'get_vc' by explicitly mentioning both modes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each mode based on the vc_id parameter: if omitted/empty, list all; if provided, resolve that specific VC. It does not compare with sibling tools, but the condition is clearly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_vcA

Verify the issuer signature and validity window of a Verifiable Credential.

Resolves the issuer's public key from its DID document in the DID registry
(so ANY issuer registered via get_did can be verified, not just this server),
rebuilds the exact bytes that were signed (the VC with 'proof' reset to ""),
checks the Ed25519 signature in proof.proofValue, then the validity window.

This confirms the credential is AUTHENTIC for its claimed issuer; it does NOT
assess whether that issuer is trusted or authorized (a separate concern).

Returns {"valid": bool, "issuer": ..., "subjectId": ..., "reason": ...}.
A credential is valid only if the signature checks out AND the current time
is within its validFrom/validUntil window.

ParametersJSON Schema

Name	Required	Description	Default
`vc`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It details the verification process: resolving public key from DID document, rebuilding signed bytes, checking Ed25519 signature, and checking validity window. It also notes it works for any issuer registered via get_did. However, it does not describe error conditions or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the main purpose, followed by detailed process and constraints. Each sentence adds value without redundancy. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides the return object shape {valid, issuer, subjectId, reason}. It explains the verification steps and clarifies scope (authenticity vs. trust). This gives an AI agent complete context to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only defines 'vc' as an object with no constraints (0% schema coverage). The description adds significant meaning by explaining which parts of the VC are used (proof.proofValue, validFrom, validUntil) and that the proof is reset to empty string for verification. This compensates for the sparse schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it verifies the issuer signature and validity window of a Verifiable Credential, specifying the verb (verify) and resource (VC). It distinguishes from sibling tools like get_did and resolve_did by focusing on credential validation rather than DID resolution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to confirm authenticity of a VC's signature and validity window) and explicitly states what it does NOT do (assess issuer trust/authorization), providing clear context. However, it does not explicitly mention alternative tools for trust assessment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: echo/ping for testing, get_did/resolve_did for DIDs, get_vc/list_credentials/resolve_vc/verify_vc for VCs. Overlap between list_credentials and resolve_vc is resolved by parameter differences.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern (get_did, get_vc, list_credentials, resolve_did, resolve_vc, verify_vc) with lowercase snake_case. echo and ping are conventional single-word utilities.

Tool Count5/5

Eight tools cover both DID and Verifiable Credential management appropriately without being excessive or insufficient for a focused identity server.

Completeness4/5

Core workflows (create/resolve DID, issue/list/resolve/verify VC) are covered. Minor gaps like DID update/deactivation or issuer management are absent but acceptable for a basic identity server.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

wallet-verifier-mcp B
com.wallet-connectors
MCP server for verifying EUDI/Talao wallet data via OIDC4VP (pull) for AI agents.
Security Blockchain Web3 & Decentralized Tech
12
Probe V0 A
io.github.lexbritten
Experimental MCP server for current empirical verification of explicit public HTTPS endpoint claims.
API Testing Penetration Testing
21
HODLXXI Read-Only A
io.github.hodlxxi
Public read-only MCP server for HODLXXI agent identity, trust, receipts, and verification.
Blockchain Cryptocurrency
262
AI Codex B
io.github.majorelalexis-stack
Neutral W3C DID/VC identity and reputation oracle for AI agents (did:key/did:web, eddsa-jcs-2022).
Blockchain Cryptocurrency Web3 & Decentralized Tech
62

Related MCP Servers

aip-identity
Autonomous Agents Security
The-Nexus-Guard
A
license
A
quality
D
maintenance
MCP server for AI agent identity — verify agents with Ed25519 signatures, check trust scores, sign and verify content, exchange encrypted messages. Built on the Agent Identity Protocol (AIP).
Updated 6 months ago (2026-03-09 12:03 UTC)
8
MIT
Agent Identity MCP Server
Security Autonomous Agents
AiAgentKarl
A
license
Not graded
quality
D
maintenance
MCP Server for AI agent identity and authorization. Create, verify, and manage agent identities with trust scores and scoped authorization tokens.
Updated 5 months ago (2026-04-03 16:05 UTC)
MIT
mcp-server-jis
Security Web3 & Decentralized Tech
jaspertvdm
A
license
A
quality
D
maintenance
MCP server for jis: bilateral intent identity verification. Enables users to verify identities, request mutual consent, and send verified messages within the Intent-Centric Web ecosystem.
Updated 6 months ago (2026-02-20 04:32 UTC)
7
MIT
@bind-protocol/mcp-serverofficial
Security Autonomous Agents
bind-protocol
A
license
A
quality
C
maintenance
Local MCP server for Bind Protocol — credential parsing, verification, and hashing tools for AI agents.
Updated 7 months ago (2026-02-18 06:38 UTC)
3
19
MIT

Appeared in Searches

Information about Duende IdentityServer

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fcapub/idm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

IDM MCP Server

Features

Requirements

Setup

Running

Using it from Claude Code

Generating a keypair

Tools

get_did(entity_type, pk, pktype, description="", protocol="", transparency="")

resolve_did(did="")

get_vc(subjectID, content, keyType, signType, usage)

verify_vc(vc)

resolve_vc(vc_id="")

list_credentials(subject)

Example flow

Agent Skills

Project structure

Limitations

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@bind-protocol/mcp-serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API

`get_did(entity_type, pk, pktype, description="", protocol="", transparency="")`

`resolve_did(did="")`

`get_vc(subjectID, content, keyType, signType, usage)`

`verify_vc(vc)`

`resolve_vc(vc_id="")`

`list_credentials(subject)`