MCP is a protocol for connecting AI models to the things they need: tools they can call, data they can read, and prompts they can reuse. Anthropic published it as an open standard, and the reason it caught on is unglamorous. Before MCP, every AI application wrote its own bespoke integration for every system it touched, and none of that work transferred. Fifteen apps that each needed access to the same six systems meant ninety integrations, each maintained separately, each subtly different.
The architecture is a client-server split. An MCP server wraps some capability (your Postgres database, a GitHub repo, a filesystem, an internal API) and advertises what it offers over the protocol. An MCP client lives inside the AI application and speaks to any server that follows the spec. The model asks what's available, gets back a machine-readable description of tools and their parameters, and calls them. Neither side needs to know anything specific about the other in advance, which is the whole point.
Servers expose three kinds of thing. Tools are functions the model can invoke with side effects: query this, create that, send this. Resources are data the model can read, addressed by URI, like a file or a record. Prompts are reusable templates a server can offer for common tasks against it. Most of the value in practice is in tools and resources; prompts are the least-used third.
The obvious question is why this isn't just an API, and the answer is discovery and audience. A REST API is a contract between two systems whose developers agreed on it in advance, documented in prose that a human reads before writing the client. MCP is designed so that the consumer is a model at runtime: it enumerates the available tools, reads their schemas, and figures out which to call for the task at hand, without anyone having written integration code for that specific combination. MCP servers usually wrap APIs. It's a layer on top, not a replacement.
What makes it strategically interesting is the network effect. Write one MCP server for your product and every MCP-compatible AI client can use it. Build one MCP client and your app inherits every server anyone has published. That flips integration from quadratic to linear, which is the same argument LSP made for editors and language tooling, and it worked there for the same reason.
The security story deserves more attention than it usually gets. An MCP server is arbitrary code you're granting a model the ability to invoke, and tool descriptions are text that ends up in the model's context, which makes them an injection surface. Running a server someone else wrote against your production database is a real trust decision, not a convenience one. The maturing practice is to treat servers like dependencies: pin them, review them, scope their credentials narrowly, and log every call.
Why It Matters
Integration cost has been the main thing keeping AI systems from being useful inside real companies, where the relevant data always lives in eight systems that don't talk to each other. MCP turns that from custom engineering into a standard, which is why it went from a spec to broad adoption unusually fast. For product teams, shipping an MCP server is now a distribution decision: it's how your product becomes reachable from the AI tools your customers already use, without you building an integration for each one.
Example
An engineering team wants their coding assistant to see Jira tickets, query the staging database, and read internal architecture docs. Without MCP, that's three custom integrations against whatever plugin system their assistant happens to have, thrown away if they switch tools. With MCP, they run three servers (one per system, two of them off the shelf), point the assistant at them, and the same servers work when a teammate uses a different MCP-compatible client. The assistant discovers at runtime that it can call search_tickets and query_staging, and picks the right one when someone asks why the checkout flow regressed.