MCP server that provides cryptographic identity management for agents. Creates RSA key pairs, signs messages, and verifies signatures to enable secure agent authentication and authorization.
The Agent Identity Wallet MCP server provides 5 cryptographic identity tools with moderate definition quality. Tool names follow verb_noun conventions (create_identity, get_identity, sign_message, verify_signature, revoke_identity), which is positive. However, descriptions are extremely brief (10-30 chars in most cases), parameter schemas are minimal, and output schemas are entirely undocumented. The server handles a specialized domain (cryptographic identity) but lacks the depth of documentation and error guidance expected for production use. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) are present despite risk levels being declared. Error handling guidance is absent, callers have no recovery path if operations fail.
Creates a new RSA 2048-bit cryptographic identity for an agent with a given name. Generates a public/private key pair and saves it to disk.
Retrieves information about the current agent identity, including the agent name, file location, and public key.
Revokes the current agent identity by deleting the identity file from disk. This is a destructive operation.
Cryptographically signs a message using the agent's private key with SHA256 algorithm. Returns the message and its hex-encoded signature.
Verifies that a message and signature pair are cryptographically valid using SHA256 and a provided public key (or the current identity's key if omitted). Returns whether the signature is valid.
All tool descriptions are extremely brief (10-30 chars), far below the 194-char baseline for production tools. Descriptions lack context on WHEN to use each tool, WHAT happens to state, and recovery guidance for failures.
Output schemas are completely undocumented. Callers cannot determine what fields to expect from create_identity, get_identity, sign_message, or verify_signature. This forces LLMs to infer structure, leading to parsing errors and wasted tokens.
Tool annotations (destructiveHint, readOnlyHint, idempotentHint) are not declared in any tool definition, despite clear risk levels (WRITE, READ_ONLY, DESTRUCTIVE) being noted in metadata. The MCP protocol supports these annotations, they should be present in schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 9 | - | v1 |
Parameter 'publicKey' in verify_signature is marked optional in description ('If omitted, uses current identity's key') but schema likely does not reflect optional vs required status, ambiguous for schema-driven clients.
No error handling guidance. If create_identity fails (disk write error, bad name), the tool provides no recovery path, actionable error message, or retry guidance. LLMs cannot self-correct.
create_identity accepts only a 'name' parameter (string) with no constraints (min/max length, allowed characters, regex). RSA key generation could fail with non-ASCII names or extremely long strings. No format guidance.
No idempotency guarantees. If create_identity is called twice with the same name, does it overwrite? Return existing? Fail? Agents retry on ambiguous failures, non-idempotent behavior risks duplicate key generation.
revoke_identity is irreversible and accepts no parameters (e.g., no 'confirm' flag or dry_run option). An agent that calls this in error has no recovery path. Missing confirmation request pattern.