MCP or a Custom Integration? How to Tell Which One You Actually Need

We build MCP servers for a living, so take this with the appropriate pinch of salt: MCP is not always the right answer. Perhaps a third of the time we look at a client system and recommend a plain integration instead. It is worth understanding where the line falls, because getting it wrong in either direction is expensive.

The Model Context Protocol describes, in a standard way, what capabilities a system exposes and how an AI client may invoke them. The immediate benefit is that any MCP-aware client can use your system without a bespoke connector being written for that specific client.

The benefit that matters more over time is different, and it is not really a technical one. Because every agent reaches your systems through the same described interface, the question "which agents can call what?" has one place to look. With bespoke point-to-point integrations, that question has as many answers as you have integrations, and they are scattered across whoever wrote each one.

So MCP earns its keep when you expect more than one agent, more than one system, or more than one team. If any of those will be true within a year, the standard interface pays for itself.

If you have exactly one workflow, hitting exactly one system, with no plan to add a second — build the integration. An MCP server in front of a single endpoint used by a single agent is architecture for its own sake, and you will maintain it forever for no return.

The same applies when the interaction is not really conversational. If the task is "every night at two, pull yesterday orders and push them into the warehouse system," that is a scheduled job. Putting an agent in the middle adds cost, latency and a class of failure you did not previously have. Not everything that touches AI needs to be agentic.

And if a good connector already exists for your stack and it does what you need, use it. We have talked clients out of building things that were already sitting in their vendor marketplace.

Count two numbers: how many distinct systems agents will need to reach, and how many distinct agents or assistants will exist. Multiply them. If the answer is one, build the integration. If it is two or three, it is a genuine judgement call and usually comes down to whether you expect that number to grow. Above three, standardise — you are heading for sprawl and it is cheaper to prevent it than to unwind it.

There is a second trigger that overrides the arithmetic entirely. If you operate in a regulated environment, the "which agent can reach what" question is going to be asked by someone who can stop you shipping. In that case standardise earlier than the numbers alone would suggest, because you are not buying convenience, you are buying an answer you can hand to a reviewer.

Point-to-point integrations do not fail loudly. They accumulate. Each one is a sensible local decision, and twelve months later nobody can produce a complete list of what talks to what, because the list only ever existed in the heads of the people who built each piece and two of them have left.

That is the cost we see most often and the one that never appears in the original estimate. It shows up as a slow tax on every subsequent change, and eventually as a project to work out what you already have. Standardising the access path is a way of paying that cost once, deliberately, at the point where it is still small.

If you are weighing this up for a specific system and want an honest answer rather than a sales one, get in touch. Sometimes the honest answer is that you do not need us yet.