One MCP layer instead of 500 integrations
When every AI client wants to talk to every engineering tool, the integration count grows as a product, not a sum. The arithmetic behind why I put one MCP layer in front of an enterprise engineering tool estate.
In my last role I ran a global engineering application estate used by engineers around the world, covering requirements, architecture, CAD, CAE, test and product line engineering.
When AI assistants arrived, the requests started immediately. The coding assistant should see the requirements. The chat assistant should open a test report. The new agent platform should query the PLM system. Each request was reasonable on its own. Together they were a trap.
The arithmetic
If every AI client integrates with every tool directly, the work grows as a product. If both sides connect to one shared layer, it grows as a sum. Take a round 100 engineering tools, which is modest for a large manufacturer.
| AI clients | Engineering tools | Point to point (clients × tools) | One MCP layer (clients + tools) |
|---|---|---|---|
| 1 | 100 | 100 | 101 |
| 3 | 100 | 300 | 103 |
| 5 | 100 | 500 | 105 |
| 10 | 100 | 1,000 | 110 |
With one client the two approaches cost the same. By the fifth client, point to point means 500 separate integrations to build, secure and keep alive through every tool upgrade. Five AI clients is not a forecast, by the way. Most large companies already have that many, if you count the chat assistant, the coding assistant, an agent platform, analytics copilots and whatever the business units have built.
Figure 1. Left: five clients and seven tools wired directly, 35 connections. Right: the same clients and tools through one layer, 12 connections.
Why MCP and not another integration bus
We have had integration buses for twenty years. The difference with the Model Context Protocol is who the consumer is. MCP describes tools in a way a language model can read and decide to use: a name, a description, typed inputs. The model picks the tool. That makes the description itself part of the interface, and it changes what “integration done” means.
A connector that technically works but describes its tools badly will be called at the wrong time, with the wrong arguments, by every agent that uses it. Write the description once, well, in the shared layer, and every client benefits.
What the layer has to do
The protocol is the easy part. These are the responsibilities that make a shared layer worth having, and they are the same list I would hand to any team building one:
| Responsibility | Why it belongs in the shared layer |
|---|---|
| Act as the user, not as a service account | The agent should see exactly what the engineer could see, no more |
| One good description per tool | Tool choice by the model depends on it; fix it once for every client |
| Log every call | Who asked, which tool, what came back. This is the audit trail and the usage data |
| Rate limits and quotas | One misbehaving agent should not take down a licence server |
| Read before write | Start with read-only tools; add write actions one at a time, with confirmation |
| Version alongside the tool | When the tool upgrades, one connector changes, not fifteen |
Where the effort really goes
If you plan a layer like this, budget for these, roughly in this order.
Identity. Engineering tools have their own permission models, often per project and per programme. Making an agent act with the engineer’s own rights, and nothing more, is harder than writing any connector.
Descriptions. A tool the model misunderstands gets called at the wrong moment. Treat each description like an API contract and review it like code.
Evidence. Once every AI call to a tool passes through one place, you can see which tools people actually want AI help with and which they never touch. That is better input for the next investment than a survey.
Vendors. The ask to each tool vendor gets simpler. Not “build us your own assistant”, but “expose your tool through MCP”.
If you are about to approve the third separate “connect AI to tool X” project, stop and count the clients. The second number in the table arrives faster than you think.