What Is MCP (Model Context Protocol)?

What is MCP?

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data sources through one consistent interface.

The usual analogy is a USB-C port for AI. Before it, connecting an assistant to a service meant a custom integration for that specific pairing — and the work multiplied with every new combination. Ten assistants and ten services implied a hundred integrations. MCP turns that into twenty: each service exposes one MCP server, each assistant speaks MCP once.

Anthropic announced it in late 2024 and handed it to the Linux Foundation in late 2025. By 2026 it had become the default answer to "how do I give a model access to this?" — Monday's overview puts adoption at tens of thousands of public servers and over sixty thousand open-source projects.

The problem it solves

A language model on its own knows nothing about your systems. It cannot read your database, check your calendar, or open a file. Everything useful requires connecting it to something.

Before MCP, every one of those connections was bespoke: your own auth handling, your own schema for describing what the tool does, your own error conventions — repeated per assistant. Change assistant and you rewrote the lot.

MCP standardises three things: how a tool describes itself, how it is called, and how results and errors come back. That is genuinely all it is. The value is not sophistication; it is that everyone agreed.

How it actually works

There are two sides.

An MCP server wraps a capability and exposes it. It advertises the tools it offers — each with a name, a description, and a schema for its inputs — and executes calls against them. A server might wrap a database, a filesystem, a ticketing system, or an internal API.

An MCP client is the assistant. It connects to servers, reads the tool list, and decides when to call something. The model sees tool descriptions as part of its context and chooses based on them.

The practical consequence is that your tool descriptions are part of your prompt. A vague description produces a tool the model calls at the wrong moments. Writing good ones is closer to interface copywriting than API documentation — name things by what someone would recognise, be explicit about when a tool applies, and say what it does not do.

What this enables

The honest framing: MCP does not make models more capable. It makes them connectable, cheaply.

The practical result is that connecting an assistant to an internal system went from a project to an afternoon. That changes what is worth building. Plenty of internal integrations that could never justify bespoke work now clear the bar — which is precisely why 2026 saw an explosion of small, single-purpose servers rather than a few large ones.

The security questions to answer first

This is where the enthusiasm needs tempering, because MCP is a mechanism for granting a model access to your systems, and it deserves the scrutiny that implies.

Everything a tool returns is untrusted input. If an MCP server reads web pages, emails, or user-submitted documents, its output may contain text engineered to look like instructions. An assistant that treats returned content as commands is exploitable. This is prompt injection with a delivery mechanism, and it is the central risk.

Third-party servers run with your permissions. Installing an MCP server from a public registry is closer to installing a dependency with credentials than to adding a browser extension. Read what it does. Prefer ones you or a trusted party maintain.

Write access is a different decision from read access. The mature pattern in 2026 is that assistants may read freely within scope but need human approval for write actions — creating records, changing status, sending anything. Enterprise deployments generally enforce that boundary structurally.

Scope credentials narrowly. A server given broad database access will use it. Give it the narrowest permission set that still does the job, and audit what it retained afterwards.

Should you adopt it?

If you are connecting AI assistants to internal systems: almost certainly yes. There is no longer a competing standard worth betting against, and writing bespoke integrations means rewriting them later.

If you are building a product other people integrate with: shipping an MCP server is becoming a reasonable expectation, in the way a REST API became one.

If you are experimenting: start with read-only servers against non-production data, and add write access only once behaviour is predictable.

What MCP does not do is absolve you of the design questions around agent behaviour. It makes the plumbing standard. What the model does with that access is still your problem.

If you are weighing MCP for internal systems and want an honest read on the security posture, book a call.

Common questions