What Is Model Context Protocol? A Plain-English Guide for Engineering Leaders

MCP Is a Standard Interface

The MCP Dev Summit North America drew roughly 1,200 attendees to New York in April 2026. That number matters because MCP started as a single vendor's protocol. Anthropic introduced it on November 25, 2024. In December 2025, Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI. A 1,200-person summit signals that engineering leaders across the industry have placed MCP on their evaluation roadmap, whether or not they have shipped a single server yet.

So what is model context protocol, in plain terms? Model Context Protocol is a JSON-RPC-based open standard that defines how MCP clients discover and invoke tools, resources, and prompts exposed by MCP servers. It does not reason, plan, or replace your model. Per the modelcontextprotocol.io specification (2025-06-18), MCP servers speak JSON-RPC over HTTP or stdin/stdout and respond to standardized methods including tools/list and tools/call, which allow clients to auto-discover and invoke capabilities without hardcoded integration logic. The reasoning, planning, and multi-step orchestration live elsewhere, in agent frameworks like LangChain, LangGraph, LlamaIndex, and CrewAI.

That boundary matters.

Confusing MCP with an agent framework is the fastest way to architect a system that performs poorly and costs more to maintain than the proprietary connectors it was supposed to replace.

‍

The Three Things an MCP Server Exposes

According to the MCP specification, every server exposes some combination of three capability types. Tools are actions: things the model can call to write a file, query a database, or trigger an API. Resources are data: files, text, structured content the client can read. Prompts are templates: reusable instruction patterns the server surfaces to the client. That three-part taxonomy is the whole surface area. MCP does not expose authentication logic, orchestration state, or business rules. Those belong to your application layer.

Claude Desktop can act as an MCP client, connecting to a local filesystem MCP server that exposes read/write tools through tools/list. Claude does not contain any filesystem logic. The server translates JSON-RPC calls into actual OS file operations. Swap Claude for Cursor or Windsurf and the same server still works without modification. That portability is the contract MCP defines: one server, multiple clients, zero renegotiation of the interface.

IBM's analysis of the MCP ecosystem confirms the architectural role. MCP normalizes tool access while agent frameworks handle reasoning. The two layers are complementary. Teams evaluating MCP server development as a standards-based approach need to scope it precisely, as a tool-access layer, before they can evaluate whether it belongs in their stack.

A sophisticated reader will push back here: if MCP is a transport spec, why should an executive care? Engineering will handle the wire format.

The wire format itself is a developer concern. The decision between MCP and a proprietary tool-call API is a portfolio-level investment choice with a three-to-five-year budget tail. Proprietary tool APIs lock every integration to a single model vendor. When you evaluate a second model, you rebuild connectors. When a third-party vendor deprecates their API, you rebuild again. MCP changes that economics: one server, built once to the standard, remains reusable across any MCP-capable client. The standardization decision determines vendor lock-in, integration reusability, and the engineering budget you free up or burn through over the next three years. That is a capital allocation question dressed in protocol clothing.

Anthropic open-sourced MCP in November 2024. By March 2025, OpenAI had officially adopted the protocol across its products, including the ChatGPT desktop application. Google DeepMind followed. The Anthropic ecosystem alone had grown to more than 10,000 MCP server builders by mid-2025. When three of the dominant model providers align on a single integration schema, the calculus on proprietary connectors changes materially. The question for engineering leaders in 2026 is whether your integration strategy was built before or after that alignment happened.

‍

The N×M Integration Problem

Once you understand MCP is a contract between clients and servers, the next question is why that contract was worth standardizing in the first place.

The answer is arithmetic. Before MCP, each LLM or AI assistant needed a custom connector to each data source and tool. Three model vendors and ten internal systems meant thirty potential integrations, each built to a different API, each maintained separately, each breaking on its own schedule. IBM's analysis of the pre-MCP ecosystem names this directly: N models times M tools required bespoke integrations, and vendors used incompatible tool APIs that fragmented the ecosystem. That overhead did not matter much for a single proof-of-concept. It became a structural budget problem the moment teams tried to scale past a handful of pilots.

MCP exists because of that economics, not because of novelty. Anthropic, OpenAI, and Google DeepMind converged on a single integration schema because the alternative, a permanently fragmenting set of proprietary tool-call APIs, imposed real engineering costs on every team building with their products.

The adoption timeline reflects that logic. OpenAI added MCP server support to ChatGPT applications by September 2025. Google also released a Data Commons MCP Server exposing its public datasets through a single server, reusable by any MCP-capable client without rebuilding connectors for each consumer. One server. Any client. No renegotiation.

Block and Apollo read that signal early. Block is a co-founder of the Agentic AI Foundation alongside Anthropic and OpenAI. Both Block and Apollo built MCP-based integrations against internal systems specifically to stop maintaining one-off LLM connectors per vendor. That investment makes sense only if the protocol survives across model providers. A multi-company foundation now governs MCP; no single vendor controls the roadmap. The Linux Foundation governance change in December 2025 was designed precisely to address that survival question, giving enterprise buyers the confidence that the schema they standardize on today will not be deprecated when a model vendor shifts priorities.

A different objection deserves attention here: REST, GraphQL, and OpenAPI already exist. Why do AI tools need a new protocol instead of wrapping existing APIs?

Thoughtworks makes the honest case for restraint. MCP can be overkill for simple projects, and for a single integration a direct API call is often the cleaner choice. That objection holds partial force. The argument for MCP is portfolio-level. When you have ten internal systems and three model vendors, the combinatorial cost of bespoke wrappers exceeds the cost of adopting one schema. Existing API standards define how services communicate with each other. MCP defines how AI clients discover and invoke capabilities at runtime, with auto-discovery through tools/list and a consistent invocation contract through tools/call. Those are different problems. Wrapping a REST API solves the former; MCP solves the latter.

The gap between the two shows up in maintenance cost, not in initial build time. A direct API wrapper built for one model vendor today requires a rewrite when you evaluate a second vendor. It requires another rewrite when the first vendor changes their tool-call schema. MCP separates the tool definition from the client consuming it, so the server survives a client swap without modification. In practice, the break-even on that investment tends to arrive around the second or third model evaluation cycle, once versioning and update costs for bespoke wrappers accumulate.

For engineering leaders building AI agent frameworks that will outlast any single model vendor relationship, the integration schema decision made in 2025 and 2026 will shape the maintenance budget for the three years after it. Block and Apollo made that calculation. The question is whether your integration strategy accounts for the same compounding cost.

What MCP Actually Does in Production Architecture

Knowing what MCP is supposed to do clarifies what it is not supposed to do, and where engineering leaders most often get burned.

MCP sits as a thin tool-access layer between your agent orchestration logic and your backend services. It complements RAG, vector databases, and frameworks like LangGraph rather than replacing them. That sentence is the architecture in full. Teams that treat MCP as a one-size solution, expecting it to handle retrieval, reasoning, and orchestration alongside tool access, are the ones whose projects underperform. Thoughtworks names this directly: MCP is not a replacement for RAG, and retrieval mechanisms remain necessary. The common failure scenario is a team migrating to MCP expecting the model will know everything, then discovering hallucinations and stale context because retrieval was never properly designed.

IBM's analysis confirms the same boundary from a different angle. MCP handles standardized access to tools, while frameworks like LangChain, LangGraph, LlamaIndex, and CrewAI handle reasoning and orchestration. Conflating them breaks the architecture.

Thoughtworks also identifies a second, equally common failure mode: overbuilding MCP for simple integrations and offloading application logic to the model. They call this a damaging antipattern that reduces a system's value and control. When decision logic moves into the model, the application loses the ability to audit, test, or constrain what happens at each step. The system becomes harder to debug and harder to trust in production. Separation of concerns is what makes production performance possible.

We built and run a production voice agent on our own phone line, and the architecture reflects exactly this boundary discipline. Orchestration logic decides when to look up a customer or schedule a call. Tool-access layers handle the actual system calls. The model does not own workflow decisions. That separation is what allows the system to hit a 1.7-second median response time, with 76% of conversation turns completing under 2 seconds across 512 measured turns. When you put workflow decisions inside the model, latency climbs and reliability drops because the model is now doing work it was not designed to do efficiently. The same boundary MCP enforces between clients, servers, and agent frameworks is what keeps production systems predictable.

The architectural picture, then, looks like this. An agent framework handles reasoning and multi-step orchestration. MCP servers expose tools the framework can call at runtime, using tools/list for auto-discovery and tools/call for invocation. RAG pipelines and vector databases handle retrieval and context. Each layer does its job. None of them substitutes for another.

One pointed objection deserves a direct answer. If MCP does not handle retrieval, orchestration, or reasoning, what concrete value does it add over writing tool-call functions directly into a LangGraph agent?

For a single agent project with one model vendor and one internal system, the honest answer is that the marginal value is small. A direct tool-call function embedded in your LangGraph agent works fine in that scope. The cost of adopting MCP for one integration may genuinely exceed the benefit.

The value compounds at the portfolio level. When a second agent needs the same tool, you have two choices: duplicate the tool-call logic in the second agent, or point both agents at a shared MCP server. When you evaluate a second model vendor, a tool-call function written against one vendor's schema requires a rewrite. An MCP server requires no modification because the client changed, not the server. When a third team wants to reuse the integration, MCP turns a one-off wrapper into a reusable asset with a defined interface.

That is the engineering leadership lens, not the developer lens. A developer optimizing a single agent project reasonably chooses the simplest path. An engineering leader building a portfolio of agents across multiple model vendors and multiple internal systems is making a different calculation, one where the break-even on MCP investment tends to arrive around the second or third reuse.

The architectural decision also has a governance dimension. When tool-call logic lives inside individual agents, tool definitions fragment across codebases. When tools live in MCP servers, the surface area is centralized, auditable, and consistently versioned. That matters when a security review asks what tools your agents can invoke. It matters when a compliance team asks for an audit trail of tool access. Centralized tool definitions are easier to review, restrict, and update than logic scattered across a dozen agent implementations.

The production discipline is the same in every case. Keep the model doing what models do well, reasoning and language, and keep tool access, retrieval, and orchestration in layers that you control, test, and audit independently. MCP formalizes one of those layers. Used correctly, it makes the whole system more maintainable. Used as a catch-all, it adds complexity without the corresponding benefit. For teams thinking through AI agent architecture decisions, the boundary discipline is the part that survives every model upgrade.

What MCP Does Not Solve: Security, Governance, and Scope Creep

Understanding where MCP fits in a well-structured architecture sharpens the next question. What does MCP leave entirely unaddressed, and where does that gap create real risk?

MCP carries no security boundary, no authorization model, and no substitute for human review of tool invocations. The teams that treat it as any of those three things are creating measurable enterprise risk that the protocol's own maintainers explicitly warn against.

The MCP specification does mandate explicit user consent before exposing data or invoking tools, treats tool invocations as arbitrary code execution, and intentionally limits how much of the prompt the server can see. The spec also states clearly that these are principles the implementation must enforce, not guarantees the protocol provides. The protocol defines the interface. Your implementation is responsible for everything that makes that interface safe to run in production.

Red Hat security engineers document the gap precisely. Their analysis identifies three distinct risk categories in MCP deployments: the confused deputy problem, OAuth design issues that conflict with modern enterprise authentication practices, and command injection risks for local servers. These are not theoretical. They are structural properties of how MCP servers execute commands and make API calls. A server that can write files or call external APIs can be directed to do both by any client that can reach it, unless your implementation adds controls the protocol does not include.

The April 2025 security research adds three more. Researchers identified prompt injection vulnerabilities, tool permission designs that allow combining multiple tools to exfiltrate data, and lookalike tools that can silently replace trusted ones without the client detecting the substitution. That last category is the one that catches teams off guard.

Community-built MCP servers make the lookalike-tool risk concrete. Thoughtworks warns that community-built MCP servers are untested and should be used at your own risk. Because an MCP server can be written in 100 to 200 lines of code, the ecosystem now contains thousands of unvetted servers. A team installing a community "GitHub MCP server" could be granting an LLM write access to private repositories without reviewing what tools the server actually exposes. The server's name describes the integration. The server's tools define the actual permissions. Those two things do not always match.

On engagements we have run, the pattern we observe consistently is that teams underestimate the surface area they are opening when they install a community server. The instinct is to treat MCP like an npm package: find one that does what you need, install it, move on. The difference is that an npm package runs code you can audit. An MCP server hands an LLM a set of tools with real system access, and the LLM decides when and how to use them based on context that includes untrusted inputs from the outside world. That is a different risk profile than a library dependency.

A fair pushback: Anthropic and the Linux Foundation are actively hardening the spec, with OAuth flows, PRM documents, and working groups targeting the March 2026 roadmap. Won't these concerns be resolved at the protocol level?

The governance progress is real. The Agentic AI Foundation represents a genuine multi-company commitment to improving security properties across the spec, and the working groups are doing legitimate hardening work. Protocol improvements move on a multi-quarter cadence. You are deploying agents now, against systems that have real data and real consequences for unauthorized access. Authorization, audit, and least-privilege design have to live in your implementation today, not in a future spec version scheduled for review next year.

The practical implication: every tool your MCP server exposes should be purpose-scoped, not general-purpose. An early version of our own MCP server included a general-purpose SQL query tool. We removed it after recognizing that a broad query tool can be coaxed into reading stored secrets, and that an AI agent processing untrusted web content is exactly the kind of prompt-injection target that makes a general query tool dangerous. Every tool on our server is now purpose-built and scoped. The server enforces DNS-rebinding protection, an explicit host and origin allowlist, and bearer-token authentication. Sign-in is restricted to verified organizational accounts. That architecture did not come from the MCP spec. It came from treating tool invocations as arbitrary code execution, which is what the spec asks implementers to do, and then building the controls that assumption requires.

The governance question for engineering leaders is whether you have designed authorization, consent, and tool-scope policies that can survive a security review today. Teams that skip that design step and rely on future spec versions to close the gap are the ones who end up rolling back agentic features under compliance pressure after their first security review. Scope control, audit trails, and least-privilege tool definitions are implementation decisions. The protocol will not make them for you, and the March 2026 roadmap will not retroactively secure what you shipped in Q1. Teams thinking through how to build an AI agent responsibly should plan the policy work alongside the protocol work, not after it.

Where MCP Belongs on Your 2026 Roadmap

Pick one high-value internal system. Your CRM, your code repository, or your data warehouse. Build a single MCP server against it before standing up a second one. The first server teaches you what authorization, consent, and tool-scope policies your environment actually needs, and those lessons compound across every server that follows. Pair the pilot with a written authorization, consent, and tool-scope policy. The protocol does not give you those by default, and skipping that step is how teams end up rolling back agentic features after their first security review. The teams that succeed in 2026 will be the ones whose first server was scoped tightly enough to survive an audit, and whose policy document was written before the second server was approved.