Loading ToolBench
MCP server for ScrapeBadger - Twitter/X scraping API for AI agents
ScrapeBadger MCP server has consistent naming, complete parameter schemas with validation constraints, and clear descriptions across all 16 tools. However, output schemas are completely undocumented, no schema definitions for what these tools return to the LLM. Error handling is absent from the source code provided. The server implements proper input validation via Pydantic models and constraint annotations (e.g., max_results with ge/le bounds), but lacks recovery guidance and error categorization. Tool descriptions are adequate (120-180 chars average) but could be more prescriptive about when to use each tool vs. similar ones. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY.
Get details about a Twitter community including name, description, member count, rules, and admin information.
Get followers of a Twitter/X user. Returns list of follower profiles with their bios and follower counts.
Get accounts that a Twitter/X user is following. Returns list of following profiles with their bios and follower counts.
Get details about a Twitter list including name, description, member count, subscriber count, and owner information.
Get recent tweets from a Twitter list. Returns tweets from all list members with text, metrics, and media.
Get trending topics for a specific location using WOEID. Common WOEIDs: US=23424977, UK=23424975, Japan=23424856.
No output schemas documented. Tools return Pydantic model instances serialized via _serialize_model(), but LLMs receive no schema definition of expected fields, types, or structure. This forces LLMs to infer what fields are available and their types, increasing hallucination risk and preventing reliable field extraction for downstream tool composition.
No error handling or recovery guidance in tool implementations. The code wraps ScrapeBadgerError but provides no categorization (retryable vs. user-fixable vs. fatal) and no recovery guidance. When a tool fails (e.g., 'User not found'), the LLM receives no hint about what to try next (search_twitter_users? Correct the username?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2026-07-28+ | v2 |
Get current trending topics on Twitter/X. Optionally filter by category (news, sports, entertainment). Returns trend names and tweet counts.
Get a single tweet by ID. Returns tweet text, author, metrics (likes, retweets, replies), media, polls, and quoted tweets.
Get extended 'About' information for a Twitter/X user including account location, username change history, and verification details.
Get a Twitter/X user's profile by username. Returns name, bio, follower count, following count, verified status, and more.
Get recent tweets from a Twitter/X user. Returns tweets with text, metrics, media, and engagement data.
Search for Twitter communities by query. Returns matching communities with names, descriptions, and member counts.
Search for Twitter lists by query. Returns matching lists with names, descriptions, and member counts.
Search for Twitter places by name. Returns place names, types, and full location details for use with geolocated tweets.
Search for tweets by query. Returns matching tweets with text, authors, metrics, and media. Supports advanced Twitter search operators.
Search for Twitter/X users by query. Returns matching profiles with bios, follower counts, and verification status.
Missing tool annotations despite all tools being READ_ONLY. No readOnlyHint, destructiveHint, or idempotentHint annotations provided in tool definitions. This prevents clients from understanding tool safety properties and optimizing caching/retry logic.
Descriptions lack disambiguation guidance for similar tools. For example, search_twitter_users, get_twitter_followers, and get_twitter_following all return user lists but with different semantics. The descriptions do not explain when to use each, forcing LLMs to reason through the names alone and risking wrong tool selection.
No pagination or result limiting guidance for list-returning tools. Tools like get_twitter_followers, get_twitter_following, and get_twitter_user_tweets accept max_results constraints but do not document whether they support pagination (cursor, offset, next_token) or return a total_count. This limits scalability and LLM planning.
Parameter descriptions for search/filter tools do not document supported query syntax. For example, search_twitter_tweets description mentions 'Supports advanced Twitter search operators' but does not enumerate them or link to documentation. LLMs cannot infer valid syntax without explicit guidance.