Loading ToolBench
An MCP server that provides tools to interact with Twitter/X, allowing users to retrieve tweets and send new tweets using Twitter credentials
Two tools with minimal documentation. Both have Zod schemas (getTweet and sendTweet with basic string parameters), but lack depth in descriptions. getTweet has a 24-char description; sendTweet has a 23-char description. Neither exceeds the 10-char minimum for adequate context, placing them in the 'bare minimum' category (rubric: descriptions under 20 chars → score 0-20). Parameter descriptions are generic single-sentence strings. No output schema documentation visible. Critical gap: sendTweet is a destructive operation (marked DESTRUCTIVE risk) but the description does not state this consequences or mention any confirmation/dry-run pattern. No error recovery guidance. getTweet returns tweet.text as a raw string (not structured), while sendTweet awaits result.json() and returns it, inconsistent output handling. No pagination, batching, or composition patterns evident. The server exposes authentication via environment variables (good), but the tool descriptions do not guide agents on when/why to use each tool or what happens on failure.
Get a tweet by its ID
Send a new tweet
Insufficient tool descriptions for LLM selection. 'Get a tweet by its ID' (24 chars) and 'Send a new tweet' (23 chars) lack context on WHEN to use, WHAT it returns, and prerequisites. Rubric baseline: avg tool description = 194 chars; A+ tools 50 - 200 chars minimum.
Destructive operation (sendTweet) lacks explicit consequences statement. Description does not say 'This posts to your Twitter account' or 'This action is irreversible'. Agents need to know which calls are safe to retry and which have side effects.
No output schema documentation. getTweet returns tweet.text (a string); sendTweet returns parsed JSON result. Agents cannot plan downstream calls or extract structured data without knowing the response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 7 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No error recovery guidance. Errors are caught and wrapped in UserError, but descriptions do not explain how to recover (e.g., 'If authentication fails, verify TWITTER_USERNAME and TWITTER_PASSWORD in .env'). Error responses must tell the LLM what to do next.
No confirmation/dry-run pattern for destructive sendTweet. A single-use tool that posts tweets has irreversible consequences. Best practice: offer a dry_run parameter or separate confirm_send_tweet step to prevent accidental posts.
Inconsistent output handling. getTweet returns raw string (tweet.text); sendTweet returns JSON object (result.json()). Agents expect structured, consistent response types. This forces per-tool parsing logic.
Parameter descriptions are minimal single-sentence strings. 'The ID of the tweet to retrieve' and 'The text content of the tweet to send' do not specify format (tweetId: is it numeric, alphanumeric? text: max length?), constraints, or examples.