Loading ToolBench
MCP server to allow an AI agent to access a wallet PID and initiate OIDC4VP (OpenID Connect for Verifiable Presentations) requests for identity verification
This MCP server exhibits significant definition quality gaps. Only 2 tools are defined with minimal schema completeness. Tool 1 (initiate_oidc4vp_request) has a reasonable description but parameters lack purpose context. Tool 2 (create_customer_account) has a vague description and the 'data' parameter is a bare object type with no schema definition, just a generic description. Neither tool documents output schemas. Parameter descriptions are superficial (e.g., 'Customer account data with fields for...' is not actionable). No enum constraints exist despite parameter sets that should be constrained. Error handling guidance is absent, the code shows validation logic (missing vp_token, presentation_submission) but tools don't document what errors can occur or how LLMs should respond. Security issue: credentials and internal state (Redis keys, JWT payloads) are not isolated from tool exposure, though the tool parameters themselves avoid API keys directly.
Creates a customer account with provided data, enriched with verification status from wallet
Displays a QR code or a button that allows the user to share verified identity data from their digital wallet (such as first name, last name, or other credentials). Only use this tool to request data from the user's wallet.
Tool 2 'create_customer_account' has no input schema definition. The 'data' parameter is typed as a bare 'object' with generic description 'Customer account data with fields for first name, last name, and other credentials', no actual schema properties, no field types, no enum constraints, no examples of valid input structure.
Neither tool documents output schema. LLMs cannot plan downstream calls or extract relevant data if they don't know what fields are returned. Tool 1 returns a Python dict with 'status', 'tool_call_id', 'session_id', 'authorization_request', 'qr_code_base64', this structure is inferred from code, not declared in the tool definition.
Tool 1 description ('Displays a QR code...') is only 97 characters and assumes context about wallet data sharing. Missing: when to use vs alternative methods, what data is actually returned, what happens on timeout. Tool 2 description is even weaker at 109 characters, does not explain when to call it or how enrichment from wallet works.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Parameter descriptions lack actionable context. Tool 1 'server' parameter is described as 'The callback server URL' but does not explain format, required scheme (http vs https), or error handling if invalid. 'session_id' and 'tool_call_id' descriptions are minimal, no guidance on what these identifiers reference or where to obtain them.
No error handling documentation. Code validates 'vp_token' and 'presentation_submission' presence (line: 'if not vp_token or not presentation_submission'), checks JWT signatures, verifies expiration, but tool definitions do not declare which errors can occur, whether they are retryable, or recovery guidance. LLM sees a failure but has no guidance.
Tool 1 'server' parameter likely expects a base URL but description does not clarify whether trailing slash is required, whether it must support specific path patterns (e.g., ends with '/verifier/'), or what HTTP scheme. Ambiguity forces LLM to guess.
Tool 1 description mentions 'only use if user agrees' but does not declare permission requirements or gate execution. Code does not validate caller permissions. Tool 2 has no permission documentation despite being a WRITE operation that creates customer records.
Tool 2 'create_customer_account' description does not explain when to use it (before or after wallet verification?), what 'enrichment' means operationally, or whether it depends on output from Tool 1. Multi-step workflows need dependency hints.