A Model Context Protocol server that allows interaction with Twitter, enabling posting tweets and searching Twitter.
The Twitter MCP server provides two tools with basic input schemas and descriptions, but falls short of production quality. Tool naming is appropriate (post_tweet, search_tweets), but descriptions are generic and lack context about when to use each tool or prerequisites. Parameter descriptions are present but minimal. Output schemas are not documented, and error handling provides generic responses without recovery guidance. The server is STDIO-only, which is a hard transport limitation.
Post a new tweet to Twitter
Search for tweets on Twitter
Output schemas not documented. LLMs cannot plan downstream steps or extract results without knowing what fields are returned.
Tool descriptions are too brief (15-31 chars). These descriptions lack WHEN to use each tool and prerequisites.
Error handling returns generic text responses without recovery guidance. E.g., rate limit error says 'Please wait a moment' but does not suggest retry delay or next steps.
Parameter 'count' in search_tweets has a description but lacks context about how results are ranked or filtered. Is it newest first? Most relevant?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No pagination support in search_tweets. Without offset/limit and total_count, large result sets will blow context windows. Tool description does not mention result limit or pagination.
API credentials (API_KEY, API_SECRET_KEY, ACCESS_TOKEN, ACCESS_TOKEN_SECRET) are loaded from environment and passed to TwitterClient, but no audit logging or permission checks documented. Destructive tool (post_tweet) should have permission gates and audit trails.
post_tweet has no dry-run or confirmation mechanism. Agents can inadvertently post tweets without verification. Irreversible operations should support confirmation patterns.