Agency17 June 20264 min read

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

We exposed our whole back office as MCP: 13 servers, 222 tools

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.

What does "expose an ERP as MCP" actually mean?#

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.

Why one server per domain?#

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.

| 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.

The three rules that keep 222 tools safe#

A surface this size is only as good as the discipline that is identical across every tool.

1. One uniform envelope#

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.

2. Tools loaded by role#

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. This is lazy loading as a security boundary, not just a context-saving trick: the menu itself is scoped to the caller.

3. A JWT minted per principal#

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.

Notice the pattern under all three: never trust the agent to enforce a rule the system can guarantee. The envelope guarantees honesty, role-loading guarantees scope, the per-principal JWT guarantees identity. The agent gets to choose; it never gets to bypass.

Demo MCP vs production MCP#

The gap between a single MCP server and an agent-ready back office is the whole job.

| 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.

What this means for your team#

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.

Common questions

What does it mean to expose an ERP as MCP?

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.

Want this running on your team?

Talk to us about your team