Loading ToolBench
A collection of MCP servers including Twitter API and WordPress REST API integrations
Server has 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-200 chars range, mostly adequate), and input schemas are present with type definitions. However, parameter descriptions are inconsistent, some parameters lack clarity on constraints, ranges, or valid values. Output schemas are not documented. Error handling returns strings rather than structured objects, making LLM parsing difficult. No tool annotations (readOnlyHint/destructiveHint). Twitter tools expose API token validation in descriptions rather than handling silently. WordPress tools lack pagination guidance despite accepting limit/page parameters. Overall pattern adherence is ~40%, typical of community servers.
Get WordPress categories. Args: limit: Maximum number of categories to return (default: 20) Returns: Formatted category information
Get WordPress pages. Args: limit: Maximum number of pages to return (default: 10) Returns: Formatted page information
Get a single WordPress post by ID. Args: post_id: ID of the post to retrieve Returns: Detailed post information
Get WordPress posts with optional filtering. Args: limit: Maximum number of posts to return (default: 10) page: Page number for pagination (default: 1) category_id: Filter posts by category ID tag_id: Filter posts by tag ID search: Search term to filter posts Returns: Formatted post information
Get WordPress tags. Args: limit: Maximum number of tags to return (default: 20) Returns: Formatted tag information
Output schemas not documented. Tools return free-text strings (e.g., 'Tweet posted successfully!\nTweet ID: ...') instead of structured JSON objects. LLMs cannot reliably parse unstructured text responses, increasing hallucination risk and token waste.
Parameter constraints missing or vague. 'max_results' in search_recent_tweets states '(default: 10, max: 100)' in description but no minItems/maxItems in schema. 'sort_order' accepts 'recency' or 'relevancy' but no enum constraint in schema. LLMs cannot validate inputs without formal constraints.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). post_tweet is destructive (WRITE risk) but lacks destructiveHint annotation. Search and get tools are read-only but lack readOnlyHint. Agents cannot distinguish safe from risky operations without annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Post a new tweet to Twitter. Args: text: The content of the tweet (required) reply_to_tweet_id: ID of the tweet to reply to (optional) quote_tweet_id: ID of the tweet to quote (optional) Returns: Result of the tweet creation including tweet ID and URL
Search for recent tweets matching a query. Args: query: Search query text (required) max_results: Number of results to return (default: 10, max: 100) start_time: Oldest timestamp to include (format: YYYY-MM-DDTHH:mm:ssZ) end_time: Newest timestamp to include (format: YYYY-MM-DDTHH:mm:ssZ) sort_order: Order of results - "recency" or "relevancy" (default: recency) Returns: Formatted list of matching tweets
Error handling returns unstructured strings. twitter_request() returns {'error': True, 'message': '...'} but tools format this into plain text. LLMs cannot programmatically detect error type (retryable vs fatal) or extract recovery guidance. No error classification per pattern:error-classification.
Pagination not fully specified. get_posts, get_categories, get_tags, get_pages accept 'limit' and 'page' but no 'total_count' or 'next_cursor' documented in output. LLMs cannot determine if more results exist or how to fetch them efficiently.