In plain terms
Before MCP, every pairing of an AI app and a business system needed its own custom integration. MCP works like a universal plug: a system exposes its capabilities once, as an MCP server, and any MCP-capable assistant can use it.
Why it matters
It turns integrations from a per-vendor project into a reusable asset and reduces lock-in: the connector you build for your CRM works across assistants. It also concentrates risk. Every server you add is new capability and new attack surface, so you need a list of approved servers and their permissions.
Example
A company wraps its ticketing system in an MCP server offering “search tickets” and “add comment”. The same server then serves the support team's chat assistant, the developers' coding agent and an internal reporting agent, with no extra integration work.
Most often confused with
MCP vs. API
An API is how one service exposes its functions to programmers. MCP is a layer above: a uniform way to describe such functions so that a model can discover and call them. An MCP server usually wraps one or more APIs.
Origin: Introduced by Anthropic in November 2024; donated to the Agentic AI Foundation under the Linux Foundation in December 2025.
Under the hood
A client–server protocol built on JSON-RPC. Hosts (the AI application) run clients that connect to servers, locally over stdio or remotely over HTTP. Servers expose three main primitives: tools (functions the model can call), resources (data to read) and prompts (reusable templates); remote servers authenticate with OAuth. Security questions sit with the host: which servers to trust, what each may do, and whether combining servers assembles the lethal trifecta. Tool descriptions come from the server and enter the context, so a malicious server can attempt tool poisoning.