Loading ToolBench
Twitter search and interaction tool for FastMCP using Tweepy
This server has 7 tools, all READ_ONLY user/follower lookup operations. Naming is clear and verb-prefixed (get_user_*, get_user_followers*, etc.), following the get_noun convention. Descriptions are present but minimal (15-35 chars), below the 50-200 char LLM-optimized range. All tools have input schemas with properly typed parameters and descriptions. However, there is no visible output schema documentation, the source code shows tool registration but not the response structure that downstream agents need to plan follow-up calls. The tools are well-composed (each does one lookup task), but lack critical metadata: no error handling guidance, no pagination limits documented, no chaining IDs returned to enable multi-step flows, and no tool annotations (readOnlyHint, idempotentHint) despite all being read-only. The middleware injects OAuth 2.0 credentials server-side, which is secure. The main issue is that descriptions are too terse for LLM-driven selection and tool responses are not documented.
Fetches a user by ID
Fetches a user by screen name
Retrieves a list of followers for a given user
Retrieves a list of common followers (simulated)
Retrieves users the given user is following
Get detailed profile information for a user
Retrieves a list of users to which the specified user is subscribed (uses following as proxy)
Descriptions are too short (15 - 40 chars) to guide LLM tool selection. Baseline for A+ tools is 50 - 200 chars. Current descriptions lack WHEN to use each tool and how they differ from similar ones (e.g., get_user_followers vs get_user_followers_you_know).
No output schema documented in the source. LLMs cannot infer what fields a get_user_followers response includes (user objects, pagination tokens, total count?). This blocks agents from planning follow-up calls and chaining tool outputs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Pagination tools (get_user_followers, get_user_following, get_user_followers_you_know, get_user_subscriptions) accept a 'count' parameter (default 100, max 100) and 'cursor' for pagination, but the description does not clarify what the response returns, does it include total_count, next_cursor, or both? Without this, agents cannot tell when to stop paginating.
No tool annotations (readOnlyHint, idempotentHint) despite all 7 tools being read-only, idempotent operations. LLMs could benefit from explicit hints to retry failed lookups or batch multiple user requests without concern for side effects.
No error handling guidance. If a user_id is invalid or a rate limit is hit, what should the LLM do next? Descriptions do not say 'Use get_user_by_screen_name if you only have a username' or 'Retry after 60 seconds if rate-limited'.
Ambiguous naming: get_user_followers_you_know does not clearly convey that it returns followers of the target user who are also followed by the agent (common followers). Shorter alternative: get_common_followers or get_mutual_followers with a clearer description.
get_user_subscriptions description says 'uses following as proxy', this is an implementation detail. The description should explain WHAT the user gets (e.g., 'Returns the list of users this account is subscribed to'), not HOW it's implemented. This confuses LLMs about whether the result includes subscriptions to accounts vs. channels vs. topics.