X's official MCP server is a real, supported way to connect an agent to the X API, and for a lot of jobs it is the right pick. It is also easy to walk into with the wrong expectations. Here are five things worth knowing before you register anything, so the setup matches what your agent actually needs.
This is the short version. For the full official-vs-session breakdown, see Connect an AI Agent to X: MCP vs Session.
1. Even read-only needs a developer app
"Without any setup" is the marketing line, but there is always an app behind it. Even the read-only app-only bearer token requires a registered X developer app (docs.x.com/tools/mcp). If your agent just needs to read posts or search, you still register, enable auth, and manage credentials before the first call.
2. It is pay-per-use, not free
The MCP layer adds no charge, but it inherits X API pricing. Every tool call bills against your plan or pay-per-use credits (docs.x.com/tools/mcp). A chatty agent that polls X on a loop is spending real money on each call, which surprises people who assumed the MCP itself was the product.
Browser reads against your own session sidestep that per-call meter, since you are reading pages the way your own browser does rather than billing an API endpoint. For read-heavy work, that cost difference adds up fast.
3. Writes are rate-limited harder than reads
Write actions (post, bookmark, publish an Article) hit stricter rate limits than reads, so a busy agent will see 429 errors and need retry-with-backoff. This is a real constraint to design around, not a bug.
Worth being straight here: session reuse does not fix this. The rate limits live at the X API, so any approach that writes to X hits the same 429s. If your agent writes at volume, plan for backoff no matter which path you choose, and lean toward the official OAuth app for the audited, scoped connector.
4. Setup is five things that must line up
The OAuth flow itself is fine. The friction is that five separate pieces all have to be correct before a single call fires: a developer app, OAuth 2.0 enabled, a client ID and secret, a registered redirect URI (the default is http://localhost:8080/callback), and the running bridge. Miss the redirect URI and the callback fails. Skip an enrollment step and the API rejects you until you fix it in the portal.
None of it is hard alone. Together it is an afternoon. Session reuse removes this whole layer for reads, since there is no app, secret, or redirect URI to line up.
5. Your own bookmarks need full OAuth
An app-only bearer token is read-only with no user context, which sounds fine until you realize your own bookmarks and timeline are user-scoped. Reading your data rather than only public data requires the full OAuth 2.0 flow through the bridge. So the one-header shortcut does not cover the personal-read case many agents actually want.
A logged-in session handles this naturally, because it already is your logged-in context. Reading your own bookmarks through a session you authenticated is the same as opening them in your browser.
The honest summary
None of these make X's official MCP a bad choice. For writes, multi-user apps, and anything that needs an official audited connector, it is the right tool. The five points are about matching the setup to the job. If your agent mostly reads, mostly runs for one user, and you would rather skip the app-and-billing layer, a session-based read path fits better.