The Model Context Protocol: how AI actually connects to the world outside its context window

The concept most people gloss over when they first encounter AI agentsAI agentsAgentic AI refers to AI systems that pursue goals autonomously by planning, taking actions through tools, and adapting based on results, with minimal step-by-step human direction.View full definition → is not the agent itself. It is the plumbing that makes the agent useful: how does the language model actually reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → out and do something? Read a file, query a database, call an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, update a ticket in Jira? The Model Context Protocol, or MCP, is the answer Anthropic proposed in late 2024, and it has since become a de facto standard across a surprisingly broad range of tooling. Understanding it properly is the difference between knowing that agents "can use tools" and knowing what that actually requires in practice.

Why it matters for managers and technical leads specifically

If you are evaluating AI deployments, negotiating vendor contracts, or deciding whether to build versus buy an agent capability, MCP is not an implementation detail you can safely ignore. Here is why.

Before MCP, every AI tool integration was bespoke. If you wanted Claude to read your Salesforce data, someone had to write a custom connector. If you then wanted the same capability in a different model, someone had to write another one. Multiply that across a dozen tools and three or four models, and you have a maintenance nightmare and significant engineering cost.

MCP defines a shared interface. A server that exposes your company's CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition → data via MCP can, in principle, be called by any MCP-compatible client, whether that is Claude, a GPT-4-based workflow, or an open-source model running on your own infrastructure. This is architecturally similar to what REST standardised for web APIs in the early 2000s. The analogy is not perfect, but the strategic logic is the same: standardisation lowers integration cost and increases optionality.

For non-technical leaders, the practical implication is that when a vendor tells you their tool is "MCP-compatible," that is a specific, testable claim, not marketing language. You can ask exactly which capabilities they expose as MCP tools, what authentication model they use, and whether their server implementation has been independently tested against the spec. That is the level of specificity the conversation should reach.

How it actually works

MCP is a client-server protocol. The model (or the application wrapping the model) is the client. The external system you want the model to interact with runs an MCP server. The server exposes a defined set of resources, tools, and prompts. The client discovers what is available, and the model can then decide to invoke a specific tool during a conversation or task.

A concrete example makes this clearer. Say you are building an internal assistant that helps finance analysts query budget data. You set up an MCP server that connects to your financial database. That server advertises one tool: `query_budget`, which takes a department name and a fiscal year as parameters and returns a JSON summary. When an analyst asks the assistant "What did the marketing department spend on external agencies in Q2 2026?", the model recognises that this requires live data, calls `query_budget` with the appropriate parameters, receives the result, and incorporates it into a natural language response.

Three things are worth noting about this flow.

First, the model does not have direct database access. It calls a tool via a defined interface, and the MCP server controls what the tool actually does. This matters for security: you are not giving the model free access to a database, you are giving it access to specific, governed operations.

Second, the model has to decide to use the tool. This decision is part of the model's reasoning process. A model that has been well-instructed and sees a clear tool available will generally use it correctly. A model that is poorly prompted, or that faces an ambiguous tool description, may not. Tool descriptions inside MCP servers need to be written with the same care as a good API documentation page.

Third, MCP supports not just tools (actions the model can invoke) but also resources (data the model can read, like documents or database records) and prompts (pre-structured interaction templates). Most current implementations focus heavily on tools, but the resource layer is increasingly important as organisations want models to work with proprietary content without copying it into the context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition → permanently.

As of mid-2026, MCP support is built into Claude's API (Anthropic being the protocol's originator), available in several versions of the OpenAI Assistants API, and implemented in frameworks including LangChain, LlamaIndex, and the open-source AutoGen project from Microsoft Research. The ecosystem is real and growing, though maturity varies significantly by platform.

When to use it and when not to

MCP fits well when you have a stable external system that a model needs to interact with repeatedly, when multiple models or applications might need that same access, and when you have engineering capacity to run and maintain a server.

It is less appropriate when you are prototyping quickly and a hardcoded function call will do the job in an afternoon. The overhead of setting up a proper MCP server, handling authentication, writing solid tool descriptions, and managing versioning is real. For a one-off automation that touches a single API, that overhead is not justified.

There is also a security tradeoff that deserves direct attention. MCP servers can be targeted by what researchers call prompt injection via tool results: an attacker embeds malicious instructions in data that gets returned to the model through a tool call, hoping the model will follow those instructions. If your MCP server pulls content from external sources (web pages, customer emails, third-party APIs), this is not a theoretical risk. It is an active area of concern in the security community as of 2026, and production deployments need explicit mitigations, including output validation and careful scoping of what tools can return.

The honest picture of MCP is this: it solves a real coordination problem in AI systems, and the standardisation it offers has genuine long-term value for any organisation running more than a handful of integrations. But it introduces its own complexity and its own attack surface. Treating it as infrastructure, with the same rigour you would apply to any API layer, is the right posture.

Any organisation that expects to run AI agents at scale across multiple tools will eventually need something like MCP, whether under that name or a successor. Starting to understand the architecture now, rather than when a vendor is already in the room, puts you in a far better position to ask the right questions.