MCP integration explained for business systems

MCP is a standard plug between AI systems and your tools, so you build a connector once instead of rebuilding it for every model and every assistant. It does not solve permissions, reliability, or the fact that a tool server is a privileged piece of infrastructure.

JarvisBitz

Before MCP, connecting an AI system to your CRM meant writing a bespoke integration for that model, that assistant, and that CRM. Change the model and you rewrote it. Add a second assistant and you wrote it again. Every combination was its own piece of work.

The Model Context Protocol standardises that connection. You expose your system once, in a defined shape, and any AI client that speaks the protocol can use it. That is the whole idea, and it is genuinely useful. It is also narrower than the marketing suggests, which is the part worth understanding before you plan around it.

The problem it actually solves

Integration work used to multiply. Five internal systems and three AI surfaces meant fifteen connectors to build and maintain, each with its own quirks and its own way of breaking. MCP turns that into five, one per system, reusable across every surface.

The practical consequences are worth being concrete about:

• You are less locked in. Switching the underlying model does not mean rewriting your integrations, which matters because models get deprecated roughly annually.
• Connectors get reused. The server you build for a support assistant also serves your internal tooling and any future agent.
• Capabilities are described, not hardcoded. The AI discovers what a system can do and what arguments it takes, rather than you scripting each call.

What it looks like in practice

You run a small service, an MCP server, that sits in front of a system you already have. It declares a set of tools: what each one does, what it needs, and what it returns. The AI client connects, reads that list, and can then call them during a task.

The important thing to notice is where the boundary sits. The server is yours. It runs in your environment, holds your credentials, and decides what is exposed. The model never gets your database password. It gets a menu of operations you chose to publish.

What MCP does not solve

Permissions

The protocol carries no opinion about who is allowed to do what. If your server exposes a refund tool, anything connected to it can call that tool. Scoping by user, enforcing limits, and deciding which actions need a human are your responsibility, and they sit in the server, not the protocol.

Reliability

A model calling a tool can call it twice. Networks fail mid write. If your operations are not idempotent, a retry becomes a duplicate refund or a second order. That was true before MCP and it stays true after.

Whether the underlying system is any good

MCP exposes what you have. If the data behind it is inconsistent or the API is slow, you now have a standard way to reach something that still does not work well. It is a plug, not an upgrade.

The security question most teams miss

A tool server is privileged infrastructure. It holds credentials and can act on real systems, so it deserves the same scrutiny as any other service with that reach. Two specifics are worth naming because they are new to a lot of teams:

• Tool results are untrusted input. If a tool returns content that came from outside your organisation, a support ticket, a scraped page, a customer email, that content can contain instructions aimed at the model. Treat anything a tool returns as data to be reasoned about, never as directions to follow.
• Third party servers inherit your access. Installing someone else's MCP server to reach a SaaS product means running their code against your credentials. Review it the way you would review any dependency with production access, and prefer ones you can read.

Neither of these is a reason to avoid MCP. They are reasons to treat a tool server as infrastructure rather than a configuration detail.

When to use MCP and when to skip it

For a single scripted call inside one workflow, a direct API integration is simpler and you should just write it. MCP earns its keep when the same capability needs to be available to more than one thing, or when you expect the AI layer underneath to change.

How to start without a large programme

Pick the one system your team touches most during the work you want to automate, usually the CRM, the ticketing system, or the order database. Expose a deliberately small set of operations from it: the three or four things people actually do. Put approval in front of anything that writes. Run it against one workflow, watch the traces, and expand only where the logs show a human is doing something repetitive.

That gets you a reusable asset in weeks rather than an integration programme, and the traces tell you what to build next instead of you guessing.

If you want to see which of your systems are worth connecting first, our free AI audit looks at your live setup, or read how we approach agents that use tools safely.

Related reading

LLM data residency: what to configure and what to verify

Residency is a configuration you set, not a property you inherit, and the defaults differ per vendor and change without notice. Establish four things in writing for each provider, then enforce the rest at your own gateway, because that is the only layer you control.

LLM spend: attribution before optimisation

You cannot cut what you cannot see. Most teams optimise models and prompts before they can attribute a single dollar to a team, feature or customer, which means they are guessing. Meter at the gateway first, then cache, route and cap in that order.

What to log in an LLM system so you can debug it later

A 200 response tells you almost nothing about an AI system, because the failure you care about is a confident wrong answer that returned successfully. Log the inputs, the retrieved context, every tool call and the guardrail outcomes, or you will be debugging from screenshots.