Updated July 2026: adds the official X hosted MCP server (launched June 30, 2026) and refreshes X API pay-per-use read rates against the April 20, 2026 change.
Key Takeaway: AI agents and coding tools reach public X/Twitter data three ways: an MCP server that exposes read tools to chat clients, an agent skill that teaches coding tools the endpoints, and a plain REST API called from generated code. Read-only access keeps autonomous agents off user accounts, and flat per-request billing avoids per-resource costs.
Most guides about a Twitter API for AI agents assume the agent is going to post. Watch a feed, draft a reply, publish. That is one job, and the official X API owns it. The larger and faster-growing job is reading: an agent that searches conversations, pulls a profile, checks who follows whom, or collects tweets for a model to summarize. Reading is where a managed, read-only data layer beats wiring an autonomous agent into a write-capable account.
That is the gap Sorsa API, an alternative Twitter/X API built for read-heavy access, fills for AI builders. It exposes 40 read endpoints across profiles, tweets, search, followers, Lists, Communities, and verification checks, with a single API key in an ApiKey header (no OAuth, no app review), flat per-request billing from $0.02 per 1,000 tweets, and a flat 20 requests per second on every plan. New accounts get 100 free requests, one time, no credit card, on all 40 endpoints, which is enough to wire an agent to real data before paying anything.
This guide covers the three connection paths, how read-only changes the safety math for autonomous agents, how the pieces map to the tools people actually use (Claude Desktop, Cursor, Claude Code, Codex, Windsurf, and vibe-coding builders), and what the data costs at agent scale.
On this page
- Why AI agents and coding tools need a Twitter/X API
- Three ways to connect Twitter/X data to AI tools
- Read-only or write access: what an autonomous agent needs
- The official X API and its hosted MCP server
- What Twitter/X data costs for an AI agent
- Which path fits which tool
- How a small team wired an agent to live X data
- FAQ
- Getting started
Why AI agents and coding tools need a Twitter/X API {#why}
AI agents and coding tools need a Twitter/X API because a language model has no live access to the platform on its own: its training data is frozen, and X blocks unauthenticated scraping. An API turns "what are people saying about this" into a structured call the model can make, get back clean JSON, and reason over, without the model inventing an answer.
The demand is not niche. In Stack Overflow's 2025 Developer Survey of more than 49,000 developers, 84% of respondents are using or planning to use AI tools in their development process, up from 76% in 2024, and 51% of professional developers use AI tools daily. Those tools increasingly reach outside their own context for real data, and public social conversation is one of the most requested sources.
Two distinct readers show up in practice. The first is an agent at runtime: a monitoring agent, a research assistant, a support bot that needs to check a public account. The second is the coding tool itself at build time, where Cursor or Claude Code writes the integration code and needs to know the endpoints, the auth, and the response shapes to get the calls right. The three paths below serve both.
Three ways to connect Twitter/X data to AI tools {#three-ways}
There are three ways to give AI tools Twitter/X data: an MCP server for chat clients, an agent skill for coding tools, and the REST API called directly from generated code. They are not competitors; they suit different tools, and the same API key works across all three.
Option 1: An MCP server for chat clients
An MCP server is the fastest path for a chat-style client. The Model Context Protocol is an open standard, introduced by Anthropic in late 2024, that lets an AI application call external tools in one uniform way. An MCP server exposes a set of tools; the client speaks the protocol; the model picks the right tool for each request. The Sorsa MCP server wraps the read endpoints so any MCP-compatible client gains native tools for searching tweets and reading profiles, followers, replies, mentions, and trends.
It runs locally through npx, so there is nothing to clone or build. Point it at your key and restart the client:
{
"mcpServers": {
"sorsa": {
"command": "npx",
"args": ["-y", "sorsa-mcp"],
"env": {
"SORSA_API_KEY": "YOUR_KEY"
}
}
}
}
That same block works in Claude Desktop, Cursor, VS Code with GitHub Copilot, Windsurf, and any other MCP client. The server exposes one tool per endpoint (40 in total), all read-only. The MCP server source is on GitHub under an MIT license. For the full client-by-client walkthrough, see the dedicated Twitter MCP Server guide; this section is the short version.
Option 2: An agent skill for coding tools
For coding agents that build and run workflows, an agent skill fits better than a chat tool. A skill in the open SKILL.md format is a folder of instructions an agent reads to learn a capability: how to authenticate, which endpoint matches which goal, and how to paginate and batch. Unlike an MCP server, which the model calls at chat time, a skill teaches a coding agent to write correct API code itself, then run it inside a real project.
The open SKILL.md skill for the Sorsa API works with any agent that reads the format: Claude Code, Cursor, Codex CLI, and others. Manual install is a copy into the agent's skills directory:
git clone https://github.com/Sorsa-io/sorsa-x-api-skill ~/.claude/skills/sorsa-x-api
export SORSA_API_KEY=your_key
After that, a prompt like "get the 100 most recent followers of @elonmusk" or "search X for popular posts mentioning Solana this week" is enough. The skill tells the agent to authenticate with the ApiKey header, choose the endpoint (/followers for followers, /search-tweets for search), and page through results. It ships with runnable Python and curl examples plus a small client that handles retry and pagination, so the agent reuses request plumbing instead of rewriting it.
The skill route is the one most competitor pages skip, and it is the natural fit for the read side of an agentic workflow: the agent decides when X data is needed and fetches it on its own.
Option 3: The REST API and AI-readable docs for vibe coding
When you build the app yourself and let an AI write the integration, call the REST API directly. Vibe coding, building software by describing it in plain language, was Collins Dictionary's word of the year for 2025, and tools like Cursor, Bolt, Lovable, and Replit now ship working apps from prompts. The bottleneck for any external API in that flow is whether the model knows the API well enough to write correct calls.
That is what AI-readable documentation solves. Alongside the human docs, Sorsa publishes an AI-readable version of the documentation: a plain-text reference an agent can pull into context and parse without fighting HTML or rendering. Pasting or linking that into Cursor or Claude Code gives the model the endpoint list, parameters, and response fields, so the generated requests match the real API on the first try.
The API itself stays simple, which keeps generated code short. A profile lookup is one authenticated GET:
import os, requests
r = requests.get(
"https://api.sorsa.io/v3/info",
headers={"ApiKey": os.environ["SORSA_API_KEY"]},
params={"username": "elonmusk"},
)
r.raise_for_status()
print(r.json()["followers_count"])
Search is a POST with a JSON body that accepts Twitter advanced-search operators through the tweet search endpoint:
curl -X POST "https://api.sorsa.io/v3/search-tweets" \
-H "ApiKey: $SORSA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"query": "from:elonmusk min_faves:1000", "order": "popular"}'
From there, the followers endpoint returns up to 200 profiles per call, batch endpoints take up to 100 tweets or profiles per request, and the same key covers everything. For a fuller orientation, the build-with-AI guide and the API quickstart walk through the setup end to end.
Read-only or write access: what an autonomous agent needs {#read-only}
For most AI use cases, an agent needs to read public X data, not write to an account, and read-only access removes a real class of risk. An agent that can only read cannot post, delete, follow, or send a DM no matter what a prompt injection in a scraped reply tells it to do. That is a meaningful guardrail when the agent runs on its own.
The trust data backs the caution. The same Stack Overflow 2025 survey found a sharp gap between use and confidence: only 29% of 2025 respondents said they trust AI, down 11 percentage points from 2024, and the top frustration, cited by two thirds of developers, was AI output that is almost right but not quite. When an agent's mistakes are confined to reads, an almost-right action returns wrong data you can catch, not a wrong post on a live account you cannot recall.
This is also the honest concession. If your agent's job is to publish, like, or send DMs, the official X API is the compliant path for write actions on a user account, and no read-only provider replaces it. Some third-party APIs do sell write actions; that is a different tradeoff, since it puts automated writes on real accounts. Sorsa is read-only by design, which keeps API usage off user accounts entirely. For a read-heavy agent, a flat 20 requests per second and flat per-request pricing matter more than write endpoints the agent will never call. For read-only single-key authentication, setup is a key in a header, not an OAuth flow per user.
The official X API and its hosted MCP server {#official-x}
The official X API is the first-party source, and in mid-2026 it added its own MCP layer. Per X's developer announcement, the platform shipped a hosted MCP server on June 30, 2026, letting Grok, Cursor, Claude, or any MCP client read and write X through the developer's own credentials, with a separate MCP server for the developer documentation. It is first-party, OAuth-scoped, and routes every call through the account's X API plan.
The catch that surfaced immediately was cost. The hosted MCP does not change pricing; it sits on the pay-per-use model, so every tool call bills per resource fetched, and observers flagged the per-call bill as the top first-day surprise. For an agent that fires many reads, that adds up in a way a flat plan does not.
For a read-only agent, the differences that matter are setup and cost: the official API needs an OAuth app and bills per resource, while a flat read-only plan needs one key and bills per request.
| Axis | Official X API | Sorsa API |
|---|---|---|
| Setup for an agent | OAuth 2.0 app, review, token refresh per user | single API key in the ApiKey header |
| MCP option | first-party hosted MCP (June 30, 2026), OAuth-scoped, read and write | read-only MCP server, local via npx, no OAuth |
| Access model | pay per resource fetched | flat: 1 call = 1 request |
| Read cost | $0.005 per post, $0.010 per profile | from $0.02 per 1,000 tweets, from $0.01 per 1,000 profiles |
| Write actions | posting, DMs, drafts (compliant path) | none (read-only by design) |
| Free start | no free tier; buy credits first | 100 free requests, no card |
One Sorsa request returns up to 100 tweets or 200 profiles, so the per-1,000 figures use that batch base. Official X API read rates are per the April 20, 2026 pricing.
What Twitter/X data costs for an AI agent {#cost}
For a read-heavy AI agent, a flat per-request plan is far cheaper than per-resource billing, because agents make many small reads and reuse the same data. The official X API charges per resource fetched: $0.005 per post read and $0.010 per user read, so a single tweet returned with its author profile costs $0.015, or about $15 per 1,000. Author data embedded in a search result is billed as a separate user read.
A flat plan inverts that. On Sorsa, 1 API call is 1 request against your monthly quota regardless of how many items it returns, and the author profile inside every tweet response is free. The plans are $49 per month for 10,000 requests (Starter), $199 for 100,000 (Pro), and $899 for 500,000 (Enterprise), each at 20 requests per second. On read-heavy workloads that works out up to 50x cheaper than the official API once volume passes roughly 10,000 post reads per month.
Read the per-tweet number two ways. A bulk ID lookup through /tweet-info-bulk returns 100 tweets per request and lands at the from $0.02 per 1,000 tweets base on Pro. An interactive search through /search-tweets returns about 20 tweets per request, so it works out closer to $0.10 per 1,000 on the same plan, since each call returns fewer items. Both sit far below $15 per 1,000 on the per-resource model, and neither carries the official API's 2 million post-read monthly cap. Cutting request counts with batch calls is covered in optimizing API usage; the full official pricing is in the 2026 X API pricing breakdown.
Which path fits which tool {#which-path}
The right path depends on the tool and the job, not on which is newest. A short decision list:
Claude Desktop, Cursor, or VS Code as a chat client: the MCP server, since it drops read tools in with one config block and no glue code.
Claude Code, Codex, or Cursor building a workflow: the agent skill, which teaches the coding agent the endpoints, auth, and pagination it writes against.
A custom or vibe-coded app: the REST API called from generated code, with the AI-readable docs so the model writes correct requests.
An agent that posts, likes, or sends DMs: the official X API, the compliant path for write actions on a user account.
High-volume, read-heavy data collection: a flat Sorsa plan, where 1 call is 1 request and author profiles come free inside tweet responses.
Many builds mix paths: an MCP server for exploration while prototyping, then the REST API in the shipped app. Collecting tweets to train or fine-tune a model is its own workflow, covered in building a Twitter dataset for machine learning.
How a small team wired an agent to live X data {#case}
A small social-analytics team, around five people, ran a mention-tracking agent on the official X API and watched the per-resource bill climb as coverage grew across more brands. Each tracked mention meant a post read plus a user read for the author, and the OAuth token-refresh code had to be maintained separately for each environment.
Moving the read workload to a flat plan and wiring the agent through the MCP server cut their Twitter data spend by more than 90 percent, and let them delete the per-environment token handling in favor of one key in an environment variable. Because every tool the agent could call was read-only, a prompt injection buried in a scraped reply could not make it post or follow anything, which removed a review step the team had added out of caution. The pattern generalizes to any always-on read agent; the mechanics of continuous polling are in real-time monitoring with the REST API.
FAQ
Can AI agents access Twitter/X data without a developer account?
Yes. A managed Twitter/X data API like Sorsa needs only an API key in an ApiKey header, with no X developer account, OAuth flow, or app review. An agent authenticates with one key and calls read endpoints for profiles, tweets, search, and followers. New accounts get 100 free requests, no credit card, so an agent can pull live data within minutes of signing up.
Should you use the Sorsa MCP server or the agent skill for coding tools?
Use the MCP server for chat clients like Claude Desktop and Cursor, where the model calls read tools directly during a conversation. Use the SKILL.md agent skill for coding agents like Claude Code and Codex that write and run integration code, since the skill teaches them the endpoints, auth, and pagination. Both use the same Sorsa API key, and many builders run both.
Can an AI agent post tweets through the Sorsa API?
No. Sorsa is read-only by design and has no write endpoints, so an agent cannot post, reply, like, follow, or send DMs through it. That is intentional: read-only access keeps autonomous agents off user accounts. For write actions on an account, the official X API is the compliant path; Sorsa covers the read side, which is what most agent and coding-tool workflows actually need.
How much does Twitter/X data cost for an AI agent?
The official X API charges per resource fetched, $0.005 per post and $0.010 per profile, so a tweet with its author runs about $15 per 1,000. Sorsa uses flat per-request billing: $49, $199, or $899 per month for 10,000, 100,000, or 500,000 requests. Bulk lookups land near $0.02 per 1,000 tweets and searches near $0.10 per 1,000, with author profiles included free.
What is the official X MCP server and how is it different?
X launched a first-party hosted MCP server on June 30, 2026, letting AI clients read and write X through the developer's own OAuth credentials, routed through their X API plan. It supports write actions, which read-only servers do not. The tradeoff is cost: it bills on the pay-per-use model per call, while the read-only Sorsa MCP server runs locally and bills per request against a flat plan.
Which AI coding tools work with the Sorsa Twitter/X skill?
The skill uses the open SKILL.md format, so it works with any agent that reads that format, including Claude Code, Cursor, and Codex CLI. The MCP server works with any MCP-compatible client: Claude Desktop, Claude Code, Cursor, VS Code with GitHub Copilot, and Windsurf, among others. Either way, the setup is the same standard configuration and one Sorsa API key.
Getting started {#getting-started}
You can try the data before writing any code. Start in the browser playground to run endpoints from a UI with no signup, then claim 100 free requests to point a real agent at live data. The 100 requests are one time, need no credit card, never expire, and cover all 40 endpoints, which is enough to test the MCP server, the skill, or a direct call end to end.
From there, pick a path. Add the MCP config block for a chat client, clone the skill for a coding agent, or paste the AI-readable docs into your editor and let it write the integration. The full documentation and flat 20 requests per second cover the operational details, and teams moving an existing agent off the official API can follow the migration guide. If you are weighing providers first, the Twitter API alternatives comparison lays out the options with real numbers.
Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.
This guide draws on hands-on operation of the Sorsa API, its live endpoints and public MCP and skill repositories, and the current v3 documentation. External figures were verified on July 11, 2026 against the Stack Overflow 2025 Developer Survey for AI-tool adoption and trust, and against X's own developer announcement of the hosted MCP server (June 30, 2026) and the April 20, 2026 X API pricing update for the cost comparison. The official X API is the primary comparison point throughout.