An open standard for connecting AI applications to the tools and data they need — and why it quietly won the integration war.
TL;DR
- MCP standardizes the messy middle. Instead of writing bespoke glue for every model-to-tool connection, you write one MCP server and any MCP-capable client can use it.
- It is client/server, not a framework. Hosts run clients; servers expose tools, resources, and prompts over JSON-RPC.
- Adoption is what made it matter. Once multiple major vendors and IDEs spoke the same protocol, building an integration once meant it worked everywhere.
- For developers, the unit of reuse shifts from "an integration for my app" to "a server the whole ecosystem can call."
The N×M problem MCP solves
Before MCP, wiring a model up to your tools was an N×M problem. Every AI application (N) needed a custom adapter for every tool or data source (M) — your database, your ticketing system, your file store, your internal API. Each pairing was hand-rolled, subtly different, and brittle. Switch models or add a tool and you were back writing glue.
The Model Context Protocol, introduced by Anthropic in late 2024, collapses that grid into N+M. A tool is exposed once as an MCP server. Any MCP-capable client can connect to it. The common analogy — "USB-C for AI" — is apt: a single port specification that turns a combinatorial mess into plug-and-play.
The win isn't a smarter model. It's a shared socket that lets integrations be written once and reused everywhere.
What MCP actually is
MCP is a protocol, not a library or a framework. It defines how an AI application and an external capability provider talk to each other over JSON-RPC. Three roles matter:
- Host — the AI application the user interacts with (an IDE assistant, a desktop chat app, an agent runtime).
- Client — the connector inside the host that maintains a session with one server.
- Server — the process that exposes capabilities. A server can run locally over stdio or remotely over HTTP.
A server offers three primitive types:
- Tools — functions the model can call (query a database, open a PR, send a message).
- Resources — read-only data the host can pull in as context (files, records, documentation).
- Prompts — reusable, parameterized templates a server can hand to the host.
That small surface area is the point. Because the contract is narrow and standardized, a server author and a host author never have to coordinate directly.
A minimal server
The shape of a server is deliberately boring — declare a tool, describe its inputs, return a result:
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { z } from 'zod'
const server = new McpServer({ name: 'weather', version: '1.0.0' })
server.tool(
'get_forecast',
{ city: z.string().describe('City name to fetch the forecast for') },
async ({ city }) => {
const forecast = await fetchForecast(city)
return { content: [{ type: 'text', text: forecast }] }
},
)
Any MCP host can now discover get_forecast, see its schema, and let a model call it — with no knowledge of your code beyond the protocol.
Why adoption is the real story
Standards don't win on elegance; they win on reach. MCP's inflection point wasn't a spec revision — it was cross-vendor uptake. Once it stopped being one company's protocol and became something multiple model providers, IDEs, and agent platforms all spoke, the incentive flipped. Publishing an MCP server meant your tool worked across the whole ecosystem instead of one app, and the catalogue of available servers grew fast enough that "is there an MCP server for X?" became a normal first question.
That is the flywheel every standard needs: more clients make servers more valuable, and more servers make clients more valuable.
What it means if you build agents
The practical shifts are concrete:
- Build integrations once. Wrap your internal systems as MCP servers and stop maintaining per-app connectors.
- Treat servers as the reuse boundary. The thing you share across teams (and the community) is a server, not a tangle of app-specific code.
- Mind the security surface. A server hands a model real capabilities. Scope tools tightly, validate inputs, sandbox execution, and never expose a server you wouldn't hand the keys to — prompt-injected agents will call whatever you offer.
- Design tools for models, not humans. Clear names, tight schemas, and descriptions that explain when to use a tool make the difference between an agent that uses it correctly and one that flails.
The takeaway
MCP didn't win because it was clever. It won because it was shared. The Model Context Protocol turned a thousand bespoke integrations into a common socket, and in doing so made "connect a model to the real world" a solved, reusable problem rather than a per-project slog. If you are building agentic systems, the question is no longer whether to speak MCP — it's which of your systems to expose as a server first.