Loading ToolBench
A simple MCP server with packaged tools for interacting with JSONPlaceholder API
This server has 3 tools with significant quality gaps. Naming is acceptable (verb_noun pattern used), but descriptions are extremely terse (13-45 chars, well below the 194-char baseline). Parameter descriptions are nearly absent, most params lack any guidance on valid values, formats, or constraints. The create_post tool has an unusually large required parameter set (12 fields) with no indication of what constitutes valid values, ranges, or relationships between fields. Schemas are present but lack depth, no enums where appropriate, no format specifications, no documented output schemas. Error handling exists but is generic (JSON.stringify of results, catch-all InternalError). No tool annotations (readOnlyHint, destructiveHint). The server does not expose actual tool definitions in the source code shown, tool discovery is dynamic via toolPaths and import, making it difficult to verify exact parameter types and descriptions. Based on visible code, input schemas appear well-formed (proper JSON Schema objects with properties and required arrays), but descriptions are the critical failure point.
Create a new post in JSONPlaceholder.
Fetches all comments from JSONPlaceholder.
Fetch a user by their ID from JSONPlaceholder.
Severely undersized tool descriptions (13 - 45 chars vs. 194-char baseline). Examples: 'Fetches all comments from JSONPlaceholder.' (45 chars) lacks context on when to use it, what structure is returned, or pagination support. 'Create a new post in JSONPlaceholder.' (40 chars) does not clarify which fields are required at the backend vs. optional for the user, or what constitutes a valid title/content.
Parameter descriptions are almost entirely missing. The get_user_by_id 'id' parameter has a description ('The ID of the user to fetch.'), but create_post has 12 parameters with minimal context. No guidance on what range of IDs is valid, whether status must be one of a fixed set, or how publishedAt/updatedAt should be formatted. LLMs cannot infer constraints from names alone ('status', 'category', 'url').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No enum constraints for categorical parameters. The create_post tool has a 'status' parameter (type string) with no indication of valid values (draft, published, archived, etc.). A 'category' parameter similarly has no enumeration. Free-form strings invite hallucinated values; LLMs need enums to self-select valid options.
No documented output schemas. Tool descriptions and code do not specify what fields are returned or their types. LLMs cannot plan downstream tool calls or extract data without knowing the response structure. E.g., does get_user_by_id return just {id, name, email} or a verbose object with audit fields?
create_post requires 12 parameters, all mandatory. This is unusually rigid, most production tools have 1 - 8 parameters, with many optional. No guidance on sensible defaults (e.g., status='draft', publishedAt=now()). The requirement forces the LLM to reason about every field before calling, adding cognitive load and failure points.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The get_all_comments and get_user_by_id tools are READ_ONLY but lack readOnlyHint annotations. The create_post tool has Risk: WRITE but no destructiveHint. Modern MCP clients use these hints to guide agent behavior (e.g., read-only tools are safe to call speculatively; write tools warrant confirmation).
Error handling is generic. CallToolRequest handler returns McpError.InternalError with 'API error: {message}' for all exceptions. No guidance on retryability, user-fixability, or next steps. E.g., if create_post fails due to invalid status, the agent gets a 500 error with no hint to try a different status value.
get_all_comments has no pagination parameters (limit, offset, page). JSONPlaceholder typically returns large lists, fetching all comments at once risks context window overflow. Tool should accept optional limit and offset to enable cursor-based pagination.