By Alex (TwitterAPI.io team)
Disclosure: I work on TwitterAPI.io, which runs the MCP server described here. Written with AI assistance; the commands and outputs come from my own runs.
Models don't know what was posted on X an hour ago. A read-only MCP server fixes that: the client calls a tool, the server calls the X data API, the model reads the JSON. Below is the config I used, what the server exposes, and two prompts that worked.
1. Check the server before wiring it up
The server is hosted, so there's nothing to install. It speaks streamable HTTP and takes your API key as a Bearer token:
curl -s -X POST https://mcp.twitterapi.io/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "Authorization: Bearer $TWITTERAPI_KEY" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
When I ran it, tools/list returned 12 read-only tools: search_tweets, get_user_info, get_user_about, get_user_followers, get_user_followings, get_user_last_tweets, get_user_mentions, get_tweets_by_ids, get_tweet_replies, get_tweet_quotes, get_tweet_retweeters and get_trends. There are no write tools, so a model can't post for you.
2. Client config
Field names differ per client; these two are the common shapes.
Cursor (remote URL), ~/.cursor/mcp.json:
{
"mcpServers": {
"twitterapi": {
"url": "https://mcp.twitterapi.io/mcp",
"headers": { "Authorization": "Bearer YOUR_TWITTERAPI_KEY" }
}
}
}
Claude Desktop, claude_desktop_config.json (runs the npm package locally):
{
"mcpServers": {
"twitterapi-io": {
"command": "npx",
"args": ["-y", "@twitterapi_io/mcp-server"],
"env": { "TWITTERAPI_IO_API_KEY": "YOUR_TWITTERAPI_KEY" }
}
}
}
Keep the key in your client's secret store or an env var where it supports one; don't commit the file.
3. Prompt one: what are developers saying about a topic
Search the latest English tweets for "mcp server", no retweets, at least 5 likes. Group them into 3 themes and quote one tweet per theme with its author handle.
Under the hood this is one search_tweets call with query = "mcp server" lang:en -filter:retweets min_faves:5 and queryType = "Latest". My run returned 20 tweets in one page plus a next_cursor, so the model can ask for more pages if you tell it to.
4. Prompt two: summarise what an account has been posting
Fetch the latest tweets from the Anthropic account and tell me which got the most likes and what they were about.
That maps to get_user_last_tweets with userName = "anthropicai". Another 20 tweets came back, with like counts attached, which is enough for the model to rank them without extra calls.
What to watch
- Tools are billed like the REST API: per result returned, about $0.15 per 1,000 tweets at the time of writing, so a 20-tweet search costs a fraction of a cent. Check https://twitterapi.io/pricing before letting an agent loop. New accounts get up to $1 in free credits (bot check, one per person and network, expires after 31 days).
- Pagination is cursor-based. Tell the model how many pages it's allowed to fetch.
- Tweet text can contain HTML entities such as
>; models cope, but your own parsers shouldn't assume plain text.
Setup details and the full tool list: https://twitterapi.io/twitter-mcp-server
Top comments (1)
Read-only tools are an important first boundary, and the pagination cap is the practical second one. I’d add that returned post text should be treated as untrusted data by the client: a prompt embedded in a tweet must never influence tool selection, credentials, or the allowed page count. The useful contract is not just “no write tools,” but “retrieved content cannot widen authority.”