When an incumbent plans an MCP server, the work gets scoped as an integration project: which capabilities to expose, what the schema looks like, how authentication works, what the rate limits are. All necessary, and all beside the point. The consequential changes are not in the integration plan, because they are not technical. Six things dissolve when your product becomes callable, and most roadmaps account for none of them.

One: the interface stops being the way in

The obvious one, and still underestimated. Your screen was not just a way to reach the capability; it was where the work happened, which meant it accumulated everything around the work — the habits, the training, the internal documentation, the org chart of who does what in which tab. A tool call reaches the capability without any of that. The first time a meaningful share of your usage arrives through the server rather than the front door, the interface investment stops compounding and starts depreciating.

Two: the context migrates to the harness

This is the one that decides the long game. Your product held context: what this customer did last quarter, their configuration, their preferences, the history that made your software feel tailored. In an agent workflow, the durable context accumulates one level up — in the harness, which sees not just your tool but every tool, and therefore holds a picture of the work that no single product can match.

Context is what lock-in is actually made of. When it relocates, switching away from you gets easier at exactly the moment switching away from the harness gets harder. You did not lose the data. You lost the position of being the only thing that understood it in context.

Three: your telemetry degrades to tool calls

Nobody budgets for this one and it is expensive. Product organisations improve by watching intent: where people hesitate, what they search for and fail to find, the sequence that reveals what they were actually trying to do. A tool call gives you none of that. You see a function name, some arguments, and a result.

The intent — the goal the agent decomposed into this call — stayed in the harness. So the signal that drove your roadmap thins out precisely as the surface you are being judged on widens. You are being used more and understanding it less.

Four: the pricing model stops matching reality

Per-seat pricing assumes a person, a login, and a rough proportionality between people and value. An agent calling your server is not a seat, and one agent can carry the work of many logins. The arithmetic moves in the buyer’s favour immediately, and your revenue detaches from the value you deliver at the very moment your delivered volume goes up.

This is the seat-based fault line arriving through a new door. It is also the most fixable item on this list, which is why it belongs on the near-term roadmap rather than the strategy offsite.

Five: substitution becomes a configuration change

Protocols exist to make components interchangeable. That is the feature. It is also what removes the friction that used to protect you — the migration project, the retraining, the integration rebuild. When a competitor exposes a comparable schema, replacing you is a change of endpoint, tried on a Tuesday, reversible if it goes badly.

Whatever switching cost you had that lived in familiarity and habit does not survive this. The only switching costs that do are the ones made of things a schema cannot carry: the record itself, the accumulated data, the regulatory position, the network.

Six: you get disintermediated from the outcome

The buyer increasingly pays for a result rather than for software. In an agent workflow, the thing that delivers the result is the harness — it holds the goal, sequences the tools, and reports the outcome. You supply a step. Which means the value conversation, the renewal conversation and the pricing conversation all happen at a layer you are not in.

Being a dependable component of someone else’s outcome is a real business. It is a smaller and more replaceable one than owning the outcome, and the transition often happens without anyone deciding it.

The order matters

These do not arrive together. The interface goes first and is the most visible, which is why it absorbs the anxiety. The pricing break follows and is loud, because it shows up in revenue. Context migration and telemetry loss are slow and quiet, which is what makes them dangerous — by the time they are measurable, several years of compounding have gone to somebody else.

The useful reframing is that only two of these are really about MCP. The other four were always the shape of the business, and the protocol just removed the interface that was hiding them. Which is the question the next post takes up: how to tell, before the market tells you, whether being called makes you bigger or makes you a commodity.


When Your Product Becomes a Tool — a five-part series on MCP and incumbent strategy

  1. When Your Product Becomes a Tool
  2. What Dissolves When You Become Callable — you are here
  3. Substrate or Façade — Who Survives Being Called
  4. The Incumbent’s Playbook for an MCP World
  5. Buying in an MCP World

Related: Buy, Build, or Orchestrate — and Why Seat-Based Pricing Is the Fault Line · The Frontier Labs Are in the Squeezed Middle of Their Own Stack.


Discover more from Digital Reflections

Subscribe to get the latest posts sent to your email.

Leave a Reply

The Blog

At the intersection of data, AI, and imagination lies the path to transformation. Our greatest evolutions occur when we use technology not just to improve what is, but to reimagine what could be.

Discover more from Digital Reflections

Subscribe now to keep reading and get access to the full archive.

Continue reading

Discover more from Digital Reflections

Subscribe now to keep reading and get access to the full archive.

Continue reading