Lexicon · III · Orchestration
MCP
Also: Model Context Protocol
An open standard acting as a universal socket between models and your systems: instead of one custom integration per tool and per product, one common socket everyone knows how to plug into.
The analogy
The standardized power socket. Before the standard, every appliance had its own connector and every building its own wiring; plugging anything in required an electrician. The standard made every appliance compatible with every socket. MCP plays that role between information systems and models: one standard way to present your tools and data.
Multiplication versus addition
Add AI tools and systems, then compare: custom integrations, or the MCP socket.
Pick an approach, then grow the fleet:
3 tools × 3 systems = 9 integrations to write and maintain.
Every cable gets coded, documented, maintained, and breaks on the next update.
An API exposes itself to developers, project by project. MCP exposes itself to models, once and for all.
The problem the socket solves
Three AI tools, three internal systems: nine integrations to write if each one is custom-built. Every new tool adds a row of cables, every new system a column; the fleet grows by multiplication, and so does the maintenance, because every cable breaks at the next update on either end. MCP turns that multiplication into an addition: each system exposes itself once, each tool plugs in once, and the two sides grow without multiplying each other.
A concrete example
Your team exposes the product database through an MCP server. As a result, Claude, the support assistant and the internal agents all plug into it with no bespoke development, and so will the next compatible tool. Before MCP, those three connections would have been three custom integrations, each maintained separately for years.
Why it is not "just an API"
An API waits for a developer to read its documentation, write calling code, test it and maintain it. An MCP server describes itself to the model that plugs in: here are my tools (to act), my resources (to read), my request templates. The model discovers those capabilities on connection and uses them on its own; nobody writes calling code. That dynamic discovery is what changes the nature of the object: you do not program the usage, you equip the model. Your existing APIs stay underneath; MCP is the layer that makes them readable by models.
What it is NOT
It is not a product to buy: it is an open standard, initiated by Anthropic in late 2024, since adopted by OpenAI, Google and Microsoft, and handed over in late 2025 to an independent foundation under the Linux Foundation. It is not magic: the socket does not decide what may be plugged in; permissions, security and logging remain your decisions. And it is not a prerequisite to get started: it is an accelerator once integrations multiply.
Often confused with
The distinction that changes the conversation.
- API
- Your existing API talks to developers: every assistant that wants to use it requires custom code. An MCP server exposes it once, in a format all compatible models understand. MCP does not replace your APIs: it makes them pluggable into models.