The X MCP Server - A Blueprint for the Connected Agent Era

X just gave every AI agent a live feed of the internet’s arguments. Here’s how to wire it up, what I’d build with it, and the security question I wish more people were asking.

X MCP Server

On June 30, X launched a hosted Model Context Protocol server, and the announcement has been sitting near the top of Hacker News ever since. In one line, any MCP compatible AI tool, meaning Claude, Cursor, Grok, VS Code and a growing list of agent frameworks, can now talk to the X API directly, using your own account’s permissions, with no infrastructure on your side.

I’ve spent the past few days connecting it to my own setup, and I think this launch matters well beyond X. It’s the clearest picture yet of how every platform will expose itself to agents. It also carries a risk that the launch coverage has mostly glossed over. Both halves below.

What MCP is and why hosted changes things

The Model Context Protocol is an open standard Anthropic introduced in late 2024. Think of it as a universal adapter between AI models and external services, instead of writing custom integration code for every tool and every platform, a developer writes to one spec, and any MCP client can discover and call any MCP server.

The ecosystem crossed 97 million monthly SDK downloads earlier this year, and GitHub, Slack, Notion, Stripe and Salesforce all run official servers.

Until last week, getting an AI assistant to read X meant building your own bridge. You stood up a server, wired it to the X API, handled OAuth, managed token refresh, and maintained the whole thing. Community built servers existed, but nobody stood behind them. Now X hosts the bridge itself at api.x.com/mcp, and there’s a second server dedicated to X’s developer documentation, so a coding agent can look up API references while it works. Billing for the underlying API access is pay per use rather than a subscription, which lowers the barrier for individual builders considerably.

What you get, and what X deliberately left out

The hosted server exposes more than 200 endpoints from the X API. The useful core, full archive post search, user timelines, profile lookups, conversation threads, trends, and bookmark management. If your agent needs to know what people are saying about something right now, this is the richest firehose with an official MCP front door.

Just as interesting is what’s excluded, X confirmed to TechCrunch that the hosted MCP does not expose the write endpoints, so agents cannot post through it, and streaming and webhook endpoints are left out too. Separately, X has been raising raw API prices on the write side, to one and a half cents per published post and twenty cents per posted link, explicitly to make spam expensive. and i believe this is a right step in securing a platform for humans.

Setting it up in Claude and Cursor

The whole setup took me under ten minutes. Three steps.

First, enable OAuth in the X developer portal for your account, which is where you choose the scopes your agent will hold. Be stingy. If your use case is search and reading, grant exactly that and nothing else.

Second, install xurl, the open source bridge X ships for this. It handles the OAuth dance and injects a fresh bearer token on every call, so no long lived credential ever sits in a config file. That design choice alone puts it ahead of half the MCP servers I’ve used.

Third, register the server in your client. In Claude or Cursor, that’s a small addition to the MCP configuration:

{
  "mcpServers": {
    "x": {
      "url": "https://api.x.com/mcp"
    }
  }
}

Restart the client, authenticate in the browser window that appears, and the X tools show up in your agent’s tool list. For the documentation server, add a second entry pointing at docs.x.com/mcp.

Full setup guides live at docs.x.com/tools/mcp.

A good first test that shows the value immediately, paste a link to any long thread and ask your assistant to pull the full conversation, summarize the actual disagreement, and list the three most substantive replies. Watching an agent do in eight seconds what used to be twenty minutes of scrolling is the moment this clicks.

The part that worries me

Here’s the question I wish the launch threads spent more time on. When your agent pulls posts from X, every one of those posts is untrusted text from a stranger, sitting in the same context window as your instructions. Prompt injection through social content is not hypothetical. A hostile post can contain text crafted to steer any agent that reads it, and if that agent also holds other tools, your calendar, your files, another API with write access somewhere, the attacker is no longer just influencing a summary.

X’s read only design limits what an attacker can do through X itself, which is exactly why I praised it. It does nothing about what an attacker can do through the other tools connected to the same agent. So my rules, which I’d suggest as a baseline for anyone wiring this up: give the X connection the minimum scopes it needs, never combine untrusted content feeds with sensitive write tools in one agent session, treat fetched posts as data to be analyzed rather than instructions to be followed, and log every tool call so you can audit what actually happened. None of this is X’s fault. It’s the tax on the connected agent era, and we should start paying it consciously.

Where this goes

My prediction is that within a year an official MCP server will be table stakes for any platform with an API, the way a REST API became table stakes fifteen years ago. X moving early, with sensible read only scoping and genuinely smooth developer experience, sets the reference implementation others will copy.

The agents were always going to get eyes on the real time internet. The interesting choices are about what else we let them hold while they’re looking.

Have you connected it yet, and if so, what’s the first workflow you automated? Tell me in the responses, I’m collecting use cases for a follow up piece.