MCP and the end of the integration project

Yes, when the platform underneath already publishes live domain events. Put a public API over that event stream and one MCP server over the API, and every consumer that used to need its own project - a BI tool, a revenue-growth-management model, an AI agent - connects with a key and reads real state. No nightly export, no bespoke feed, no reconciliation job. The integration project does not get smaller; it stops being a category of work.

Why did the integration project never end?

Because every time someone wanted data out of a route-to-market estate, it became a scoped project. Extract from the order system, transform to the warehouse's shape, schedule the job, reconcile the numbers, hand the analyst last night's snapshot. Want a new view? Another project. That is the M-by-N tax: M tools times N systems, each pairing a hand-built feed that someone owns forever. And you rent the middleware that carries those feeds by throughput. Per integrate.io's pricing analysis, MuleSoft lists from roughly $1,250 per vCore per month as of early 2026, with one documented Platinum arrangement at $210,000 a year for four vCores and a Forrester composite for a $7.5B organization near $600,000 a year in license alone. At brewer scale the count is not small: one of the world's largest brewers has publicly documented connecting more than 4,500 business-critical applications. None of that spend produces an insight. It moves data between systems that already hold it, on a delay - and the delay is where the BI backlog lives.

What does an MCP server over a public API actually change?

One event stream feeds three faces from the same source of truth: the operational API, the analytics warehouse, and an MCP server. Because they read the same events, none of them is a copy that can drift. MCP - the Model Context Protocol - is a standard way to expose tools and data to AI systems; per the official specification at modelcontextprotocol.io, a server advertises its capabilities so any compliant client can discover and call them with no bespoke integration. Anthropic, which published the protocol in November 2024, describes it as

a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol.

Put that server over a public API on live events and each consumer changes character. An analyst's tool queries current state, not last night's export. An RGM model reads live prices and volumes and writes its recommendation back through a typed command instead of a spreadsheet round-trip. An agent can draft a task, estimate the blast radius against real downstream state, and execute it. That last capability is the one the market actually pays for - Anthropic reported its own agentic coding tool at over $500 million in run-rate revenue as of September 2025, and it works because it operates on a whole coherent system rather than one file at a time. What every one of these consumers stops needing is a project. They authenticate, discover the tools, and act. This is the same event-native shape our suite runs on, which is why the shift is not theoretical to us.

How do you get to a platform that plugs in with a key?

This is a build order, not a big-bang switch, and it has a fairly reliable sequence.

1. Events first, on one bus. Nothing downstream is legible until state changes are facts on a shared stream - order placed, stock reserved, empty returned, delivery confirmed. This is the substrate, argued at length in one event bus versus a middleware translation chain, and every later step reads from it.
2. One public API over the stream, not a feed per consumer. Expose typed read models and typed commands. The API is the contract; there is deliberately no second, private one that a favoured integration gets to use.
3. An MCP server that wraps the API. Its tools map to the same read models and commands you already published. You are exposing what exists, not rebuilding it - the server is a thin adapter, not a new system.
4. Keys and scopes as the front door. A read-only analytics key, a scoped RGM key that may write recommendations but not orders, an agent key with named permissions. Authorization stops being paperwork and becomes the safety envelope.
5. Point analytics and RGM at the API, then delete the export job. Do not build another pipeline beside the old one. Strangle the existing exports one consumer at a time, the same way we replace a commerce stack while it keeps running.
6. Leave SAP where it is. The financial core consumes the events it needs and remains the system of financial record. It is not something an agent writes to; the MCP server exposes the route-to-market platform around it, not the ledger itself.

What does this not give you for free?

The hard part is not adopting a protocol. It is that a key which reads live state can also act on it. The moment an agent or model connects, your authorization model, rate limits and audit trail are the only thing standing between a useful tool and an expensive mistake - so they have to be real: scoped tokens, per-tool permissions, and every call landing in the same event log as a human action. The standard is also young and still moving; the specification has revised more than once since November 2024, so you build against a shifting target and keep the MCP layer thin enough to follow it without a rewrite. And a server over a fragmented stack inherits the fragmentation. If the events underneath are not consistent and typed, the agent still sees six private data models behind a nicer door. The protocol standardizes access; it will not standardize your domain for you. That work - retrofitting clean, typed events onto systems that never emitted them - is most of the bill, and it is worth pricing honestly before anyone promises a demo.

The interesting question for the rest of 2026 is not whether to adopt MCP; the protocol will be table stakes long before the year is out. It is whether your route-to-market platform emits state clean enough for a key to be a real front door - consistent events, a public API, invariants an agent cannot unknowingly violate. Brewers who make that true this year will add the next analytics tool, RGM model or agent as a configuration change; the ones still renting integration by the vCore will be scheduling exports and explaining the backlog. That gap, more than any model benchmark, is what a serious build-versus-buy decision should be weighing now.