MCP explained:
How AI connects to your tools and data

If an AI assistant can only discuss a customer record, the risk is mainly whether its answer is accurate. If it can open the customer record, update it, send an email, raise a purchase request or trigger code, the decision problem changes. The question is no longer only what can the model say? It becomes what can this system touch, under whose authority, and with what controls?

That is the practical significance of Model Context Protocol, usually shortened to MCP.

Anthropic introduced MCP in November 2024 as an open standard for connecting AI applications to external systems.¹ A year later, MCP was donated to the Agentic AI Foundation under the Linux Foundation, with support from a broad group of major AI and cloud companies.² OpenAI supports MCP across the Responses API, Agents API, and ChatGPT and Codex plugin and integration tooling.³ The useful conclusion is not that every organisation should rush to adopt it. It is that MCP has moved quickly from developer experiment towards infrastructure that decision-makers are likely to encounter in vendor proposals, internal architecture discussions and AI procurement.

The simplest mental model: a standard socket for AI

The usual analogy is “USB-C for AI”. It is useful, up to a point. A USB-C port gives many devices a common way to connect. MCP gives AI applications a common way to discover and use capabilities exposed by other systems.

The analogy becomes misleading if it suggests MCP is merely a passive cable. An MCP connection may expose information, but it may also expose actions. A tool can query a database, create a ticket, update a record or call another service. The protocol makes those capabilities legible to the AI application; it does not decide whether they are safe or appropriate to use.

MCP in one diagram

The protocol standardises the connection layer between an AI application and external capabilities.

1. Person or workflowAsks for work
2. AI host or appReasons and coordinates
3. MCP clientSpeaks the protocol
4. MCP serverExposes resources, prompts and tools
5. External systemHolds data, APIs and software actions

MCP standardises the middle of the chain. It does not replace identity, authorisation, business rules or audit.

There are five useful pieces in that diagram:

• The person or workflow asks for something to be done.
• The AI host or application contains the model experience and coordinates what happens.
• The MCP client is the component that speaks the protocol to an MCP server.
• The MCP server presents capabilities in a standard form.
• The external system remains the place where the underlying data, API or software action actually lives.

That last distinction matters. An MCP server does not make your CRM, document store or finance system disappear. It usually sits in front of existing software and gives an AI application a standard way to reach selected parts of it.

What can an MCP server actually expose?

At its core, MCP has three concepts that are worth learning because they correspond to three different kinds of organisational reach: resources, prompts and tools. The names sound technical; the management implications are not.

What an MCP server can expose

Three core primitives give the AI application different kinds of reach.

Resources

Context and dataFiles, records, schemas and application information

Prompts

Reusable guidanceStructured prompt templates and interaction patterns

Tools

Callable capabilitySearch, query, create, update or trigger an action

An MCP server can expose one, two or all three. The protocol defines the interface; the host decides how they are presented and governed.

Resources are information made available as context: files, records, schemas or application-specific data. Think of them as things the AI application may be allowed to read or inspect.

Prompts are reusable templates or structured interaction patterns exposed through the server. They can package a known task or method so that the user or application can invoke it consistently.

Tools are callable functions. This is where MCP becomes operationally important. A tool might search, calculate, create, update, send, trigger or execute. Current official MCP documentation describes tools as functions that models can discover and invoke to interact with external systems.⁴

An MCP server may expose any combination of those capabilities. That means “we have an MCP connection” tells you very little about risk. A read-only resource server exposing a policy library is a different proposition from a server able to edit production records or initiate payments.

MCP is not an agent, an API or a connector—although it may sit beside all three

Much of the confusion around MCP comes from adjacent terms being used as though they describe the same thing. They do not.

On a narrow screen, each term is shown as a separate card.

The API distinction is particularly important. MCP is not an “API killer”. A server may simply translate MCP tool calls into the existing API calls that the underlying application already understands. The standardisation happens at the AI-facing layer, not necessarily inside the business system itself.

Nor does a common protocol guarantee that every MCP implementation is interchangeable. Different servers can expose different tool names, parameters, permissions, data models and quality levels. A standard plug shape reduces integration friction; it does not make every appliance identical.

Why organisations care

The commercial attraction is straightforward: MCP can reduce the amount of bespoke integration work required each time an AI application needs access to another system. A host that understands MCP can, in principle, work with many MCP servers rather than needing a unique interface for each combination of model and data source.

That creates several possible benefits:

• Faster experimentation. A team can expose a capability once and make it available to more than one compatible AI client.
• More composable systems. Several focused servers can be combined rather than one monolithic integration owning everything.
• A wider supplier ecosystem. Vendors can present tools and data through a shared protocol rather than requiring every AI platform to build a bespoke adapter.
• Potentially lower switching friction. An open protocol can make integrations more portable, although portability still depends on the actual tool definitions, permissions and application logic.
• A cleaner route from conversation to workflow. The same interface that retrieves context can also expose tools that perform controlled actions.

This is why MCP belongs in a decision-maker vocabulary even when the reader will never configure a server personally. It is becoming part of the plumbing by which AI systems move from isolated chat interfaces towards operational software.

The management issue is authority, not connectivity

Imagine a procurement director using an AI assistant connected to contract files, supplier records and the purchasing system. The instruction is simple: “Show me the renewals due in the next 90 days, identify price increases and prepare negotiation notes.”

If the MCP connections are read-only, the assistant may be able to find the contracts and supplier history but not alter anything. If another tool can create draft purchase orders, the authority has expanded. If it can email suppliers or approve an order, it has expanded again. The user interface may still look like the same chat window; the operating risk is completely different.

That is the point at which the USB-C analogy runs out. Standardised connectivity is useful. Standardised connectivity is not standardised trust.

MCP is the connection layer, not the control system

Managers still need to design the layers that determine who can do what, when and with what evidence.

1. MCP connectionHow the AI application reaches the capability
2. IdentityWhich user, agent or service is making the request?
3. AuthorisationWhat may this identity read, write or execute?
4. Human approvalWhich sensitive actions must pause for confirmation?
5. Isolation and limitsHow large is the blast radius if something fails?
6. Audit and monitoringWho did what, and can the organisation reconstruct it?

MCP makes reach easier. Governance determines whether that reach is safe and appropriate.

The current MCP specification is explicit that powerful data-access and code-execution paths create trust and safety obligations, and that consent, access control and tool safety must be designed by implementers.⁵ OWASP makes the same point more bluntly: MCP combines ordinary integration risks with agentic behaviour, prompt injection and the possibility that a model chooses which tool to invoke and with what parameters.⁶

Where the security risk actually comes from

MCP is not dangerous simply because it is MCP. The risk comes from the combination of reach, permissions and AI-mediated decision-making. Several failure modes are especially relevant to managers and buyers.

Over-scoped authority. A server that only needs to read one data set should not inherit broad administrative credentials. Least privilege matters more when a model can dynamically select tools.

Untrusted servers and supply chains. An MCP server is software. If the package, update or dependency is malicious or compromised, the protocol does not make it trustworthy. Server provenance, version control and update discipline therefore become procurement questions, not merely developer hygiene.

Prompt injection through tools and data. Tool descriptions and returned content can themselves carry malicious instructions. OWASP describes “tool poisoning” and related attacks in which seemingly legitimate tool metadata or responses influence the model into taking an unintended action.⁶

Too much automation too soon. A low-risk read-only search on a trusted server may justify standing, informed approval within a tightly bounded scope. Destructive, financial, data-sharing or production-changing actions should require action-specific confirmation. The control should reflect the consequence, not the novelty of the technology.

Weak auditability. If an AI system can call tools, the organisation should be able to reconstruct which identity requested the action, which tool was called, with what arguments, what the result was and whether a human approved it.

The Wiz security checklist that prompted this explainer recommends many of the same controls: allowlisting approved servers, tightly scoped credentials, human confirmation for write and execute operations, sandboxing, egress restrictions, centralised gateway controls and full-fidelity audit logging.⁷ Wiz is a security vendor and the document ends with a product pitch, so those recommendations are better treated as commercially interested guidance than as neutral proof. Their value here is that they align closely with independent OWASP guidance and the protocol’s own security principles.

Why some MCP explainers are already out of date

The 2026-07-28 revision made the current protocol core stateless: it retired the initialize/initialized exchange and Mcp-Session-Id, added Mcp-Method and Mcp-Name routing headers, and hardened authorisation. That does not make applications stateless, and current SDKs can still use the legacy handshake when they negotiate an older protocol revision.⁸

Persistent-session diagrams describe earlier revisions; they are not current implementation guidance for a connection negotiated under 2026-07-28.

For a decision-maker, the important point is not the wire format. It is that MCP is being redesigned for more ordinary production infrastructure, easier scaling and stronger enterprise operation.

This is also a useful procurement warning. “Supports MCP” is not a sufficiently precise claim. Buyers should ask which protocol and SDK versions are supported, how updates are handled, what is deprecated, and how the supplier prevents a protocol upgrade from quietly changing permissions or tool behaviour.

Eight questions to ask before approving an MCP connection

Use these questions with an internal team, vendor, developer or implementation partner before treating an MCP connection as routine infrastructure.

On a narrow screen, each approval question is shown as a separate card.

The answers need not all be “maximum control”. After informed consent, a low-risk, read-only research tool may justify lighter friction than a tool capable of financial or production changes. The useful discipline is to make the authority visible and deliberate.

What to remember

MCP is likely to become less interesting as it succeeds. Good infrastructure disappears into the background. That is precisely why it is worth understanding before it becomes a box on an architecture diagram that everyone assumes somebody else has governed.

If you remember one sentence, use this one: MCP standardises how AI reaches tools and data; your organisation still has to decide what that AI is allowed to do once it gets there.

The practical management question is therefore not simply “Do we support MCP?” It is: “What authority are we standardising, through which server, under whose identity, with what approval, and with what audit trail?”