What is MCP?

Knowledge, data and integration

MCP means Model Context Protocol. It is an open protocol for connecting AI applications and assistants to external tools, data sources and reusable context in a more standardised way. Instead of building a completely bespoke connection between every AI client and every business system, MCP defines a common pattern for how those systems can describe capabilities and exchange information. That does not make MCP a magic adapter or a guaranteed enterprise standard. It means there is now a shared protocol that may reduce integration friction if it is adopted and governed sensibly.

What this means

The practical translation for leaders is straightforward. If an API is the interface to a specific system, MCP is often the pattern that lets an AI host discover and use tools or context that may sit above, alongside or behind those APIs. In other words, MCP is usually not replacing APIs. It is more often orchestrating access to capabilities that are ultimately backed by APIs, databases, file systems, search services or other existing technology.

That distinction matters because a lot of the current discussion about MCP mixes real value with hype. The value is genuine: a protocol can lower the friction of connecting assistants to approved sources and tools. The hype appears when people talk as if a protocol alone solves trust, permissions, maturity or operational risk. It does not. MCP can simplify connection patterns. It cannot decide what an assistant should be allowed to do, whether a source is trustworthy, or whether the result should be accepted without review.

Why it matters

Why does this matter now? Because many AI deployments stall at the boundary between "interesting demo" and "useful work". Teams can get a model to speak fluently, but the moment they want it to pull from the ticketing system, search internal guidance, open a task, inspect logs or work inside a governed workflow, they hit integration friction. MCP's appeal is that it offers a common way to expose those capabilities to AI hosts without creating a fresh custom contract for every pairing.

That can be useful for internal knowledge access, governed retrieval, coding assistants, support copilots and more agentic workflows. A team may want one assistant to search approved documentation, another to call a case lookup tool, and a third to run a constrained internal action. If each connection is built differently, security review and maintenance become slow. A standardised protocol can make the shape of those integrations more consistent, which helps both builders and operators.

But the risk side grows with the convenience. Once an AI host can reach tools and live systems, the organisation has opened a wider action surface. The UK National Cyber Security Centre has warned that agentic systems increase risk because they can have broader system access, behave in harder-to-predict ways and act faster than humans can meaningfully review. MCP does not create those problems on its own, but it often sits exactly where those problems become operational.

How it works

At the architecture level, MCP uses a host, client and server pattern. The host is the AI application the user interacts with. It may be a chat client, coding environment or another assistant surface. The host creates clients that maintain connections to MCP servers. Those servers provide capabilities and context. The official specification describes communication using JSON-RPC messages and capability negotiation between the components.

The server side can expose several different primitives. Tools are functions the model can invoke, such as querying a system, triggering a calculation or calling another service. Resources are data or context items, such as files, schemas or application-specific information, that can be presented or attached for use. Prompts are templated workflows or instructions supplied by the server for users to invoke. This matters because "connected to MCP" does not always mean the same thing. One deployment may only offer tools. Another may expose resources and prompts as well. A third may add interactive UI capabilities through product-specific support.

The control model also varies by primitive. In the specification, prompts are designed to be user-controlled. Resources are application-driven. Tools are model-controlled, and the specification recommends keeping a human in the loop with the ability to deny tool invocations. That is a useful design clue for non-technical leaders: not every capability should be left to automatic model choice. Some actions deserve confirmation, especially when write access, external effects or regulated data are involved.

Authorisation is another area where maturity matters. The specification includes an authorisation framework for HTTP-based transports and aligns it with established identity patterns such as OAuth discovery and protected resource metadata. At the same time, the specification makes clear that authorisation support is optional and transport-specific. In practice, that means buyers and builders still need to ask hard questions about identity, token handling, delegated access, consent and revocation. The existence of a spec does not remove the need for enterprise access design.

There is also an operational difference between local and remote servers. A local server can run on the user's machine and may be useful for tightly scoped tasks such as repository or file access. A remote server can serve many clients over HTTP and may be easier to govern centrally. Neither model is automatically safer. Local servers expand what runs on the endpoint. Remote servers create clear network-facing dependencies. The right choice depends on the workflow, the trust boundary and the control model.

Where it shows up in real workflows

A good workflow example is internal support. Imagine a service operations assistant used by staff handling customer escalations. Through MCP, the host might expose a read-only ticket lookup tool, a resource containing the current escalation policy, and a prompt template for summarising a case handover. That is much more useful than a generic chat window. But it only works well if the assistant is limited to the necessary accounts, if its outputs are logged, and if any write action still requires human confirmation.

A second example is software delivery. A coding assistant in an IDE may use MCP to inspect repository issues, query deployment logs, fetch API documentation and run test-related utilities. This can speed up triage and debugging. It can also create a powerful failure mode if the wrong server is trusted, if a tool returns poisoned content, or if the assistant is allowed to change production-facing resources without review. The protocol helps the connection exist; it does not remove the need for environment separation or approval gates.

A third example is knowledge work in finance or procurement. An assistant may search a governed resource set of policies, supplier data and approved templates, then suggest a draft response or pre-fill a request with retrieved facts. In that model, MCP can be genuinely useful because it keeps the interaction tied to current source systems instead of whatever staff happen to paste into chat. But the safer pattern is usually constrained and role-aware: read the policy, suggest the draft, ask the person to approve the next step.

Common misunderstandings

The most common misunderstanding is that MCP is the new name for APIs. It is not. APIs remain the underlying interface for many business systems. MCP often sits one level higher, packaging tools and context for AI clients and coordinating how a host reaches them. Another misunderstanding is that MCP is simply RAG by another name. Again, no. RAG is a retrieval pattern. MCP can help expose resources or tools used in retrieval, but it is broader than retrieval and can include actions as well as context.

It is also a mistake to think open protocol equals solved security. Prompt injection remains a central risk because AI systems do not strongly separate instructions from untrusted content. An MCP server may expose resources or return tool outputs that become part of the model's context. If those inputs contain malicious instructions, the assistant can be manipulated unless the wider system applies sensible boundaries. The right mental model is not "MCP makes agentic AI safe". It is "MCP gives agentic AI another connection surface that must be governed".

A final misunderstanding is to treat current product support as uniform. It is not. Major clients now document MCP support, but the feature sets vary. Some support tools, resources and prompts. Some support only tools. Some support remote HTTP flows and OAuth-based authorisation patterns. Others do not. That variation is normal for an emerging standard, but it means procurement and pilot design should be grounded in the specific host product, not in protocol branding alone.

Risks and boundaries

This unevenness shows up clearly in public product documentation. Official documentation from major tools shows that MCP is already supported across some AI assistants and development environments, but not always in the same way. VS Code documents support for tools, resources, prompts and interactive apps. GitHub Copilot documents MCP support and enterprise controls, but the Copilot cloud agent currently supports only tools and does not currently support remote OAuth-based MCP servers. OpenAI documents both remote MCP servers and managed connectors. Those are signs of meaningful momentum, but also signs that buyers should verify capability-by-capability what a given host really supports.

The security concerns are not theoretical. Source boundaries matter. Teams need to know which servers are allowed, which tools are exposed, which actions are reversible, which resources are trustworthy, and what happens when the model is uncertain. They should review third-party servers as carefully as they would review any integration component. They should also decide what gets logged: user request, tool invocation, server used, response received, human approval step and resulting action. Without that, incident review and accountability are weak.

Prompt injection deserves special attention. MCP can improve interoperability, but it does not change the underlying fact that an LLM may be influenced by hostile content from a document, a webpage, a knowledge base entry or a tool response. For that reason, least privilege matters more, not less. If a compromised or manipulated run can only read a narrow set of low-risk resources, the damage is constrained. If it can write broadly across finance, service and identity systems, the problem is far more serious.

There is also a vendor maturity boundary. Some products may retain data differently, support only subsets of the spec, or expose limited administration controls. MCP is promising enough that teams should learn it. It is still young enough that teams should not assume consistency.

What leaders should do next

Leaders considering MCP should resist the urge to start with the broadest possible automation. Start with one low-risk, read-oriented workflow where better context would clearly help staff. Choose a host with visible controls and a server with narrow scope. Ask which MCP features are actually supported in your chosen product: tools only, or also resources and prompts? Local transport or remote? What authorisation model is used? How are tokens stored? Can access be limited by role, project or environment?

Then add practical guardrails. Keep write tools behind human approval. Prefer least privilege and allowlists over broad access. Separate test from production servers. Sandbox local servers where the host allows it. Maintain an inventory of approved servers and their owners. Test adversarial scenarios, including prompt injection through retrieved content and unsafe tool descriptions. Plan offboarding as well as onboarding, because stale connector access is a real operational risk.

Handled this way, MCP can be useful without being romanticised. It is a promising connection pattern in an ecosystem that clearly wants more interoperability between AI hosts and real business systems. It is also early enough that support varies, controls differ and governance questions still matter more than slogans. For most organisations, that means pilot carefully, learn the boundaries, and treat MCP as an integration layer that deserves the same seriousness you would apply to any other pathway into live systems.

FAQs

Is MCP a replacement for APIs?

No. APIs still do the underlying work of exposing data and operations from business systems. MCP often uses or wraps those capabilities so that AI hosts can discover and use them through a more standardised protocol. If you removed the underlying APIs, databases or files, MCP on its own would not magically recreate them.

Should a small or mid-sized organisation adopt MCP now?

Possibly, but usually for a narrow use case rather than a broad platform bet. MCP is already useful in some tools and workflows, especially where the same assistant needs governed access to external context or utilities. The sensible approach is to test support, permissions, logging and review controls in one contained scenario before expanding.

Can MCP be used safely with internal systems and private data?

It can, but only if you treat it as a governed connection pattern rather than a convenience feature. Decide whether the server is local or remote, how identity is handled, what data is exposed, what actions are allowed, how approvals work and what gets logged. The safety question is mostly about scope, control and monitoring, not about the acronym itself.

Sources

‹ What is a knowledge base in AI work?

What is ML? ›