Loading ToolBench
Official Model Context Protocol (MCP) server for twitterapi.io — Twitter / X data API. Search tweets, get user profiles, followers, replies, trends — all via Claude Desktop, Cursor, or any MCP-compatible client.
Strong tool naming (all verb_noun pattern) and comprehensive parameter descriptions. Schemas are well-defined with Zod validation. However, tool descriptions are verbose (200-400+ chars, exceeding the 10-200 char guidance) and contain example values that LLMs may reuse literally. Output schemas are not documented, responses are transformed but the structure is not declared. Error handling is minimal. 11 of 12 tools have good naming and descriptions; composition is sound with clear single responsibilities.
Fetch trending topics for a location. Returns top trends with tweet volume. Use this to discover what's trending globally or in a specific region, or to find relevant hashtags for a topic.
Fetch quote-tweets (retweets with comment) of a tweet. Returns ~20 quotes per page. Use this to find commentary on a tweet, analyze public opinion, or track how a tweet is being discussed.
Fetch replies to a tweet. Returns ~20 replies per page. Use this to analyze conversation threads, find responses to a tweet, or understand public reaction.
Fetch users who retweeted a tweet. Returns ~100 users per page. Use this to find who amplified a tweet, analyze reach, or identify engaged audiences.
Fetch tweets by their numeric IDs. Batch fetch up to 100 tweets in one call. Use this to retrieve specific tweets when you have their IDs, or to re-fetch tweets for updated engagement metrics.
Tool descriptions exceed 200 chars and contain example values (e.g., 'from:elonmusk since:2026-01-01'). LLMs tend to reuse examples literally rather than adapt to context, causing incorrect queries.
Output schemas are not documented. The transformer (compactResponse) strips fields and flattens responses, but the LLM has no schema to understand the returned structure. This forces the LLM to infer field names and types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2026-07-28+ | v2 |
Fetch a user's profile 'about' / bio page. Returns extended profile information including bio, location, website, and other metadata. Use this to get detailed information about a user's profile.
Fetch the followers of a user. Returns a paginated list of user profiles (name, bio, follower count, etc). Use this to analyze a user's audience, find influencers in a niche, or monitor follower growth.
Fetch the accounts a user follows. Returns a paginated list of user profiles. Use this to analyze a user's interests, find similar accounts, or understand their network.
Fetch a user's profile information (name, bio, follower count, verification status, etc). Returns a single user object with full metadata. Use this to identify a user, check their verification status, or get their follower count.
Fetch a user's recent tweets (timeline). Returns ~20 tweets per page in reverse chronological order. Use this for recent activity, NOT historical/date-range queries (use search_tweets instead). Optionally include replies.
Fetch tweets that mention a user. Returns ~20 tweets per page. Use this to monitor brand mentions, track conversations about a person, or find replies to a user.
🎯 PRIMARY CHOICE for date-range / historical / keyword-based tweet queries. Use this (NOT get_user_last_tweets) whenever user asks about a SPECIFIC TIME RANGE or historical tweets: • 'tweets from January 2026' → query='from:elonmusk since:2026-01-01 until:2026-02-01' • 'tweets between X and Y' → 'from:USER since:X until:Y' • 'tweets last week / last month' → translate to since:/until: dates • 'tweets containing keyword X by user Y' → 'from:Y X' • 'older tweets' / 'archive' / 'in 2025' → use date range, not pagination Date format: YYYY-MM-DD (UTC midnight). 'until:' is exclusive (until:2026-02-01 = up to Jan 31). General: Search Twitter/X for tweets matching a query. Supports the full Twitter advanced search syntax (from:, to:, since:, until:, lang:, filter:, has:, -, OR, etc). Returns ~20 tweets per page in reverse chronological order ('Latest') or by engagement ('Top'). Use this for keyword research, monitoring mentions of a brand/topic, finding tweets in a date range, or discovering conversations.
Error handling is not visible in tool definitions. No guidance on retryable vs. fatal errors, no recovery suggestions, and no error classification. LLMs will not know how to respond to API failures.
get_user_last_tweets has mutually exclusive parameters (userName vs userId) but no validation or clear guidance on which to prefer. LLMs may pass both, causing ambiguous behavior.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. All tools are read-only, but this is not declared to the MCP client, limiting optimization opportunities.