Connecting X to your AI assistant

Someone tells you their assistant watches X for them now. You look into it and find that X runs an official MCP server at https://api.x.com/mcp, described in one line as a way to “Call X API endpoints (search posts, look up users, bookmarks, trends, news, Articles, and more)” [1]. The setup is a URL, an approval screen and a token. That is the entire friction. Ten minutes later your assistant can search the full post archive and read profiles, and you have not yet decided what any of it is for.

This guide is for a solo operator or a small team deciding whether X data belongs in an AI workflow: competitive monitoring, a trend check before you publish, audience research before you position something. It is not for anyone who needs bulk historical data at research scale, and it is not for anyone hoping to automate posting, because X’s own automation rules close most of that door before the pricing does. Two things settle the decision, and neither is about the protocol. The first is what each read costs now that X bills per resource. The second is what you are actually handing over when you approve that screen.

A connector is a token you issue and a meter you open

MCP is an open protocol for connecting model applications to outside data and tools, built on JSON-RPC 2.0 between hosts, clients and servers, where servers expose resources, prompts and tools, and tools are functions the model executes [5]. The current specification is dated 2026-07-28 [5]. That is the whole idea, and it is genuinely useful. It is also worth reading what the specification itself says about the arrangement, because it is unusually direct. Tools “represent arbitrary code execution and must be treated with appropriate caution”, and descriptions of tool behaviour “should be considered untrusted, unless obtained from a trusted server” [5]. Users “must explicitly consent to and understand all data access and operations” [5].

X publishes two servers. The X MCP server calls the X API. A separate Docs MCP server at https://docs.x.com/mcp does nothing but “Search and read X API documentation” [1], which is a reasonable first thing to connect because it cannot touch your account.

When you connect the first one, two things happen that are easy to miss because they happen behind a single approval. A credential is issued in your name carrying a set of scopes, which decides what an agent acting as you is permitted to do. And a billing relationship starts, because every call the assistant makes draws down a credit balance. Most of the mistakes people make here are made in those two places, not in the setup.

X bills per resource, so a monitoring loop has a running price

The X API is now pay-per-usage. The pricing page states it plainly: “No subscriptions—pay only for what you use” [2]. You buy credits up front in the Developer Console and they are “deducted as you make API requests” [2]. There is one published ceiling, and it is high: “Pay-per-usage plans are capped at 3 million Post reads per monthly billing cycle” [2]. At the published post rate that cap sits somewhere near $15,000 of reads a month, so for a small team it is not a budget control. The thing that actually stops spending is the credit balance you loaded.

Reads are billed per resource returned rather than per request; writes are billed per request [2]. Reading posts costs $0.005 per resource. Users, follows, followers and DM events cost $0.010. Lists, Spaces, Communities and Notes cost $0.005. Likes, mutes and blocks cost $0.001. Reading your own data qualifies for an owned-reads rate of $0.001 per resource, which the page describes as 1,000 resources for $1 [2]. One softening detail is worth knowing before you do the arithmetic: resources are “deduplicated within a 24-hour UTC day window”, so pulling the same post twice inside the same UTC day does not bill twice [2].

Writes are priced separately and deliberately higher. Creating a post costs $0.015 per request, a post containing a URL costs $0.200, a summoned post costs $0.010, and DM or user interactions cost $0.015 [2]. Read that price gap once and the design intent is obvious. Reading X in volume is cheap. Publishing links in volume is not meant to be.

Run the numbers on your actual loop rather than on a vague sense of scale. A search that returns 100 posts is 100 resources, and an agent set to check hourly is doing that 24 times a day.

The connector exposes the API underneath it, and that surface moves

An MCP server does not add capability. It re-presents an API in a form a model can call. Anything the X API cannot do, the X MCP server cannot do either, and anything the API changes, the server changes with it.

The clearest evidence is the server’s own short history. When it launched on 30 June 2026, X said the tool “is not compatible with X’s Write API endpoints”, which ruled out posting through it [8]. That is no longer the whole story. The current documentation lists bookmark management and Article drafting and publishing among the capabilities, and warns that “Writes count against rate limits (bookmarks, article_publish) and are stricter than reads; expect occasional 429s and back off” [1]. The durable lesson is not about bookmarks. It is that the launch coverage of any connector describes a surface that has since moved, and the docs page is the only thing worth quoting to yourself before you grant access.

Authentication comes in two shapes, and the choice is the main safety dial you have. You can paste an app Bearer token into an Authorization header on the MCP client, which the docs describe as “Read-only endpoints; no user context (can’t act as you)” [1]. Or you can run a local bridge that “handles the OAuth 2.0 PKCE login and auto-refreshes tokens, so the model acts with your account’s scopes”, which is “Required for writes (bookmarks, Articles) and any user-context tool” [1]. If your use case is monitoring and research, the first shape does the job and cannot post, bookmark or read your messages. Start there and stay there until something you actually need forces the upgrade.

Grant the smallest scope list that does the job

Once you take the user-context path, the approval screen is the decision. X’s OAuth 2.0 scopes are granular and individually named, which is good news if you read them. tweet.read covers “All the Tweets you can view, including Tweets from protected accounts” and users.read covers “Any account you can view, including protected accounts” [3]. Those two carry a monitoring workflow on their own. The rest of the list is where the exposure lives: dm.read covers “All the Direct Messages you can view, including Direct Messages from protected accounts”, dm.write sends and manages them, tweet.write posts and reposts for you, follows.write follows and unfollows for you, like.write likes and un-likes, and offline.access keeps the connection alive “until you revoke access” [3].

Anthropic’s guidance for custom connectors says the same thing in fewer words: review what permissions the server is requesting, “Limit these scopes when possible and deny access if requested permissions seem unnecessary” [6]. The same page is explicit about the trust question underneath it, advising users to “only connect Claude to servers built and hosted by organizations and applications you trust” [6]. Custom remote MCP connectors are available on the Free, Pro, Max, Team and Enterprise plans, with free users limited to one, and on Team or Enterprise an owner has to add the connector in organisation settings before members can use it [6].

ChatGPT draws the line in a different place, and it is worth knowing which side of it you are on. Full MCP support including write and modify actions is rolling out in beta to Business, Enterprise and Edu plans, while Pro users can connect MCP servers with read and fetch permissions only in developer mode [7]. If you are a Pro subscriber wondering why your connector will not post, that is why, and it is arguably the correct default.

Every post the server returns is text a stranger wrote

The vendor warnings you will read are mostly about the server. Anthropic notes that “Malicious MCP servers may include hidden instructions that try to make Claude perform unintended actions” [6]. OpenAI warns that “Connecting to unsafe or untrusted MCP servers may increase exposure to security risks (including prompt injection)” [7]. Both are correct and both are, in this case, the easy half of the problem. X’s server is run by X. The question of whether to trust the operator is not the interesting one.

The interesting one is the payload. A full-archive search returns posts written by anybody, and the whole point of the workflow is that you do not choose which ones. If you monitor a keyword, anyone who learns that keyword can write a post containing instructions and know it will be read into your agent’s context. That is not an exotic attack. It costs one post, it is targeted by definition, and it is the single input class where hostile text is free to produce at will. Anthropic’s own phrasing is careful about the defence: Claude “has built-in protections that attempt to block these attacks, but it’s important to pay attention to tool inputs & outputs” [6]. Attempt is the operative word, and it is doing honest work in that sentence.

The practical consequence is a rule about what sits downstream, not about the connector itself. Read-only scopes are the strongest version of this. If the token cannot post, cannot follow and cannot message, then the worst outcome of a poisoned search result is a wrong summary, which you will catch when you read it. Trouble arrives when the same session that reads X can also spend money, send email or publish, because then the untrusted text and the consequential action share a context.

X’s automation rules decide what an agent may do with the account

Before you design any workflow that acts rather than reads, read the automation rules, because they eliminate most of the ideas people arrive with. Automated liking is out: “You may not like posts or hide replies in an automated manner” [4]. Automated following is out: “You may not follow or unfollow X accounts in a bulk, aggressive, or indiscriminate manner” [4]. The obvious agent use case, replying to anyone who mentions a term, is out: “Sending automated replies to posts based on keyword searches alone is not permitted” [4]. Riding a trend is out: “You may not automatically post about trending topics on X, or use automation to attempt to influence or manipulate trending topics” [4]. Bulk adding users to lists or posts to collections is out as well [4].

What survives is narrower and, for most operators, more useful anyway. Automated posts drawing on outside information such as RSS feeds or weather data are permitted, as are automated posts for entertainment or informational purposes, provided they comply with the other rules [4]. Automated replies are permitted where someone has explicitly opted in by requesting contact or clearly indicating intent, with an easy opt-out and only one automated response per interaction [4].

So the honest shape of an X connector for a small business is a research tool with a human at the publishing end. It reads, it summarises, it drafts, and a person presses send. That is not a consolation prize. It is the only version that is both permitted and safe, and it removes the two failure modes that would otherwise cost you the account.

What still goes wrong

The price list is the least stable thing in this guide. X’s pricing page is explicit about it: “Prices are subject to change. Current rates are always available in the Developer Console” [2]. Every figure in this guide is a reading of that page on one day. Re-check the rates in the console before you build a loop around them, and treat any number you find elsewhere, including the ones here, as a snapshot rather than a quote.

Per-resource billing meets agent behaviour badly. An agent that retries a failed search is a meter running, and failures are expected rather than exceptional, since the documentation tells you to anticipate 429 responses and back off [1]. Deduplication only helps inside a 24-hour UTC window [2], so a loop that re-reads the same 500 posts every day pays for them every day. The published cap of 3 million Post reads per billing cycle [2] is not a safety net at this scale; a runaway loop will exhaust your credits long before it reaches it. The balance alert is the control.

Injection remains open. Anthropic says its protections attempt to block these attacks [6] and OpenAI names prompt injection as an exposure of untrusted servers [7], and neither claims the problem is closed. The specification is equally candid about how much of this it can enforce, stating that “MCP itself cannot enforce these security principles at the protocol level” and leaving them to implementors as SHOULDs [5]. Whatever protection you get comes from the client you happen to be using, not from the standard, and it can change under you between releases.

Last, none of this answers whether the data is worth reading. A connector makes X cheap to query and easy to summarise. It does not make a hundred posts about your category into a finding. If you cannot say in advance what decision the monitoring would change, the honest move is to leave the connector unconfigured and spend the ten minutes somewhere else.