We exposed our whole back office as MCP: 13 servers, 222 tools
Making a real ERP usable by AI agents isn't an integration project. It's a contract. We exposed a fiduciary back office as 13 MCP servers and 222 tools, one server per domain, one uniform envelope, per-principal auth. Here's the shape that holds.
tsukumo
The short answer
Making a real back office usable by AI agents is not an integration project, it is a contract. We exposed a Swiss fiduciary's ERP as 13 MCP servers and 222 tools: one server per business domain, every tool returning the same {status, data, error} envelope, tools loaded by role so an agent only sees what it may use, and a JWT minted per principal so every call carries who is asking. The discipline is the same as running a microservice fleet, not wiring one demo server.
Short version: making a real ERP usable by AI agents is not an integration project, it is a contract. We exposed a Swiss fiduciary's back office as 13 MCP servers and 222 tools, and the thing that made it work was not the count, it was the discipline: one server per domain, one uniform response envelope, tools loaded by role, and a JWT minted per principal so every call carries who is asking. Wire one demo MCP server and it feels easy. Make a whole back office agent-ready and it is a fleet-of-services problem with all the rigor that implies.
It means giving agents a typed menu of capabilities, not a stack of API docs.
The naive way to let an agent use your systems is to hand it your REST documentation and let it figure out which calls to chain. That works in a demo and falls apart in production, because the agent re-derives the integration every time and gets it subtly wrong. MCP flips it: each operation becomes a declared tool with a typed signature the agent discovers and calls directly. The agent stops guessing how your API works and starts choosing from a menu you control.
The unit of work is the tool, not the endpoint. An endpoint is documentation an agent has to interpret. A tool is a capability it can invoke. The whole job is turning the first into the second, safely.
Because a back office is not one system, and pretending it is makes everything worse.
We split the surface the same way you would split a monolith into services: one MCP server per business domain. That gives each surface three properties that matter at scale.
What per-domain servers buy you
Property
Why it matters for agents
Small, focused tool list
A model reasons worse when handed hundreds of irrelevant tools. Per-domain servers keep each menu short.
Separately deployable
A change to invoicing tools never risks the payroll surface.
Separately permissioned
Access is granted per domain, so a principal can reach documents without reaching payments.
Thirteen servers, not one. The total is 222 tools across all of them, but no single agent ever reasons over 222 at once, which is the point of splitting.
Prefer this built rather than figured out? That's the studio: we ship it on the same fleets we'd hand your team.
Every tool, in every server, returns the same shape: { status, data, error }. Never a bare value, never a thrown stack trace the agent has to interpret. A failure is an explicit status the agent can branch on, never something that looks like success. This is the single most important rule, because it is what stops a silent failure from reaching the agent dressed as data.
An agent is handed only the tools its principal is allowed to use. A bookkeeping agent does not see payment-execution tools; it cannot call what it was never given. People reach for lazy loading to save context. Here it does double duty as a security boundary: the menu itself is scoped to the caller.
Every tool call carries a JWT minted for the specific principal on whose behalf the agent is acting. Not a shared service key, a per-principal token. So every call is attributable and auditable, and access is enforced below the tool rather than by trusting the agent to stay in bounds.
The gap between a single MCP server and an agent-ready back office is the whole job.
Demo MCP vs production MCP
One demo server
A back-office fleet
One surface, a handful of tools
One server per domain, hundreds of tools total
Returns raw values
Uniform {status, data, error} everywhere
One shared key
A JWT minted per principal, per call
Every tool visible
Tools loaded by role and domain
Impressive in a video
Auditable, permissioned, deployable
MCP is having its moment, and most of what you see is the left column. The right column is what it takes to let an agent operate a real business system without it becoming the most over-privileged client you have ever shipped.
If you want agents to operate your back office, start by deciding the contract, not the integration. One server per domain. One envelope every tool obeys. Tools scoped to the caller. An identity on every call. Get those right and adding the next 50 tools is routine; get them wrong and every new tool is a new way to leak or to fail silently.
We learned this exposing a real fiduciary back office, where an over-privileged or dishonest tool is not a bug, it is an incident. If your team is trying to make its systems agent-ready without losing control of them, that's the work we do.
We map your domains, the contract every tool obeys, and where the identity boundary has to sit before any agent touches production.
Want your back office agent-ready without losing control of it?
MCP (Model Context Protocol) lets an AI agent discover and call tools through a standard interface. Exposing an ERP as MCP means wrapping its operations as MCP tools an agent can call directly, instead of handing the agent raw API docs and hoping it composes the calls correctly. The agent sees a typed menu of capabilities, scoped to who it is acting for.
Why one MCP server per domain instead of one big server?
The same reason you split a monolith into services. One server per domain (invoicing, payroll, documents, and so on) keeps each surface small, separately deployable, and separately permissioned. It also keeps the tool list an agent loads short and relevant, which matters because a model reasons worse when handed hundreds of irrelevant tools at once.
How do you secure 222 agent-callable tools?
Three layers. A uniform response envelope so failures are explicit and never look like success. Role-based loading so an agent is only handed the tools its principal is allowed to use. And a JWT minted per principal so every single tool call carries a verifiable identity, scoped and auditable, rather than a shared god-key.
Isn't 222 tools too many for an AI agent to handle?
It would be if every agent saw all 222. They don't. Tools are loaded lazily by role and domain, so any given agent sees a small, relevant subset. The 222 is the total surface of the back office, not the menu any one agent reasons over at once.
