Loading ToolBench
This server has 5 tools with reasonable structure but several quality gaps. All tools are explicitly registered with Zod schemas and descriptions present in the source code. Tool names follow verb_noun conventions (create-post, reply-to-post, toggle-like, get-feed, update-username). However, descriptions are brief (15-95 chars, below the 50-200 char LLM-optimized baseline), and parameter descriptions lack context about expected formats, constraints, and when to use each tool. Error handling returns text messages but does not guide the LLM on recovery actions. Output schemas are not documented, the tools return JSON.stringify(response) without specifying what fields or structure the agent should expect. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite write operations. The server does not accept human-readable identifiers like usernames or display names, it expects opaque postId and parentId strings, forcing agents to discover IDs externally.
Create a new post with the provided content
Get recent posts feed (50 most recent posts in reverse chronological order) along with the current topic
Create a reply to an existing post
Like or unlike a post
Update the authenticated user's username
Tool descriptions are too brief (15-95 chars) to guide LLM tool selection. Baseline for LLM-optimized descriptions is 50-200 chars. 'Create a new post with the provided content' omits WHEN to use it vs other tools, prerequisites, and what the response contains. This forces LLMs to guess the purpose of overlapping tools.
Output schemas are not documented. Tools return JSON via JSON.stringify(response) but do not specify what fields or structure the response contains. LLMs cannot plan downstream calls without knowing the response structure. For example, create-post response structure is unknown, does it include post_id, timestamp, author, likes? Agents cannot chain calls without this information.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Tools require opaque IDs (postId, parentId) without accepting human-friendly identifiers like usernames or display names. Users say 'Reply to Jack's post' but this tool requires a post ID from somewhere else, forcing agents to discover IDs in a separate call. reply-to-post and toggle-like have this issue.
Error handling returns plain text error messages without guidance for recovery. 'Error creating post: Invalid content length' tells the LLM nothing about what to do, can it retry? Should it ask the user? Or is this unrecoverable? Errors should include categorization (retryable, user-fixable, fatal) and next steps.
Write operations (create-post, reply-to-post, toggle-like, update-username) lack tool annotations. toggle-like and update-username should be marked with destructiveHint or idempotentHint so agents understand retry safety and confirmation requirements. No annotations are present.
Parameter descriptions lack constraints and context. The 'content' parameter for create-post says 'Content of the post (1-280 characters)' but does not explain what characters are allowed, whether hashtags/mentions work, or what happens if the LLM passes markup. The 'imageUrl' parameter requires a 'url' format constraint but the description does not explain what image types or sizes are accepted.
get-feed description states 'Get recent posts feed (50 most recent posts in reverse chronological order)' but does not document the response structure, whether pagination is supported, or what metadata is included per post. LLMs cannot reason about result limits without explicit documentation.