Every major AI coding environment shipped MCP v2.1 in the same two-week window. Claude Code's redesign, Cursor's native support, Microsoft Agent Framework 1.0, OpenAI Codex — they all picked the same connective tissue. A breakdown of what changed, why the architecture makes sense, and where the ecosystem is still fragile.
Every major AI coding environment shipped MCP v2.1 support in the same two-week window. That's not a coincidence — it's the ecosystem sending a memo.
Cursor added it. Anthropic's new Claude Code UI launched with it baked in as the connective tissue. Microsoft's Agent Framework 1.0 shipped with "full MCP support built in" in the headline. OpenAI Codex followed. If you're still treating the Model Context Protocol as an optional integration layer or something you'll get to eventually, you're already behind the curve on how production agentic systems are being built.
What Actually Just Happened
The Claude Code redesign that dropped on April 14 is the clearest signal yet of where this is all going. It's not just a new UI — it's a full application layer on top of the CLI, organized around parallel sessions, project-scoped toolchains, and something Anthropic is calling Routines: a cloud automation system that orchestrates multi-step agent workflows triggered by schedules, events, or other agents.
The important architectural detail: every piece of this uses MCP as its integration layer. Your custom database connector? MCP server. The Jira integration? MCP. The Slack notifier your Routine fires when a build completes? MCP. The protocol that Anthropic open-sourced in late 2024 and donated to the Linux Foundation has gone from "interesting experiment" to "load-bearing infrastructure of the agentic stack" in roughly 18 months.
And now that Cursor also ships native MCP v2.1 support, developers who run both tools in their workflow — and a lot of senior engineers do, the $40/month Cursor + Claude Code combo is basically the new brew install — get to share the same MCP server configs across their entire environment. Write the server once, use it everywhere.
That's the moment when a protocol stops being a standard and starts being a platform.
Why This Architecture Actually Makes Sense
MCP's design is worth understanding if you're going to build on top of it rather than just consume it. At its core, it's a JSON-RPC client-server architecture where the AI model is the client and your tools/data sources are the servers. The LLM discovers what tools are available, calls them, gets results back, and continues reasoning. No custom glue code per-tool, no bespoke function schemas written for each model provider.
Compare this to what most teams were doing in 2024: writing tool definitions for OpenAI's function calling format, then rewriting them for Claude's format, then rewriting them again for Gemini. MCP eliminates that entire class of toil.
Here's a minimal MCP server in Python that exposes a Postgres query tool — the kind of thing you'd previously have had to implement four different ways:
from mcp.server.fastmcp import FastMCP
import asyncpg
mcp = FastMCP("postgres-reader")
@mcp.tool()
async def query_db(sql: str) -> str:
"""Run a read-only SQL query against the production database."""
conn = await asyncpg.connect(DATABASE_URL)
try:
rows = await conn.fetch(sql)
return "\n".join(str(dict(row)) for row in rows)
finally:
await conn.close()
if __name__ == "__main__":
mcp.run()
You add this to your claude_desktop_config.json once:
{
"mcpServers": {
"postgres": {
"command": "python",
"args": ["postgres_server.py"],
"env": { "DATABASE_URL": "postgresql://..." }
}
}
}
And now every Claude session, every Cursor chat, every Routine has access to your database with full context about the schema. No copy-pasting connection strings into prompts. No "here's the table structure" boilerplate at the top of every conversation.
This is what the tooling actually looks like when it's set up well. It's not glamorous, but it makes AI-assisted development feel genuinely different rather than like a fancier autocomplete.
The A2A Layer: What Happens When Your Agents Need To Talk To Each Other
MCP handles tool access — how an agent connects to the outside world. But April 9, 2026 was the one-year anniversary of the Agent-to-Agent Protocol (A2A), and the fact that both MCP and A2A are now under the Linux Foundation's Agentic AI Foundation co-founded by Anthropic, Google, Microsoft, OpenAI, AWS, and Block tells you where this is heading.
A2A is HTTP for agent-to-agent communication: a standardized way for one AI agent to discover, invoke, and coordinate with another, regardless of what framework or model is underneath. MCP is how your agent talks to tools. A2A is how your agents talk to each other.
The practical implication: if you're building anything more complex than a single-agent workflow — a pipeline where a research agent hands off to a summarizer, or a coding agent that delegates testing to a specialized verification agent — you should be thinking about A2A as the communication layer from the start rather than bolting it on later.
The architecture that's emerging looks like this:
User request
↓
Orchestrator Agent (Claude Code Routine / your main agent)
├──[MCP]──→ Database server
├──[MCP]──→ File system server
├──[MCP]──→ GitHub server
└──[A2A]──→ Specialist Agent (e.g. security reviewer)
└──[MCP]──→ Vulnerability scanner
The orchestrator handles context and routing. The specialist agents bring deep capability in their domain. Everything talks via open protocols. No vendor lock-in at the communication layer.
The Honest Take On Where This Is Fragile
I should be direct: MCP ecosystem quality is still wildly inconsistent. There are several hundred community MCP servers on GitHub and maybe 20 of them are production-ready. The rest are weekend hacks with no error handling, no rate limiting, and schemas that will confuse any model into making useless tool calls.
The FastMCP Python SDK makes writing servers easy enough that more bad servers will be written alongside the good ones. This is the npm problem — an explosion of packages, most of which you shouldn't use.
The discipline that actually matters right now isn't whether you use MCP (you should), it's being ruthless about which servers you run. Every MCP server you attach to an agent session is a surface area for prompt injection, for tool call hallucinations, and for capability that your agent will attempt to use when it shouldn't. Keep your MCP surface small and well-understood.
Also: the A2A spec is still v0.2. The "stable" framing from the Linux Foundation is aspirational. Build against it, but expect the interface to change under you at least once more before the ecosystem fully stabilizes.
What You Should Actually Do This Week
If you're running any agentic workflow in production or building one:
Write an MCP server for your most-accessed data source. Whatever you're copy-pasting into prompts the most — database schemas, API docs, issue tracker state — turn it into an MCP server. The friction of writing the server once is much lower than the compounding cost of context-stuffing it into every session.
Read the A2A spec. It's short. Even if you're not building multi-agent systems yet, understanding the mental model will shape how you architect your agents so you're not doing a full refactor when you need to scale out.
Stay skeptical of the community MCP server directory. Test every third-party server you adopt in an isolated session before you add it to your main workflow. Look at the schema definitions. Ask: what happens if this tool returns garbage? Does my agent handle that gracefully?
The protocol consolidation happening right now is genuinely good for the ecosystem. One standard for tool access, one for agent communication, both governed by a foundation with enough stakeholder buy-in to outlast any individual company's product strategy. After years of fragmentation, that's not nothing.
Build on the standard. Be honest about where the standard is still rough. Ship something useful anyway.
> EOF