Updated July 2026: covers the hosted X MCP server launched June 30, 2026, current X API pay-per-use rates after the April 20 change, and single-key setup for a read-only alternative.
Key Takeaway: A Twitter MCP server exposes X data to AI clients like Claude and Cursor as callable tools over the Model Context Protocol. X now runs an official hosted server at api.x.com/mcp, billed through the X API. Third-party read-only servers offer flat pricing and single-key setup instead.
Most of what an AI agent does with X is reading: search the live feed, pull a profile, track mentions, check who retweeted a post. Writing (posting, bookmarking, publishing) is the smaller slice, and it is the part the official server is built around. For the read path, the economics and the setup diverge sharply between the options available in 2026.
That is where the choice matters. Sorsa API, an alternative Twitter/X API provider, ships an open-source MCP server that wraps 40 read endpoints behind a single API key. There is no OAuth flow, no developer-account review, and no per-call surprise. Pricing is flat, from $0.02 per 1,000 tweets, and every new account gets 100 free requests to test an agent end to end before paying anything.
On this page
- What is a Twitter (X) MCP server?
- The Twitter and X MCP landscape in 2026
- Does the official X MCP server cost money?
- Twitter MCP server without OAuth or a developer account
- How to connect the Sorsa MCP to Claude, Cursor, and other clients
- What the Sorsa MCP server can do
- Twitter MCP cost comparison: official X API vs alternatives
- Read-only by design: why it matters for autonomous agents
- Which Twitter MCP server should you use?
- In practice: a research agent that switched paths
- FAQ
What is a Twitter (X) MCP server?
A Twitter MCP server is a small program that exposes X (Twitter) data to AI clients as callable tools through the Model Context Protocol, an open standard for connecting language models to external tools and data. Once it is connected, a client like Claude or Cursor can search tweets, look up profiles, or read trends by describing the task in plain language.
The Model Context Protocol, published by Anthropic as an open standard, works over JSON-RPC. A server advertises a set of tools, each with a name, description, and parameters. The client discovers those tools and can call them mid-conversation, then reads the structured results. The practical benefit over writing your own integration: the client chains the calls itself, so you state the outcome you want and the agent decides which tools to run. That is what makes MCP the standard path for building X data into AI coding tools and agents.
Every Twitter MCP server sits between the AI client and a source of X data. That source is the real decision. It can be the official X API, a third-party X data API, or a scraper, and the choice sets your cost, your reliability, and how much setup stands between you and the first tool call.
The Twitter and X MCP landscape in 2026
Three kinds of Twitter MCP server exist in 2026: the official hosted X server at api.x.com/mcp, community servers that wrap the official X API with your own credentials, and servers built on a third-party X data API. They differ most in cost model, setup friction, and whether they can write to X or only read.
The official X MCP launched on June 30, 2026. It is hosted and first-party: X runs it at api.x.com/mcp over Streamable HTTP, and its announcement cleared millions of views in a day. It exposes the X API across six tool groups (posts, search, users, bookmarks, trends and news, and Articles), with full-archive search and trends by location as its standout tools. Authentication is OAuth 2.0 through a local bridge for writes, or an app-only Bearer token for read-only use. According to TechCrunch's launch coverage, the server exposes existing X API capabilities to agents rather than adding new ones. The MCP layer is free, but every call bills through your X API plan.
Community servers on the official X API filled the gap before that launch and still circulate. They wrap the X API using your own developer credentials, which means several OAuth tokens and an X developer app, plus whatever the X API charges underneath. Quality varies, they are unofficial, and they inherit both the cost and the approval flow of the platform.
Scraper-based servers skip the API entirely, driving browser automation or scraping libraries. They avoid API fees but break when X changes its markup, and they carry terms-of-service risk that makes them a poor base for anything durable.
Third-party data-API servers, including the Sorsa MCP, wrap a managed X data API behind a single key. Pricing is flat or per-call, no X developer account is required, and this is where read-heavy, cost-sensitive agent workloads tend to land. For a wider view of the providers in this category, see how the alternatives to the official X API compare on price and coverage.
Does the official X MCP server cost money?
The MCP layer is free, but the official X server bills every tool call against your X API plan or pay-per-use credits. Reads cost $0.005 per post and $0.010 per user profile. Fixed tiers start at $200 per month (Basic) with a 15,000-read cap and jump to $5,000 per month (Pro). An agent that calls in a loop spends real money on each request.
This is the single most common first-day surprise: developers connect the server, run an agent, and only then realize the "no setup" pitch covers infrastructure, not cost. Pay-per-use accounts also hit a 2 million post-read monthly cap, above which a negotiated X Enterprise contract (historically from around $42,000 per month) is the only path. Those X API rates were verified on July 11, 2026, and the full X API pricing breakdown walks through the April 20 changes in detail.
A quick worked example makes the read cost concrete. Take an agent that reads 100,000 tweets a month for research. On the official X API, that is 100,000 post reads at $0.005 each, or $500 in credits, and the 15,000-read Basic cap cannot cover it, so the plan jumps to Pro at $5,000 per month. The same 100,000 tweets pulled through a batch endpoint on a flat plan is 1,000 requests, comfortably inside a $49 monthly tier. The gap is the whole reason read-heavy teams look past the official API, and it is worth understanding why the X API costs so much before committing an autonomous agent to it.
The setup adds its own friction. The write path needs an X developer app with OAuth 2.0, a registered redirect URI, a local bridge process, and a client startup timeout long enough for a browser login round trip. Read-only access is simpler, one Bearer header, but you still register a developer app. To be clear on where the official server earns its place: for write actions like posting and publishing Articles, the official X API is the compliant, first-party path, and nothing here replaces that. For read-heavy access at a flat, predictable price, a third-party server wins.
Twitter MCP server without OAuth or a developer account
You do not need an X developer account or OAuth to give an agent X data. Servers built on a third-party X data API authenticate with a single API key passed in a header, so setup is one config block and a key rather than an app review, a redirect URI, and a browser login. The tradeoff is read-only access to public data.
The Sorsa MCP server is the read-only case done cleanly. It reads your key from a SORSA_API_KEY environment variable and sends it in the ApiKey header on every request. There is no OAuth dance, no local token cache to guard, and no callback URL to register. Getting a key and adding the config takes roughly three minutes, which lines up with the broader pattern of getting X data without a developer account through a managed API.
Compare that to the official path: Node, an X app with OAuth 2.0 enabled, a redirect URI that must match exactly, a bridge command, and startup-timeout tuning so the first login can finish. The single-key model removes every one of those steps. It also keeps API usage off any user account, because the key authenticates an app, not a person, which matters when an autonomous agent is the thing making calls. The mechanics of single-key authentication are one header and one value.
How to connect the Sorsa MCP to Claude, Cursor, and other clients
Connecting the Sorsa MCP server takes about three minutes: get an API key, add one config block that points npx at the sorsa-mcp package with your key in an environment variable, and restart the client. The same block works for Claude Desktop, Cursor, and any MCP-compatible client.
Step 1: Get a Sorsa API key. Create an account and copy your key. Every new account includes 100 free requests, no credit card, that never expire and cover all 40 endpoints, which is enough to run a real agent workflow before choosing a plan. The Sorsa MCP server page has the current setup details in one place.
Step 2: Add the MCP config. Drop this block into your client's MCP configuration file. The npx command fetches and runs the published package, so there is nothing to install first:
{
"mcpServers": {
"sorsa": {
"command": "npx",
"args": ["-y", "sorsa-mcp"],
"env": {
"SORSA_API_KEY": "YOUR_KEY"
}
}
}
}
For Cursor, add it to ~/.cursor/mcp.json for global use, or .cursor/mcp.json inside a project. For Claude Desktop, edit claude_desktop_config.json (on Windows at %APPDATA%\Claude\, on macOS at ~/Library/Application Support/Claude/), then restart the app. Only SORSA_API_KEY is required; an optional SORSA_BASE_URL defaults to https://api.sorsa.io/v3.
Step 3: Confirm the connection. Ask the client to run the get_key_usage_info tool. It returns your remaining request balance and the key's expiration date, so a valid response confirms both the key and the connection in one step. If it works, the agent is ready to pull data.
If you would rather run from source, the open-source Sorsa MCP repository builds with npm install and npm run build, then points the client at node dist/index.js instead of npx. Either way, the quickstart guide covers keys and the first request.
What the Sorsa MCP server can do
The Sorsa MCP server exposes 40 tools, one per API endpoint, grouped into profiles, tweets, search, communities, verification checks, crypto-audience metrics, lists, and utilities. Every tool is a read: fetch data, never post, like, or follow. That covers most agent research and monitoring tasks without any write access to X.
The tool surface maps directly onto the API. Profiles cover get_user_info, get_followers, get_following, and the batch tool get_user_info_batch, which returns up to 100 profiles in a single call. Tweets include get_tweet_info, get_user_tweets, the bulk tool get_tweet_info_bulk for up to 100 tweets per call, and get_trends. Search gives an agent search_tweets, search_mentions, and search_users. Verification tools such as check_follow and check_retweet confirm campaign actions. Lists, communities, crypto-audience metrics, and utilities like username_to_id round out the set.
Two of those tools deserve attention, because they are the same X-proprietary capabilities the official server leads with. Full-archive tweet search runs through search_tweets, which supports advanced search operators and reaches historical posts back to 2006, so an agent can search tweets through the API across the whole timeline rather than a recent window. Trends by location run through get_trends using a WOEID, giving an agent a clean way to pull trending topics by location. Follower work runs through endpoints that return follower and following lists at up to 200 profiles per request.
The batch tools are what make the flat model cheap for agents. Because get_tweet_info_bulk returns up to 100 tweets and counts as one request, and follower tools return up to 200 profiles per request, a large read job maps to a small number of billable calls. An agent pulling thousands of tweets spends a handful of requests, not thousands.
Twitter MCP cost comparison: official X API vs alternatives
For read-heavy agent workloads, the effective cost per 1,000 tweets is where the paths separate. The official X API bills per resource, third-party APIs vary, and a flat per-request model with batch endpoints lands lowest for volume reads. The table below normalizes each path to the same unit.
| Path | Pricing model | Effective cost per 1,000 tweets | Access |
|---|---|---|---|
| Official X API (via the X MCP) | Per resource, plus fixed tiers | $5.00 (post reads) | Read and write |
| TwitterAPI.io MCP | Pay-per-call | ~$0.15 | Varies by build |
| Sorsa MCP | Flat per-request | from $0.02 (batch) | Read-only |
Sorsa's per-1,000 figure is the batch base: one request to a bulk endpoint returns up to 100 tweets, and one request to a follower endpoint returns up to 200 profiles, so volume reads collapse into few billable calls. Flat plans run from $49 per month for 10,000 requests, on flat per-request pricing with a 20 request-per-second limit on every tier. The X API read rate of $0.005 per post and the TwitterAPI.io per-1,000-tweet price were both verified on July 11, 2026.
The takeaway is direct: on read volume, the flat per-request model is the cheapest of the three, and for read-heavy workloads it runs up to 50x cheaper than the official X API once you clear roughly 10,000 tweet reads a month. The official API stays ahead only where writes or first-party status are the requirement, not the cost.
Read-only by design: why it matters for autonomous agents
A read-only Twitter MCP server cannot post, like, follow, or spend on write actions, which removes a whole class of risk when an agent runs on its own. An agent stuck in a loop on a read-only, flat-rate server wastes requests inside a fixed plan, not real money per call and not an unwanted post on a live account.
That combination, per-call billing plus write access, is exactly what makes autonomous agents dangerous on the official server. A loop that keeps searching is a billing event on every pass, and a loop with write scope can publish or bookmark without a human in the way. The community's hard-won rule for the official server is to have an agent create a draft and never publish without a separate, explicit command. A read-only server removes the need for that rule on the read path: there is no write scope to misuse, and a runaway loop only burns requests inside a plan you already capped.
Flat pricing closes the other half of the gap. When 10,000 requests cost a fixed $49, a misbehaving agent has a hard ceiling instead of an open meter. For agents that read tool documentation to understand their own capabilities, the LLM-readable API documentation gives the model a clean reference for every endpoint. When you do need writes with a human approving each one, the official X API remains the right path; for the read path that most agents live on, read-only plus flat pricing is the safer default.
Which Twitter MCP server should you use?
Read-heavy research or monitoring agents: a flat-rate read-only server like the Sorsa MCP, for predictable cost and single-key setup.
Posting, bookmarking, or publishing Articles from an agent: the official X MCP, the compliant first-party path for writes.
A quick experiment or hobby posting bot: a community server on your own X credentials, accepting the setup and stability tradeoffs.
Full official X API surface with first-party support: the official X MCP, billed through your X plan.
For most production read workloads, flat pricing and read-only safety make a third-party server the default choice. The official server earns its slot when writes or first-party status are non-negotiable, and there is no reason not to run both: a read-only server for the volume data an agent pulls, and the official API behind a manual step for the rare write.
In practice: a research agent that switched paths
A small AI product team, roughly six people, hit this split building a research agent. They wired up the official X MCP first, and the agent worked, but a few autonomous runs that looped over full-archive searches turned into a per-call bill nobody had modeled. Moving the read path to a flat per-request server cut their X data costs by more than 90 percent, and they kept the rare publish action on the official API behind a manual approval step. The agent now reads through one key on a flat plan, and a human still presses publish.
FAQ
Is there an official Twitter MCP server?
Yes. X launched a hosted MCP server at api.x.com/mcp on June 30, 2026. It exposes the X API to AI clients across six tool groups, including full-archive search, trends, and posting. The MCP layer is free, but every tool call bills against your X API plan or pay-per-use credits, so a connected agent spends real money on each request.
Do you need an X developer account to use a Twitter MCP server?
Not always. The official X MCP and community servers built on the X API require an X developer app and, for writes, an OAuth 2.0 flow. Servers built on a third-party X data API, such as the Sorsa MCP, authenticate with a single API key in a header, so there is no developer-account review and no OAuth. The tradeoff is read-only access to public data.
How much does a Twitter MCP server cost?
The MCP software is usually free; the data behind it is what costs. The official X API bills reads at $0.005 per post with fixed tiers from $200 per month. A flat per-request alternative runs from $0.02 per 1,000 tweets on the batch base, with plans from $49 per month for 10,000 requests. Pay-per-call third-party APIs sit in between.
Can a Twitter MCP server post tweets?
Some can, some cannot. The official X MCP can post, bookmark, and publish Articles once you complete the OAuth flow, and writes are rate-limited more strictly than reads. Read-only servers cannot post, like, or follow by design, which suits research and monitoring agents that only need to pull data and should never touch a live account.
Which MCP clients work with a Twitter MCP server?
Any MCP-compatible client works, including Claude Desktop, Cursor, VS Code in agent mode, and Grok Build. Connection is a config block in the client's MCP settings file. For a key-based server like the Sorsa MCP, the block points npx at the package with your API key in an environment variable, and the same block works across every client.
What can an AI agent do with X data through MCP?
An agent can search the live feed and the historical archive, pull profiles and follower lists, track mentions of a brand, read trends by location, and verify follows or retweets for a campaign. Because the client chains the tool calls itself, you describe the outcome in plain language and the agent selects which tools to run.
Getting started with a read-only X MCP
The fastest way to see whether an agent workflow holds up is to run it against real data. Every new Sorsa account includes 100 free requests, no credit card, that never expire and cover all 40 endpoints, enough for up to 10,000 tweets or 20,000 profiles. Add the config block, point your client at the server, and confirm the connection with the get_key_usage_info tool. From there, the browser playground lets you test endpoints without code, and the flat per-request plans scale the same key into production.
Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.
This guide draws on hands-on operation of the Sorsa API and its MCP server, the live sorsa-mcp package on npm, and the open Model Context Protocol specification. Details on the official X MCP come from public launch coverage, including TechCrunch; the four paths above were compared on setup and current pricing. X API rates and the third-party price cited were verified on July 11, 2026, against provider sources.