Model Context Protocol (MCP)
Model Context Protocol is an open standard for connecting AI assistants to external tools and data sources through a consistent interface. It lets one assistant work across many systems without bespoke plumbing for each, and it defines how those systems expose the actions an assistant may call.
Also known as: MCP, MCP integration, MCP server
Last reviewed
Why MCP matters commercially
Before a shared standard, every connection between an AI assistant and a business system was bespoke: separate work to reach your CRM, your job system, your document store, repeated for each assistant you wanted to use. That cost scaled badly and it locked each integration to one vendor's way of doing things.
MCP replaces that with one interface. Expose a system once and any MCP-capable assistant can use it. For a business the practical consequence is that connecting AI to your systems becomes a one-off piece of work with reuse, rather than a per-assistant project — and the integration outlives whichever assistant you happen to use today.
How MCP works
A system is exposed through an MCP server, which declares what it offers: the data an assistant may read, and the actions it may take, each with a defined input and output. The assistant is the client, and it discovers what is available rather than having it hard-coded.
The important property for a business is that the server decides what is on offer. Permissions, validation and audit logging live on your side of the boundary, in code you control, not in a prompt. That makes MCP a reasonable foundation for guardrails rather than something you have to work around — and it is increasingly how we connect agents to real systems.
MCP vs a conventional API
An API is built for developers writing code against it, with documentation a person reads. An MCP server is built for a model: it describes its own capabilities in a form an assistant can discover and reason about at run time.
In practice MCP usually sits in front of APIs you already have rather than replacing them. It is a presentation layer for AI consumers, which is why exposing a system over MCP is normally a smaller project than it sounds — the underlying integration work may already be done.
When you need it
Consider MCP when you want one assistant working across several of your systems, when you expect to change assistant or model provider and do not want to redo the integrations, or when you are building agents that need a governed way to take actions.
You do not need it for a single AI feature inside one application; a direct call is simpler. The judgement is about how many consumers and systems you expect over time. Our MCP integration work is mostly for businesses who have decided AI will touch several systems and want the connection layer built once, properly, with permissions and auditing in place from the start.
Model Context Protocol: common questions
An open standard for connecting AI assistants to your tools and data through one consistent interface, instead of building bespoke plumbing per assistant and per system. You expose a system once and any MCP-capable assistant can use it, within the permissions you define.
No. It usually sits in front of APIs you already have, presenting them in a form an AI assistant can discover and use at run time. That means exposing a system over MCP is often a smaller piece of work than expected, because the underlying integration already exists.
It can be, because the server side is yours. Your code decides what data and actions are on offer, enforces permissions and writes the audit log, rather than trusting a prompt. That makes it a reasonable foundation for guardrails, though the usual controls still have to be built.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.