Model Context Protocol (MCP)

The Model Context Protocol, or MCP, is an open standard for how AI applications reach tools and data sources. Build an integration once as an MCP server and any application that speaks the standard can use it, instead of rewriting it per application.

How does MCP work?

There are two roles. The server exposes capabilities, such as "search this database" or "create a ticket". The client is the AI application that uses them.

On connecting, the client asks the server what it offers and gets back a machine-readable description of each tool: name, purpose, expected inputs. Those descriptions go into the context window so the model knows what is available.

When the model needs a tool, the client calls it and returns the result into the conversation. The model never talks to your systems directly. The client always sits in between, and that is precisely where permissions and logging belong.

Why does MCP matter?

Before it, every integration was bespoke. Access to your CRM had to be written again for each AI application, and switching vendors meant starting over. A standard turns the integration into a component with its own lifecycle.

For you the main consequence is less vendor lock-in. The investment sits in the connections to your systems rather than in one vendor's interface. Change the model or the surrounding tooling and the connections survive.

In practice MCP is the wiring that makes an AI agent capable of acting at all. Without tools, an agent is just a conversational partner.

What to watch

An MCP server is an access path into your data and has to be treated as one. The decisive question is not what the tool can do but which permissions it runs with. A server operating under a full-access account effectively hands that access to the model.

Second, tool descriptions are text that flows into the model. If a server did not come from you, neither did that text. Third-party MCP servers should therefore be reviewed and given narrow permissions before they touch production data. That decision belongs in AI governance.

How to recognise a usable MCP server

Four properties separate a solid integration from one that causes trouble in production.

Narrow tools rather than broad ones. "Create a ticket in queue X" beats "run arbitrary SQL". The more tightly a tool is scoped, the less damage a bad judgement by the model can do.

Reads and writes separated. Many applications need only read access. Bundling both into one server throws away the simplest available safeguard.

Informative error messages. A tool that explains what it expected when given bad input leads to a second, correct attempt. A tool that merely fails leads to an invented answer.

Complete logging. Which tool was called with which values, triggered by which case. Without that log there is no establishing what happened after an incident.

Those four points double as a usable review checklist for third-party servers, and the answers tell you more about production readiness than the number of tools on offer.