What is MCP (Model Context Protocol)?

The Problem MCP Addresses

An AI assistant is far more useful when it can reach real systems — files, databases, ticketing, calendars, code repositories.

Before a standard existed, every combination required its own integration. Ten AI applications and ten data sources meant a hundred bespoke connectors, each maintained separately.

MCP defines one protocol. A data source implements an MCP server once, and any MCP-capable client can use it. The integration problem becomes additive rather than multiplicative.

Servers, Clients and Hosts

An MCP server exposes capabilities — a connection to a database, a filesystem, an API. It is usually small, and many are a few hundred lines.

An MCP client lives inside the AI application and speaks the protocol.

The host is the application the user interacts with, which manages clients and decides what the model is permitted to reach.

What a Server Can Expose

Tools — actions the model can invoke, such as querying a database or creating a ticket. These have side effects and are the part requiring most care.

Resources — data the model can read, such as file contents or records.

Prompts — reusable prompt templates the server offers for common tasks.

The separation matters: reading a resource is safe in a way that invoking a tool is not.

Why It Matters

For developers, integrations built once work across every compatible client, which removes a great deal of duplicated effort.

For organisations, it means internal systems can be exposed to AI assistants through a consistent, auditable interface rather than through ad hoc scripts.

For the wider ecosystem, it is the difference between every AI vendor building a closed integration garden and a shared layer any application can use. Adoption across major AI products has been rapid enough that it is now the default assumption for tool connectivity.

Security Considerations

MCP gives a model the ability to act. That deserves the same scrutiny as any other automated access to production systems.

The specific risks: an MCP server exposing more than intended, prompt injection in retrieved content causing unintended tool calls, and tools with destructive side effects invoked on a misunderstanding.

Sensible practice: least-privilege access on every server, human confirmation for destructive actions, treating all retrieved content as untrusted input, and auditing what tools are actually available to a given assistant.

Deciding Whether to Build a Server

The appeal is obvious and the work is larger than a wrapper, so the decision is worth making deliberately.

It is worth building when several different assistants or clients need the same capability, so one server replaces several bespoke integrations; when the capability is stable enough to have an interface; or when you are exposing something to people outside your team who should not need your internals.

It is not worth it when one application needs one integration — a direct API call is simpler and has fewer moving parts; or when the underlying thing changes weekly, because you are now maintaining an interface over a moving target.

What building one actually involves beyond the protocol: deciding what to expose and what to withhold, which is the real design work; authentication and authorisation, which the protocol does not solve for you; error behaviour that a model can act on rather than a stack trace; and versioning, because a client built against your server will break when you change it.

Treating a Server as an Untrusted Boundary

The security position that matters: anything a server returns is data, not instruction, and a model reading tool output is reading content someone else may control.

That produces concrete requirements. Scope credentials to the minimum — a server with broad write access is a broad write capability handed to whatever text arrives. Require confirmation for consequential actions: sending, deleting, paying, publishing. Log every call with its arguments, because reconstructing what an agent did without that is close to impossible. And treat third-party servers as third-party code, because that is what they are — read what it does before connecting it to anything holding your data.

The failure mode to picture: a server returns a document containing text addressed to the model rather than to you, the model treats it as an instruction, and the next tool call does something you did not ask for. The protocol does not prevent this and is not supposed to. The boundary is yours to enforce — covered in full on the prompt-injection page.

Sources

What each claim on this page rests on. Entries are typed so you can see which are primary.