MCP standardises how an agent reaches a tool server. It says nothing about what that server integrates with. Compare the tempting shortcut against the pattern that actually works.
340 tool descriptions occupy the window before the agent reads a single instruction.
Choosing well among near-identical operations is a task models perform badly.
A field with values 01–47 is documented somewhere unmachine-readable, so the model fills the gap plausibly.
Everything those operations can do — for an ERP interface, close to unlimited.
Solved probabilistically, and differently each time.
Fast to build, expensive to operate.
Designed from the agent's task decomposition, not the legacy system's structure. Eleven tasks means roughly eleven capabilities — not 340 operations, and not one god-tool with a mode parameter.
Tribal knowledge encoded once, in code, reviewably — instead of re-guessed by a model on every call. The highest-value single thing the layer does.
Read capabilities split cleanly from write capabilities, so governance can differentiate: reads broadly available, writes gated.
Where the legacy interface cannot offer it, the layer implements a request key and deduplication window. This is what stops an agent retry double-posting a journal entry.
{
"STATUS": "17",
"DOCTYP": "RE",
"WAERS": "EUR"
}
{
"status": "awaiting_credit_approval",
"document_type": "invoice",
"currency": "EUR"
}
Do not hide the asynchrony behind a synchronous facade that blocks for four hours — or worse, polls internally and times out at ninety seconds.
The agent's workflow gains an explicit waiting state rather than a blocked tool call.
Often yes — then build a workflow with agentic steps, not a conversation. Sometimes no — and the honest finding is that this use case needs a change to the underlying system, surfaced in week two rather than month five.
Reads broadly, writes narrowly. Build the read surface across as many systems as you can reach — an agent that answers "what is the status of this order across our four systems" is genuinely useful and cannot damage anything. For state changes, route through whatever validated path the business already uses, and start with propose-and-approve rather than propose-and-execute.