MCP explained: giving AI assistants safe access to your systems
An assistant that can only talk is a demo. One that can read your data and take actions is a product — and that connection is now standardised.
Every AI project reaches the same wall. The assistant is articulate, helpful and completely disconnected from the systems where the actual work lives — the CRM, the order database, the ticketing system, the document store. It can talk about your business; it cannot touch it.
The traditional answer was custom integrations: bespoke glue between each assistant and each system. With four assistants and six systems, that is twenty-four pieces of code to build and maintain, and every new tool multiplies the problem.
What MCP actually is
The Model Context Protocol is an open standard for that connection. A server exposes capabilities — tools the assistant can call, resources it can read — behind a common interface. A client (the assistant, the IDE, the agent platform) speaks that same interface to any server.
The result is the shift that made it spread: N × M becomes N + M. Write one MCP server for your internal system and every compatible client can use it. Adopt a client and it immediately works with every server anyone has published.
The analogy that has stuck is a universal port. Before, every device needed its own cable; now there is one connector, and the interesting work moves to what you plug in.
Why it matters commercially
Strip away the protocol detail and the value is simple: it is the difference between an assistant that describes work and one that does it.
- "What is the status of order 4471?" — answered from your real order system, not a stale export.
- "Draft a reply to this support ticket using our documentation" — grounded in the actual docs, with the ticket in context.
- "Which of last quarter's leads never got a follow-up?" — a genuine query against your CRM.
- "Create the project, add the standard tasks and assign the owners" — actions taken, not instructions produced.
That is also where the risk arrives, and the two are inseparable: an assistant that can take actions can take wrong ones.
The security model is the design work
This is the part that separates a demo from something you would let near production data. Four rules we do not bend:
1. Least privilege, always. The credential behind a server should permit exactly what the use case needs and nothing more. A read-only reporting assistant gets a read-only credential. The blast radius of an agent behaving unexpectedly is exactly the scope of the access you granted it.
2. The model should never see the credential. Secrets belong in a vault or a proxy layer that attaches them to outbound requests after they leave the model's reach. If an API key is sitting in the prompt or in the agent's environment, then anything that can influence that context — including content the assistant reads from an untrusted source — is a potential exfiltration path.
3. Human approval for anything hard to reverse. Reads can run freely. Sending the email, issuing the refund, deleting the record, pushing to production — those get an approval step, and that step is enforced by your system, not requested politely in a prompt.
4. Audit everything. Every tool call, with inputs, actor and timestamp. When someone asks in three months why a record changed, "the AI did it" is not an answer.
There is one failure mode worth naming explicitly: prompt injection through data. If an assistant reads a support ticket, a web page or a document, whatever is written there enters its context — and might be phrased as an instruction. The mitigation is architectural rather than conversational: constrain what the tools can do, and gate the consequential ones behind approval. Never rely on telling the model to ignore malicious instructions.
When you do not need it
MCP is infrastructure, and infrastructure has a cost. For one assistant talking to one system with one fixed capability, a direct integration is simpler and you should just build it.
It earns its keep when the numbers grow: several systems, several clients, capabilities you expect to expand, or a desire to reuse the same connection across your product, your internal tooling and your team's coding assistants. That is when standardisation stops being overhead and starts being leverage.
What we build with it
Most of what clients want falls into three shapes: an internal assistant with genuine access to company systems, a customer-facing assistant that can look things up and take safe actions on the user's behalf, and connecting existing agent tooling to proprietary internal data. Underneath all three, the interesting engineering is the same — the permission model, the audit trail and the approval gates. The protocol is the easy part.
Frequently asked questions
What is MCP (Model Context Protocol)?
MCP is an open standard for connecting AI assistants to external tools and data. A server exposes capabilities — callable tools and readable resources — behind a common interface, and any compatible client can use them. It turns an N-by-M integration problem into N plus M.
Why would a business want an MCP integration?
Because it is the difference between an assistant that talks about your business and one that works in it — reading real records, answering from live systems and taking actions like creating a project or drafting a grounded reply. Most of the practical value in business AI comes from that connection, not from the conversation.
Is it safe to give an AI assistant access to internal systems?
It is, with the right architecture: credentials scoped to least privilege, secrets held outside anything the model can read, human approval required for actions that are hard to reverse, and a full audit trail of every tool call. Treat the security model as the main design work rather than an afterthought.
What is prompt injection and how do you defend against it?
Prompt injection is when instructions hidden in content the assistant reads — a ticket, a web page, a document — get treated as commands. The reliable defences are architectural: limit what the tools can actually do, require approval for consequential actions, and never depend on instructing the model to ignore malicious text.
Do we need MCP for a single integration?
Usually not. For one assistant, one system and one fixed capability, a direct integration is simpler. MCP pays off once you have several systems or several clients, expect the capability set to grow, or want to reuse one connection across your product and internal tooling.
Keep exploring
Enjoyed this? We build the things we write about.
From first sketch to scaled platform — let's talk about your project.
Start a project
