When Anthropic introduced MCP in November 2024, the announcement read like infrastructure plumbing: an open standard for connecting LLMs to external tools and data. JSON-RPC 2.0 over a few different transports. A client-server model with tools, resources, and prompts.
The protocol is unremarkable. That was always the point.
What’s happened in the eighteen months since launch is remarkable. Anthropic donated MCP to the Agentic AI Foundation — a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. By early 2026, every frontier model vendor had shipped MCP support. Microsoft published MCP servers for GitHub, Azure, Teams, and Microsoft 365. Google added MCP to the Gemini API and Vertex AI Agent Builder. OpenAI adopted MCP in Q2 2025. AWS built a managed MCP gateway into Bedrock AgentCore.
Adoption tracks the protocol: 78% of enterprise AI teams now report at least one MCP-backed agent running in production. At organizations with 250+ AI engineers, the number is 89%, and 64% of those teams run a custom internal MCP server. There are over 10,000 public MCP servers in the registry. The MCP SDKs went from 2 million monthly downloads at launch to 97 million by March 2026.
If you’ve shipped an agentic system in the last year, you almost certainly built on or around MCP. If you haven’t, you’ve probably built integrations that need to be replaced soon.
A 60-second primer on what it actually is
MCP defines three primitives that an LLM-driven host (Claude Desktop, Cursor, an agentic runtime) talks to through a thin client:
- Tools — functions the LLM can call, with structured inputs and outputs
- Resources — read-only context the LLM can fetch (files, query results, documentation)
- Prompts — parameterized templates a host can offer the user as canned interactions
The wire format is JSON-RPC 2.0. The transports are pluggable (stdio, HTTP, WebSocket, server-sent events). Authentication is increasingly OAuth-based as enterprise servers mature.
That’s it. The genius is in what it doesn’t try to do: it doesn’t standardize the agent itself, the orchestration framework, the prompt format, or the eval methodology. It only standardizes how an LLM-driven application discovers and calls capabilities. Everything else stays in your hands.
The job before MCP
Before MCP, an agentic engineer’s day was largely the N × M integration problem.
You had N LLM providers, each with their own way to expose tools: OpenAI’s function calling, Anthropic’s tool use, Bedrock’s action groups, Vertex’s function declarations. You had M tools you wanted to expose: your CRM, your warehouse, your internal docs, your ticketing system. Every (N, M) cell was a custom integration — written, tested, maintained, and rewritten every time a model vendor changed something.
If you wanted to swap models — say, you started on GPT-4 and decided Claude 4 Sonnet was better for your workflow — you rewrote every tool integration. If you wanted to add a new LLM-driven application that needed the same tools, you rewrote them again, in whatever shape that application’s framework expected.
The result was inevitable: the tool layer became the source of vendor lock-in. Not the model. The tool integrations.
What MCP changed
MCP collapses N × M into N + M. You write the tool-side once, as an MCP server. Every LLM-driven application that speaks MCP can call it — and every frontier vendor now does. The same internal MCP server that exposes your warehouse to Claude exposes it to GPT-5, to Gemini, to whatever agentic runtime you’re piloting next quarter.
The job changes shape accordingly.
Before MCP, the asset at the end of an agentic engagement was the agent code — fragile, framework-specific, often un-reusable. After MCP, the durable asset is the library of internal MCP servers that exposes the enterprise’s capabilities as a clean interface. The agent code becomes the cheap part, swappable as models and frameworks evolve. The MCP servers stay.
This is why the 64% statistic is the most consequential number in the MCP story. The mature enterprises haven’t just adopted MCP — they’ve built their own, internal-only MCP servers that wrap proprietary systems and expose them to any future agent. That library is the part of an agentic strategy that compounds.
The standardization story isn’t really about the protocol. It’s about what your engineering work leaves behind.
How we design
Our approach to any agentic engagement now leads with the MCP server design, not the agent design.
The first technical artifact we produce in an engagement is a capability map: what internal systems should be exposed as MCP tools, what data should be exposed as MCP resources, where the boundaries should be drawn, what authentication and authorization patterns each server should enforce. The capability map is where the architectural thinking lives. The agent built on top of it is the easier problem.
We default to Amazon Bedrock AgentCore for the runtime because it ships with a managed MCP gateway — meaning the wiring between agents and MCP servers is handled, with OAuth flows, rate limiting, and audit logging out of the box. We design custom internal MCP servers in TypeScript or Python depending on which proprietary system they’re wrapping. We use the public MCP server catalog where a community-maintained server fits the use case; we don’t reinvent what already exists.
The agent code itself — the orchestration logic, the prompt design, the eval suite — comes after the MCP layer is decided. This sequence is the opposite of how most projects start. It’s also why our engagements survive the next model-vendor rotation.
What happens if you skip it
There is still time, in early 2026, to ship an agentic system without MCP. Framework-specific tool integration works. You can wire OpenAI function calling directly to your warehouse, get a demo running this week, and call it done.
But the asset you produce is the asset you’ll throw away. When the next model is better, the next runtime is faster, or the next vendor changes their tool-calling API in a backward-incompatible way, you’ll redo the work. The 64% of enterprises that have built internal MCP servers won’t.
Where to start
If you’re early — pre-agent, pre-runtime decision — start by drawing the capability map. Which internal systems need to be exposed, at what boundaries, with what authentication. That map is the design artifact that survives every subsequent vendor and framework choice you’ll make.
If you’re mid-project on framework-specific tool integration, the answer is probably to refactor the tool layer into MCP servers before going further — not to scrap the agent code. The agent code is salvageable. The tool integration almost never is.
Our Agent Readiness Assessment opens with exactly this exercise: a two-week, fixed-scope read on where you are, what to keep, what to move to MCP, and what the production architecture should look like for the next twelve months.
→ Request a scoped proposal for an Agent Readiness Assessment