Sharing a Tool Is Not the Same Problem as Enforcing a Rule
A shared execution environment and an unenforced constraint look like the same kind of mess — moving the tool surface to MCP fixes both, but for two unrelated reasons, not one.
A multi-agent system runs into the same wall more than once: several agents need the same underlying tool capability. The obvious move is to let them run in the same execution environment, so they can all reach the same code without anyone maintaining two drifting copies of it. That move quietly creates two different problems, and it’s worth being precise that they’re different, because they don’t share a fix.
The setup
Two agents — one doing deep, open-ended investigation, one doing routine day-to-day retrieval — shared a single execution environment for exactly one reason: both needed the same toolset, and duplicating that code into two copies that could drift apart wasn’t worth the alternative.
Problem one: a shared environment shares more than the tool
The runtime running these agents auto-injects a set of context files into whatever environment an agent operates in — instructions, memory, project background. Sharing an environment meant sharing those too. One of the injected files opened with a line stating, in plain text, that it belonged to the other agent. Checked against a real run transcript, not inferred: the investigating agent had been reading context meant for the retrieval agent the entire time.
Problem two: a constraint only holds if the agent complies
Separately, the investigating agent’s safeguards — a budget ceiling, a circuit breaker on errors, a rule requiring every judgment call to state its reasoning and alternatives, a check that a task can’t be marked done without going through it — all lived in code the agent had to voluntarily invoke. In one real test, the agent spent a single-digit number of calls, then answered in chat directly, skipping every one of those steps. Not one safeguard fired, because none of them sat somewhere the agent couldn’t route around.
What was ruled out
Before changing anything, this pattern was checked against more than a dozen real multi-agent and skill-isolation setups. The shared-context pattern that does get recommended elsewhere is for agents meant to collaborate on one thread, reading the same conversation on purpose. That wasn’t this case: these two agents needed to stay unaware of each other’s work, not coordinate through it — and for that shape, nothing in what was checked suggested sharing an environment and relying on injected documentation to keep concerns apart was the right call. Writing clearer docs wasn’t a live option either way — the failure mode wasn’t unclear documentation, it was documentation as the only mechanism.
What MCP actually contributes — two unrelated reasons
Both fixes came from moving the tool surface onto MCP (the Model Context Protocol). It’s worth separating why, because it earns its keep here for two independent reasons, not one.
For problem one: an MCP server typically runs as its own process, separate from any single agent’s environment, registered once rather than owned by whichever agent’s directory happens to contain its code. Reaching it doesn’t require being inside that directory — it requires the host’s configuration to grant an agent access. That turns “which agents can use this tool” into a configuration grant the host makes once, per agent, instead of a question of whose directory the code physically sits in. Once that was true, splitting the two agents into separate, clean environments cost nothing extra.
For problem two: every MCP tool declares a formal input schema — required fields, types — sent to the client as the tool’s contract. The protocol requires the server to validate every incoming call against that same schema before processing it. The schema the agent is shown and the schema the server checks against are the same declared object, not a prose description in one place and validation code, if it exists at all, in another.
One adjacent choice mattered more than it looked: the interface was built as several narrow MCP tools, each with its own tight schema, rather than one broad tool with an optional mode parameter — the broad version would have let every field slide back to optional, buying nothing from having a schema at all.
The two axes don’t have to agree
Other parts of the same system never moved to MCP, and that was also correct. Problem one and problem two are independent: a system can have either, both, or neither. Only when both are true does MCP’s cost pay for itself.