Your Copilot is not moving the P&L but a well built MCP server can.
Three design principles for MCP servers that write into business systems, and why most of the work is not in the server.
Most large companies have an AI assistant deployed by now. Licences signed, rollout finished, adoption looks fine on the dashboard. Then the CFO asks what changed, and the honest answer is that emails get drafted faster, slides come out quicker, meeting notes write themselves.
None of that reaches the P&L. Eleven minutes saved on a draft is not a cost line anyone gets to remove, and once you multiply the licence by ten thousand seats the business case starts to look thin. The value was never going to come out of the text box.
It sits in the processes that run between systems, and those are exactly the ones a read only assistant cannot touch.
Read only is a better search bar. Write access is automation.
Read only MCP servers are useful. They let an assistant answer questions against live data instead of guessing, which beats waiting for a report. But that is still retrieval.
Things change when the agent is allowed to write.
Take onboarding. HR system, directory, ERP, ticketing tool, three access groups, a checklist, several days of elapsed time. With write capable MCP servers behind those systems it becomes one instruction and a few seconds.
Or a purchase requisition in SAP. You need to know the transaction, the fields that matter, and the one that will silently block the release strategy. That is why requisitions end up with the two people in the department who understand it. An agent driving a decent MCP server makes that knowledge irrelevant.
This is process automation, done in weeks, without an RPA programme and without a screen scraping layer that breaks on the next release.
That is where the money is, but there are two conditions to make that happen in a way that’s safe: the MCP server needs to be well built and its business application needs to be able to handle it.
1. Authentication through SSO, not a static token
Everyone starts with a service account and an API key sitting in a config file. It works on day one and falls apart on day two, when someone asks who made a change and the only available answer is the service account.
The server has to authenticate the person behind the agent and inherit their permissions exactly. If the user could not have done it in the UI, the agent cannot do it either, and every write carries a name.
Which means the application itself needs SSO and a real role model behind it. That part gets underestimated. If your app still runs on local accounts and a single admin flag, the MCP work starts there, not in the server.
2. Dry run before anything is written
Every mutating tool has a preview mode. What would change, how many objects, which fields and relations, what gets created against what gets updated, all returned before a single row is touched.
The human gets a decision point in plain language. The model gets a cheap way to check its own plan against reality. Most of the mistakes I have seen were caught at that stage rather than in production.
3. Batches that are both the audit trail and the undo button
Every write happens inside a mutation batch that records who, which tool, what payload, when, and what actually changed. And because a batch is a single unit, it can be reversed as one, with a call that puts everything back the way it was.
I would not build those two things separately anymore. Traceability and reversibility come out of the same structure.
The audit side is not just a change log. One instruction in natural language can produce two hundred individual changes, and they only make sense read together as one action. When someone asks what the AI did last quarter, that should be one query rather than an investigation.
The risk side is what unblocks the conversation with security. Without an undo you are being asked to guarantee the agent never gets anything wrong, which nobody can promise. With one, the question becomes how fast you can put it back, and that question has an answer.
The part nobody talks about: the business application has to change as well
Exposing the tools was the easy part, the server itself took a few hours since everything is already API event driven.
What took much longer was everything inside the application: Mutation batches, Rollback mechanisms, dry run semantics on every mutating operation. A permission model tight enough to hold up at machine speed. Errors structured well enough that a model can act on them instead of getting a 500 and a stack trace.
MCP is not something you bolt onto a product. It is a requirement on how the product is built.
What this means if you own the application landscape
The question to ask about each core application in your portfolio is not whether the vendor has announced an MCP server. It is:
- Can it authenticate the human behind the agent and enforce that person’s permissions?
- Can it show what will happen before it happens?
- Does it record machine driven changes as reviewable units, and can those units be reversed?
Where the answer is no, that is your backlog. Where it is yes, you get something no copilot licence has delivered so far: business processes that run in seconds, with an audit trail, with an undo, and with a number your CFO recognises.
Turbo EA is self hosted and the implementation is open, so all of this can be inspected rather than taken on trust.
Vincent Verdet is an Enterprise Architect and the creator of Turbo EA, a self hosted Enterprise Architecture Management platform. turbo-ea.org
Originally published on LinkedIn on August 31, 2026.