MCP (Model Context Protocol)

The Technical Definition

MCP (Model Context Protocol) is an open standard, published by Anthropic in late 2024, for connecting language models to external data sources and tools. It defines a common wire format: how a model client (Claude, Cursor, your internal agent) talks to a server that exposes tools, resources, and prompts. The server might wrap your CRM, your file system, your database, your design tool — anything you want a model to be able to read or act on. Once a server speaks MCP, any MCP-aware client can connect to it without custom integration work.

The naming is deliberately boring. The point of a protocol is that nobody has to think about it. USB didn’t change what computers do; it changed how peripherals connected to them. MCP is the same idea applied to the agent layer.

What This Actually Means for Your Business

The reason this matters for a CEO is concentrated in one word: lock-in.

Through 2024, every AI vendor pitched you an agent platform with proprietary integrations. They built connectors to Salesforce, to Workday, to your data warehouse. The connectors were valuable, the connectors were exclusive, and the moat was the integration library. Switching vendors meant rebuilding all of it.

MCP changes that math. By the end of 2025, most of the serious agent infrastructure — Anthropic, OpenAI (which adopted it in March 2025), the major IDE vendors, internal platforms at firms like Block and Shopify — speaks MCP. SAP, Atlassian, Stripe, GitHub, Notion, and dozens of other systems publish official MCP servers. The tools you connect to your AI today increasingly travel with you when you switch the model or platform underneath them.

This isn’t a clean break from lock-in. The orchestration layer (which agent runs which workflow), the prompts, the evaluation infrastructure, the data and policies — all of that is still custom. But the connectivity layer is being commoditized. That’s the layer that ate the most engineering time in 2023-2024 builds, and it’s the layer where the vendor leverage was greatest.

The practical implication: when a vendor pitches you their AI agent platform, the question “do you support MCP, and which servers do you use?” tells you a lot. Vendors who built before MCP and have proprietary connector libraries usually downplay it — their moat depends on you not having alternatives. Vendors building today usually embrace it, because building on a standard is faster than building proprietary integrations from scratch.

There’s also an internal angle. If your IT team is building agents on internal systems, exposing those systems via MCP servers means any future agent (yours, a vendor’s, an internal experiment) can use them without rewriting the integration. That’s not a small benefit. It’s the difference between integration as a recurring tax and integration as a one-time investment.

Reality Check

What the vendor says: “Our platform fully supports MCP and integrates with everything in your stack.”

What that means in practice: They might mean the platform can act as an MCP client (consume MCP servers built by others). They might mean it exposes its own data via an MCP server (so other tools can connect to it). They might mean both. They might mean a marketing-grade subset of either. Ask which direction the support runs and which specific servers they’ve tested in production.

What Operators Actually Do

Teams that are getting ahead of this are doing two things. First: building or adopting MCP servers for their critical internal systems — the CRM, the data warehouse, the document store, the ticketing system — so any future agent project can plug in without custom integration work. The investment is small relative to the optionality it creates.

Second: insisting on MCP compatibility as a procurement criterion for new AI tools. Not as the only criterion, but as a tiebreaker. Two vendors with similar capabilities, one MCP-native and one with a proprietary connector library, are not equivalent over a five-year horizon. The MCP-native one is cheaper to integrate, easier to replace, and less likely to leave you stranded if it gets acquired or shuts down.

The other pattern: sandboxing. MCP servers can expose powerful capabilities to a model. Operators that take the protocol seriously also take its security seriously — running servers with explicit permission boundaries, logging every call, and treating any new server as a third-party dependency that goes through the same review as any other vendor.

The Questions to Ask

1. Are you an MCP client, an MCP server, or both? Every vendor answer is different. The shape of their support determines how portable your investment is.

2. Which official MCP servers have you tested in production, and which did you build yourselves? Official servers maintained by the underlying system (Notion, GitHub, Atlassian) are durable. Vendor-built servers wrapping someone else’s API can rot when that API changes.

3. If we wanted to swap out the model behind your agent next year, what would break? MCP-native architectures should make that swap relatively cheap. If the answer involves rewriting integrations, you’re paying for lock-in dressed as compatibility.