Loading ToolBench
MCP server exposing a software engineer CRUD API over the Model Context Protocol, backed by Spring Boot and PostgreSQL
Five tools with clear verb-noun naming (list_, get_, create_, update_, delete_) and comprehensive descriptions (100-200 chars each). All tools have input schemas with typed parameters and descriptions. Output schemas are not explicitly documented in the source. Parameter descriptions are detailed and include constraints (e.g., '1-255 characters', '1-50 technologies'). Risk classifications (READ_ONLY, WRITE, REVERSIBLE, DESTRUCTIVE) are present. Main gaps: no documented output schemas, no error handling guidance in descriptions, no pagination support for list-software-engineers despite potentially large result sets.
Create a software engineer. 'name' is 1-255 characters; 'techStack' is a non-empty list of 1-50 technologies, each 1-255 characters. Returns the created engineer including its generated id.
Delete a software engineer by id (a UUID string). Errors if no engineer has that id.
Fetch one software engineer by id. The id is a UUID string as returned by list-software-engineers or create-software-engineer. Errors if no engineer has that id.
List every software engineer, each with its id (UUID), name, and tech stack.
Replace a software engineer's name and tech stack (full replace, not a merge — both fields are required). The id is a UUID string; 'name' is 1-255 characters; 'techStack' is a non-empty list of 1-50 technologies, each 1-255 characters. Errors if no engineer has that id. Returns the updated engineer.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns the created engineer including its generated id') but the actual response structure (field names, types, nested objects) is not visible in the source. LLMs cannot plan downstream tool calls or extract fields without knowing the response schema.
list-software-engineers lacks pagination. No limit, offset, or page parameters visible. If the engineer database grows large, returning all records will blow the context window. Baseline pattern requires pagination for list tools.
No error recovery guidance in tool descriptions. Descriptions state 'Errors if no engineer has that id' but do not guide the LLM on what to do next (e.g., 'Try list-software-engineers to find valid IDs'). Error messages at runtime are not visible in the source.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 84 | 2026-07-28+ | v2 |
Destructive tool (delete-software-engineer) has no confirmation or dry-run pattern. Agents can permanently delete engineers without a safety gate. Irreversible operations should support a confirmation step.
Parameter 'id' in get-, update-, and delete- tools is described as 'UUID of the engineer' but no format constraint (e.g., regex, pattern) is visible. LLMs may pass invalid UUIDs. Descriptions should state format explicitly: 'UUID string (36 chars, e.g., 550e8400-e29b-41d4-a716-446655440000)'.