Hosted X MCP Evaluation (#837)

Evaluated 2026-10-01 from X's developer documentation (MCP servers for the X API, pricing, rate limits), all live. The announcement post on X sits behind the login wall and was not read. No X developer app or credit exists for BoB, so nothing was registered or queried.

Verdict: reference-only until a consumer exists; opt-in per project when one does. The server is real and Claude Code can use it, but every read is paid, it needs an X developer app per operator, and its user-context route lets the model act as the operator's X account. The one planned consumer is the X-timeline scanning capability (#825), still proposed and not yet placed in a repository. That capability, when approved, wires the server into its own project. Nothing goes into BoB's global configuration and no follow-up requirement is filed.

What it is

Two hosted servers:

Server	URL	Purpose
X MCP	https://api.x.com/mcp (Streamable HTTP, protocol 2025-06-18)	X API v2 as tools: post lookup and engagement, full-archive post search, user and news search, a user's posts, timeline and mentions, bookmarks and bookmark folders, news and trends, Article drafts and publishing
Docs MCP	https://docs.x.com/mcp	Search and read the X developer docs; no X API access

Auth

There is no dynamic client registration and no MCP OAuth discovery, so every operator needs their own X developer app. Two routes:

Route	How	Can do
App-only Bearer	The client sends Authorization: Bearer <app token> straight to api.x.com/mcp	Public reads only; no user context
xurl mcp bridge	A local stdio bridge (npx -y @xdevplatform/xurl mcp https://api.x.com/mcp) runs the OAuth 2.0 PKCE login once, caches the token in ~/.xurl and refreshes it	Everything the app's scopes allow, as the operator's account: timeline, mentions, bookmarks, publishing Articles

The app must be in X's Pay-per-use package and Production environment; otherwise the bridge fails with client-not-enrolled. On a headless machine (farm-01) the first login runs out of band with xurl auth oauth2 --headless.

Price and limits

• Pricing is pay-per-use credits bought in advance, with spending limits, no subscription. Reads are charged per resource returned: $0.005 per post, $0.010 per user. Writes are charged per request.
• Rate limits are per endpoint, for example recent search 450 requests per 15 minutes (app) and full-archive search 1 per second, 300 per 15 minutes. Writes are stricter.
• No SLA is stated for the hosted server.

So a scan that reads 2,000 posts a day costs about $10 a day before any user lookups. That is the number #825 must budget against, and the reason this server must never be on by default: an agent searching freely runs up a bill.

Claude Code compatibility

Both routes fit Claude Code's MCP configuration:

# App-only, read-only
claude mcp add --transport http xapi https://api.x.com/mcp \
  --header "Authorization: Bearer ${X_BEARER_TOKEN}"

# User context through the bridge
claude mcp add xapi --env CLIENT_ID=… --env CLIENT_SECRET=… \
  -- npx -y @xdevplatform/xurl mcp https://api.x.com/mcp

In BoB the entry would live in that project's .mcp.json, with the token or client secret named in the operator's secrets (operator.json secrets[], the secrets inventory) and resolved from the environment, never written into the file. Neither form was run.

Data scope and privacy

• The model acts as the operator. Through the bridge it can read the operator's timeline, mentions and bookmarks, change bookmarks, and publish an Article. Use a dedicated app with only read scopes unless a write is the point, and keep publishing out of any unattended run.
• Tool output is untrusted input. Posts, bios and Articles are written by strangers and arrive in the agent's context; they can carry instructions. Any consumer treats them as data, as /watch and BoB's research skills already do.
• Tokens are secrets. ~/.xurl and the bearer token belong in the secrets inventory, not in a committed config or a session log.
• Third-party content. What X returns is subject to X's developer terms on storage and display; a consumer that keeps posts (a triage pile) must check them before storing at scale.

Default or opt-in

Opt-in, per project. It is paid per read, tied to one person's account, and useful to one planned workflow. It does not belong in BoB's global configuration or in any default provisioning kit.

Where this goes next

• #825 (scheduled X-timeline scanning), if approved, is the first consumer and owns the wiring: which repository it lives in, the app and its scopes, the daily credit budget, and storing what it reads. This evaluation is its reference.
• bodfeed's bookmark intake could use the bookmark tools in place of scraping, with the same opt-in and budget rules. Nothing is filed for it here.

Not verified

• The announcement post (login wall).
• The server's behaviour: no app, credit or token exists, so no registration or query was made.
• The exact tool names and count; the docs list capabilities by category.