Loading ToolBench
MCP server that exposes Posts & Comments API as tools
The server demonstrates solid fundamentals with all 7 tools having clear action-verb names, documented descriptions, and properly typed input schemas using Zod. However, there are meaningful gaps in output schema documentation, error handling guidance, and parameter constraints that prevent a higher score. All tools follow verb_noun naming (create_post, list_posts, get_post, update_post, delete_post, add_comment, list_comments), which is excellent. Descriptions are generally 50-180 characters, meeting the 10-1024 baseline. Zod schemas provide runtime validation and type safety. However, the server lacks documentation of output schemas, does not provide actionable error recovery guidance, and parameter descriptions could be more specific about constraints and edge cases.
Add a comment to a post. Validates: text (min 10), commenter required. Returns 404 if post not found.
Create a new post. Validates: title (min 5), author (min 3), category (tech|finance|lifestyle), body (min 50 chars).
Delete a post by ID. Also deletes its comments. Returns 404 if post not found.
Get a single post by ID. Returns 404 if not found.
List all comments for a post. Returns 404 if post not found.
List all posts from the API.
Update an existing post. Same validation as create_post. Returns 404 if post not found.
Output schema not documented. LLMs cannot determine what fields to expect in responses, preventing downstream planning and increasing hallucination risk. Tools return JSON stringified responses with no schema definition visible in code.
list_posts and list_comments lack pagination parameters (limit, offset, page). Without pagination, returning hundreds of posts/comments will exhaust context windows. No statement in descriptions about result limits.
Error handling is minimal. API errors (404, 500, etc.) are caught and thrown as generic Error objects. LLM receives no guidance on recovery paths (e.g., 'Post not found. Try list_posts() to find a valid postId.' or 'Is this a retryable error?').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Destructive operations (delete_post) lack confirmation/dry-run support. An agent mistake could permanently delete posts without recovery path. No warning in description about irreversibility.
Parameter descriptions lack specific constraint details. E.g., postId description says 'MongoDB ObjectId of the post' but does not explain the format (24-char hex string), length bounds, or what 'invalid' looks like. LLMs cannot reliably construct valid ObjectIds from a vague description.
No tool annotation metadata (readOnlyHint, destructiveHint, idempotentHint). LLMs lack machine-readable cues about which tools are safe to retry and which have irreversible side effects.
API responses are returned as raw JSON stringified text, not structured objects. Agents must parse JSON within the text field, losing type safety. Returns like { content: [{ type: 'text', text: JSON.stringify(...) }] } should decompose structured data into typed fields.