Loading ToolBench
TwitterAPI.io MCP server providing offline access to docs (endpoints, pages, blogs) for Claude and other AI assistants
TwitterAPI.io MCP server provides 7 read-only tools with moderate quality. All tools have descriptions and input schemas are present. However, schema completeness varies significantly. Tool descriptions are clear but generic (no LLM optimization like dependency hints or prerequisite guidance). Parameter descriptions exist but lack detail on constraints, formats, and valid ranges. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite all being read-only operations. Error handling includes classification and suggestions but lacks recovery patterns for specific failure modes. Output schemas are not documented in tool definitions. The server treats offline documentation as a homogeneous resource, missing opportunities to compose tools around distinct user intents (e.g., separate 'browse endpoints' from 'get endpoint details').
Retrieve TwitterAPI.io authentication details including required headers, base URL, and API key dashboard URL.
Retrieve detailed information about a specific TwitterAPI.io endpoint including parameters, description, cURL examples, and response schema.
Retrieve a static guide page from the documentation by name (pricing, authentication, qps_limits, tweet_filter_rules, etc.). Returns the full formatted guide content.
Get TwitterAPI.io pricing information including credits per USD, minimum charge, and cost breakdown by operation type.
Fetch and return the content of a TwitterAPI.io documentation URL or path (e.g. /pricing, /api-reference, /blog/...). Performs path-based or URL-based access to guides and pages.
List all available TwitterAPI.io endpoints with brief descriptions. Returns endpoint names and summaries for browsing the API catalog.
No output schemas documented. Tool descriptions do not specify what fields/structure the LLM should expect in responses (e.g., search_twitterapi_docs returns 'matching content with snippets and relevance ranking' but no structured schema). LLMs cannot reliably parse responses or plan downstream operations without knowing return types.
Parameter descriptions lack constraint details. 'query' parameter accepts max 1000 chars but the description does not explain the practical implication or what happens on overflow. 'guide_name' accepts specific values (pricing, authentication, qps_limits, etc.) but should be an enum, not a free-form string. This invites hallucinated values from the LLM.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search through TwitterAPI.io documentation (endpoints, pages, blogs) with keyword-based matching. Returns matching content with snippets and relevance ranking.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint) despite all tools being read-only and safe. Tool annotations in current MCP spec help the LLM understand safety properties without parsing descriptions. Missing these reduces the LLM's ability to parallelize calls or reason about retry safety.
get_twitterapi_url tool is ambiguous. Description says 'Fetch content of a TwitterAPI.io documentation URL or path' but doesn't clarify when to use this vs get_twitterapi_guide or search_twitterapi_docs. Parameter accepts 'Full URL or path (e.g. https://twitterapi.io/pricing, /pricing, docs_home)', three different formats. No clear guidance on which format to prefer or what each returns.
Descriptions lack dependency hints and discovery guidance. E.g., search_twitterapi_docs description does not say 'If you need details about a specific endpoint, call get_twitterapi_endpoint' or 'For pricing info, use get_twitterapi_pricing'. This forces the LLM to reason through the entire tool set rather than guiding it to efficient call chains.
Error handling includes suggestions (e.g., 'Error: {message}\n\nSuggestion: ...') but the code does not show how suggestions are populated for each error case. Generic suggestions risk being unhelpful. Specific examples: what if search returns no results? What if guide_name is not recognized? Current implementation appears to only show error.message + error.suggestion, which requires suggestion to be pre-computed.