Your agent needs to read and write X. Since June 30, 2026 there are two first-party ways to do it: the hosted MCP server at api.x.com/mcp, and the X API v2 you have probably already integrated against. They look interchangeable in a demo and are not interchangeable in production. The capability surfaces differ, the auth models differ in a way that decides whether multi-tenant agents are even possible, and the metering is identical in a way that will surprise you. Here is how to pick.
These are two different products from the same team, built for two different consumers. One is aimed at a developer sitting in front of an IDE. The other is the platform surface your backend has always called. Knowing which is which saves an architecture rewrite later.
X exposes a Streamable HTTP MCP server at https://api.x.com/mcp, speaking protocol revision 2025-06-18 and identifying itself as xmcp. Its published capability groups are Posts, Search, Users, Bookmarks, News and Trends, and Articles. In practice that means full-archive post search, user and news search, resolving the current user, reading a user's posts, timeline and mentions, listing and managing bookmarks and bookmark folders, pulling trends for a WOEID, and drafting or publishing Articles.
You do not point your MCP client at that URL for user-context work. X requires your own developer app, offers no Dynamic Client Registration, and does not advertise native MCP OAuth discovery on the endpoint. Instead you run the open-source xurl bridge locally over stdio; it owns the app identity, performs a one-time browser login, and injects a fresh Bearer token on every call. Full setup lives in X's MCP documentation.
The X API v2 is the complete platform: Posts, Users, Direct Messages, Spaces, Lists, Likes, Trends, Media, Communities, Community Notes, News, and Compliance, plus Filtered Stream, the X Activity event API, and webhooks for real-time delivery. Volume Streams, Likes Streams, Powerstream, post analytics at scale, and Account Activity sit behind an Enterprise plan.
Authentication accepts three models, documented on X's authentication overview: OAuth 2.0 Authorization Code Flow with PKCE for user context, OAuth 1.0a User Context, and an OAuth 2.0 app-only Bearer Token for public read access. Per-user delegation and app-level service patterns both work, and you choose per workload.
X also hosts a second MCP server at docs.x.com/mcp exposing two tools, search_x and get_page_x, for searching and reading the X API documentation. This is a build-time convenience for your coding agent, not a runtime surface for your product agent. Do not count it as capability coverage.
The interesting differences are not in the tool names. They are in what is missing, who holds the credential, and what a single tool call costs. Each of the four dimensions below changes a different part of your architecture.
The hosted MCP is built around retrieval. It is good at the thing X uniquely owns, which is the live and historical public conversation, and it stops well short of the write surface a social agent typically needs.
The most consequential gap is post creation. A brand-monitoring agent that finds mentions and drafts a reply can read everything it needs over MCP and then cannot send the reply. You end up running the API path anyway for the last step, which means you now maintain both.
The second gap is events. Anything that reacts rather than polls — whether a mention monitor, a follower-change trigger, or a Post create feed for a tracked account — lives in the X Activity API and webhooks. There is no event subscription surface on the MCP server, so a polling loop is your only option, and on X a polling loop is a metered cost line.
This is where the X comparison diverges from every other tool in this series. Most hosted MCP servers are OAuth-only and hand you a per-user session. X does the opposite in both directions: it supports a static app-only token, and it delegates user-context OAuth to a process running on your machine. Understanding why static credentials break in production helps clarify why this matters so much for agent architectures.
The simple route is genuinely simple: paste an app-only Bearer token into an Authorization header on a remote MCP client and read public data. The tradeoff is stated plainly in X's own docs. No auto-refresh, and no user context, which means the agent cannot act as anyone.
The full route runs npx -y @xdevplatform/xurl mcp https://api.x.com/mcp as a stdio child process. On first run with no cached token it opens a browser, holds the MCP handshake open until the login completes, then caches and auto-refreshes the token in ~/.xurl. X recommends a startup timeout of at least 300 seconds for exactly this reason.
Read the bridge as an architecture statement. The credential lives on a filesystem, scoped to a machine, tied to whichever X account happened to be logged into that browser. There is no server-side store, no tenant namespace, and no revocation primitive beyond deleting a file. For a single developer in Cursor that is fine. For a B2B product where every customer connects their own X account, it is not a configuration gap; it is the wrong shape. This is the same fundamental problem explored in how tool calling auth changes when you move from single-tenant to multi-tenant.
On the MCP path, X owns hosting, the tool schemas, and the endpoint normalization. You own the bridge process lifecycle, the token cache on every host that runs an agent, the CLIENT_ID and CLIENT_SECRET that the bridge needs in its environment, and the startup latency of a browser login that no headless job can complete on its own.
On the API path you own more and control more: endpoint selection, pagination, retries, and the full token lifecycle. In exchange you get a versioned, documented contract. MCP tool schemas change when X updates the hosted server, and there is no version header to pin. For a deterministic pipeline where an unexpected schema change is an incident, that distinction decides the question by itself.
X moved to pay-per-usage pricing with no subscription. Reads are charged per resource returned and writes per request, and both paths consume the same credits because MCP tool calls resolve to the same X API endpoints under your own developer app.
Pay-per-usage plans cap at two million post reads per monthly billing cycle, above which you need an Enterprise plan. And a Post containing a link costs more than thirteen times a Post without one, so an agent that shares links has a unit economics problem long before it has a rate limit problem.
Resources are deduplicated within a 24-hour UTC window, which makes caching worth building. Rate limits are separate and orthogonal: 15-minute windows, per-endpoint, applied per user for user tokens and per app for Bearer tokens, as described in X's rate limit documentation.
The hosted server earns its place when a human is present and the work is retrieval.
The API is the answer whenever the agent has to act, react, or serve more than one person.
Strip away the tool schemas and both paths converge on the same unsolved problem. Every user who connects X to your agent produces one X credential, and neither X MCP nor the X API stores, rotates, or revokes it for you.
Fifty customers means fifty OAuth grants, fifty refresh cycles, and fifty revocation events you have to detect. The MCP bridge caches tokens on disk with no tenant boundary. The API hands you a token payload and wishes you luck. In both cases the token must be encrypted at rest, isolated per tenant, and invalidated the moment a user disconnects the app from their X settings, which they can do at any time without telling you. Your agent finds out through a 401 in the middle of a run, if you were watching for it. The challenge of secure token management for AI agents at scale applies to every credential your agent holds, not just X tokens.
Scalekit's X connector runs the OAuth 2.0 flow, holds the per-user tokens in a vault outside your agent runtime, refreshes them automatically, and resolves the right credential at call time. The same infrastructure serves both paths, so choosing MCP or the raw API stops being an auth decision.
Scalekit does not ship a separate X MCP connector, and it does not need to. The X connector is API-backed with 80 prebuilt tools, and MCP delivery is a presentation layer you turn on with a Virtual MCP server. That is the useful arrangement: full API coverage underneath, MCP transport when a client wants it.
In the Scalekit dashboard, go to AgentKit, then Connections, then Create Connection, and pick Twitter. Copy the Redirect URI it gives you into your X app under User authentication settings, set App permissions to Read and Write, then paste your OAuth 2.0 Client ID and Client Secret back into Scalekit and select scopes. For a posting agent that is typically tweet.read, tweet.write, users.read, like.write, and offline.access for refresh tokens.
The connection_name you use in code must match the connection name configured in the Scalekit dashboard exactly. This is the single most common integration error, and it fails in a way that looks like a missing tool rather than a config mistake.
Before any tool call, confirm the user has an active connected account and send them through consent if they do not. This is the only browser step in the whole flow, and unlike the xurl bridge it happens in your product, on your schedule.
The agent should not receive all 80 X tools. It receives the tools this user's connected account is authorized to call, filtered down to what this agent role actually needs. Eighty tools at roughly 200 tokens each is 16,000 tokens spent before the model does any work, and it measurably degrades tool selection. Scoping to four tools fixes both problems at once. This pattern is central to how LangChain tool calling works and where it stops without proper credential management underneath.
The same model in TypeScript, using listScopedTools to build the tool array and executeTool to run the loop. Note that listScopedTools returns pagination metadata, which is why it is the right call for building a tool surface rather than a framework helper.
X ships endpoints faster than any tool catalog tracks them. When you need one that has no prebuilt tool yet, the proxy path sends a raw request with the user's token injected server-side, so you never handle the credential to reach an uncovered endpoint.
If your consumer is an MCP client rather than your own agent loop, a Virtual MCP server gives you a static endpoint that declares exactly which tools are exposed and mints a short-lived, per-user token before each run. One server definition serves every tenant, which is precisely what the xurl bridge cannot do.
Runtime is two calls: confirm the user's connections are still live, then mint a token scoped to that user. Never reuse a token across runs or across users.
The hosted MCP path produces one audit trail, and it belongs to X: your developer app made a call. It cannot tell you which of your users triggered it, because from X's side there is one app and one cached token.
Per-user connected accounts change that. Every execute_tool call returns an execution_id, and Auth Logs record the authorization events, token lifecycle events, and tool calls tied to the connected account that authorized them, with 90 days of history on the X connector. When a compliance reviewer asks who posted from the brand account at 2am, the answer is a query, not a three-week investigation. This kind of per-action traceability is what separates functional agents from production-grade agent tool observability.
If a human is present and the job is reading X, the hosted MCP server is the faster path and the xurl bridge is a reasonable amount of setup. If your agent posts, replies, sends DMs, reacts to events, runs on a schedule, or serves more than one customer, build against the X API v2 with per-user OAuth 2.0 tokens. The hosted server's local token cache and read-heavy tool set are architectural facts, not configuration you can tune around.
Most production X agents will run the API path and expose a scoped subset over MCP for the interactive surface. Both ends need the same thing underneath: one credential per user, stored outside the agent, refreshed before it expires, revocable per tenant, and logged on every call.
Bring your X agent architecture questions to the Scalekit Slack community, or talk to an engineer if you need help now.
Browse the Scalekit X connector docs and the X connector page.
