Loading ToolBench
MCP server for managing and retrieving identity claims with comprehensive CRUD operations
This server has 6 tools with reasonable schemas but significant issues in descriptions, parameter clarity, and composition. Tool naming follows verb_noun convention (get_, create_, update_, delete_), which is good. However, descriptions are often too brief (10-34 characters), lack context about WHEN to use tools, and don't explain state-modifying consequences. Parameter descriptions are sparse or missing. Error handling guidance is absent. The server uses proper JSON Schema with types, but lacks the LLM-optimized documentation needed for reliable agent selection and planning. Most tools are READ_ONLY or state-modifying, but descriptions don't clearly distinguish them. Output schemas are not documented in the tool definitions. This is typical of a POC-stage server that needs hardening for production use.
Returns the current application version, local time, UTC time, and UTC ticks as a JSON object.
Create a new claim.
Delete a claim by id.
Retrieve details for a single claim by id.
Retrieve a list of claims.
Update a claim by id.
Output schemas are not documented for ANY tool. Agents cannot plan downstream calls or extract required fields (e.g., claim IDs for chaining). Per pattern:tool and pattern:response-shaper, every tool must document what fields it returns.
Descriptions for state-modifying tools (delete_claim, create_claim, update_claim) do not explicitly state they are destructive or create/modify data. Per pattern:command-tool, agents must know consequences. Current descriptions are 23-30 chars, below the 50-200 char optimized range.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
No error handling or recovery guidance in any tool description. Per pattern:recovery-guide and pattern:error-classification, tool descriptions should hint at what can go wrong and what the agent should do. E.g., delete_claim should describe 'Permanently removes the claim. This action cannot be undone. Fails if claimId is invalid.'
identity-update_claim has a design flaw: claimId is both a top-level parameter and required inside claimUpdateDto.id. This forces redundant input and creates risk of mismatch if agent passes different values. Per pattern:tool-composition, parameters should not be duplicated across nesting levels.
Tool descriptions lack guidance on WHEN to use each tool vs alternatives. E.g., get_claims vs get_claim_details, when does agent choose which? Per pattern:tool-description, descriptions should state the intended use case and distinguish from related tools. All get_* tools need this context.
No documentation of pagination limits for identity-get_claims. It accepts 'numberOf' param but no description states max allowed (e.g., 'max 100') or default. Per pattern:paginated-result, tools returning lists must document limits and enforce them to prevent context window exhaustion.