Your teammate opens Claude Desktop on Monday morning, asks it to summarize what practitioners are saying about a competitor's launch, and Claude just does it - pulling live posts from X, threading the signal, dropping the summary into a doc. No API key wrangled the night before. No custom server someone stood up six months ago and forgot to update. It works because X shipped a hosted MCP server on June 30, and the integration overhead that used to sit between "X has an API" and "my AI agent can actually use it" is gone.
That is a small moment. But it points at something real about where the MCP ecosystem is right now.
What a hosted MCP server actually changes
On June 30, X unveiled a hosted Model Context Protocol server that lets AI tools like Claude, Cursor, and Grok Build communicate with the X API using a user's own account permissions. The practical shift is straightforward: previously, if developers wanted an AI assistant to access X, they had to build their own MCP server, host it, connect to the X API, and handle the authentication. Now X hosts the MCP, and users authenticate with their own account's permissions - which means developers can focus on what they are actually building.
The move sees X joining a growing number of companies that now offer their own official MCP servers or endpoints, like GitHub, Slack, Notion, Stripe, and Salesforce. That list is the real story. Platform after platform is shipping official MCP servers, turning what was a developer side project into supported infrastructure.
This matters because the self-hosted MCP server ecosystem, for all its energy, has a quality problem. The Glama directory lists 22,775 MCP servers as of May 2026. Most are weekend projects.
BlueRock Security's 2026 analysis of roughly 7,000 public servers found 36.7% are SSRF-vulnerable, 41% require no authentication at all, 53% of authenticated servers rely on static API keys, and only 8.5% use OAuth. When a platform ships its own hosted server with OAuth against its own identity system, it skips the entire bottom half of that distribution.
The write-access question every team should ask first
X made a deliberate call that is worth copying: there was concern that by removing an infrastructure hurdle, X would open itself up to more automated posting or spam. X clarified to TechCrunch that the MCP tool is not compatible with X's Write API endpoints, so it is not possible to use it to post autonomously on X.
X is actually rolling out two MCP servers: one for core API access and another that provides AI tools with direct access to X's developer documentation, letting AI tools reference API specs and integration guides programmatically during development workflows.
Read-only by design is the right default, and not every official server makes that choice. The Microsoft Teams MCP server lets AI agents read and act across Teams chats and channels. Microsoft's official server - the Work IQ Teams MCP server, part of Microsoft Agent 365 and currently in preview - is read/write with full CRUD and no read-only mode; you constrain it by scoping Entra permissions, not by a flag. That is fine if you know what you are doing, and a significant exposure if you do not.
The pattern to apply across any MCP server, official or otherwise: ask what the blast radius is if the agent misbehaves or gets manipulated. Simon Willison's "lethal trifecta" is the single most useful mental model for reasoning about MCP risk. You get data exfiltration when an agent simultaneously has access to private data, exposure to untrusted content, and a way to communicate externally. Any one or two of these is fine. All three together is an exfiltration primitive. A social platform server that only reads and cannot post breaks the third leg of that tripod, which is why X's constraint is a sensible design, not just a business decision.
What "supported infrastructure" means for teams building on MCP today
The broader MCP spec is also in flux. The largest revision of the protocol since launch delivers on the 2026 roadmap: a stateless core that scales on ordinary HTTP infrastructure, extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension, and authorization that aligns more closely with OAuth and OpenID Connect deployments.
The release candidate is available now, and the final specification ships on July 28, 2026.
The stateless change is not abstract. A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server's ttlMs permits. For teams running their own internal MCP servers - connecting agents to internal wikis, ticketing systems, or data stores - this means the infrastructure overhead drops considerably after July 28.
Put it together and the picture for a team evaluating their MCP stack right now is this:
- Official hosted servers from major platforms (GitHub, Slack, Notion, Stripe, Salesforce, now X) are the safest starting point. They come with real auth, real maintenance, and a vendor accountable for security issues.
- The read/write distinction is the first thing to check. If a server can act on your behalf - post, write, delete - you need to know what gates exist before an agent can do that autonomously.
- The incoming July 28 spec makes running your own internal MCP servers significantly less painful. If you have been putting that off because of sticky-session complexity, the window to revisit is now.
A teammate like Beagle, which lives inside Slack, sees this pattern clearly: the integrations people actually use in agents are the ones with a maintained server, clear OAuth, and a readable scope. The rest sit in the config file and accumulate dust - or worse, accumulate permissions nobody audited.
MCP is becoming the address book of the internet for AI agents. Presence in the index is the new SEO. That framing is useful for platforms deciding whether to ship a hosted server. For teams on the other side of that decision, the question is simpler: which servers in your agent's tool list do you actually trust, and do you know what they can do?