Market & StrategyPE Operations

MCP and B2B Software Business Models: What Changes for Private Equity

Q: How do you review a SaaS target for agent readiness?

Four concrete review items for the next six months. Map the capability inventory. Which capabilities does the business actually expose? Not the feature list from the marketing one-pager. The list of capabilities that an external agent could consume today. How mature is the data model, how clean are output types, where

Dr. Oliver Gausmann · April 21, 2026 · 10 min read

Abstract network of connected nodes illustrating MCP and B2B software business models

Impulse

A few days ago I watched the livestream of AI Engineer Europe 2026 in London. David Soria Parra, co-creator of the Model Context Protocol at Anthropic, delivered the keynote on the future of MCP. Many of the points he raised felt familiar. My 2008 doctoral work at the University of Augsburg was on situational value networks and interorganisational information exchange ^[8]. The questions Parra raises for 2026 connect to debates the information systems community has been having for close to twenty years. For B2B software business models and private equity valuations, the talk carries concrete implications.

Executive Summary

The talk gives a snapshot of where the Model Context Protocol stands in April 2026 and what ships by June. 110 million SDK downloads per month, neutral governance since December 2025 under the Linux Foundation with Anthropic, OpenAI, Google, Microsoft, and Block as founding members ^[5]^[10]. For investors and executives whose B2B software business models will come under pressure in the coming quarters, three shifts are worth watching. The primary consumer of enterprise software is moving from the human at a screen to an agent calling capabilities over a protocol ^[4]. The distinction between software that bolts an MCP server on top of a legacy stack and software built from the ground up for agent consumption will start to drive exit valuations from 2027. And pricing architectures are opening up because pure seat pricing has become structurally incompatible with agent usage.

How mature is the MCP ecosystem today?

Parra laid out the 18-month journey in concrete milestones. The core specification was open sourced in November 2024. Remote server capabilities followed in March 2025, authorization in June, elicitation primitives in September, asynchronous tasks in December. MCP Applications, the primitive for server-driven UI, shipped in Q1 2026 ^[5]. The cumulative result is a stack that goes well beyond local tool invocation and now covers secure remote connections, enterprise authentication, and long-running asynchronous workflows.

The adoption number carries weight because it comes from organisations under no obligation to adopt. The 110 million monthly SDK downloads cut across Claude clients, the OpenAI Agents SDK, Google's ADK, LangChain, and thousands of smaller frameworks ^[5]. React took roughly twice the time to reach the same download level. Parra drew the comparison deliberately.

The governance shift from December 2025 is the second element PE sponsors should be aware of. The Agentic AI Foundation was formed under the Linux Foundation together with Block's Goose project ^[10]. Parra chairs its technical committee. For procurement teams and investors, the fact that a protocol exists matters less than who governs it. A protocol owned by one lab creates dependency. A protocol under a neutral foundation with Anthropic, OpenAI, Google, Microsoft, and Block among the founding members is infrastructure. The closest parallel, which Parra didn't draw himself, is Kubernetes. A technology born inside one company, handed to a neutral body, then adopted across competitors.

The protocol landscape is not a monoculture. Google published A2A in April 2025, a standard for direct agent-to-agent collaboration ^[11]. ACP and ANP are discussed in academic and open-source circles as alternative approaches. MCP itself added an async task primitive in December 2025 that reaches into A2A territory. The boundaries will stay contested for the next 12 to 18 months. For practical purposes, the current picture is straightforward. MCP is the dominant protocol today, and the new governance structure makes it hard for any single lab to destabilise it.

Three observations from the talk

The first extended point Parra makes concerns the composition of the connectivity stack. He describes skills as reusable domain knowledge captured in simple files, MCP as a protocol for semantics and governance-capable interaction, and CLI or computer use as tooling for local sandbox scenarios. His statement: the best agents use all three depending on context ^[5]. That's a pushback against vendor pitches that try to sell a single approach as a complete solution.

The second point is about two client-side patterns he expects to become economically material in 2026. Progressive discovery means the agent no longer loads every available tool into its context window. Instead it pulls tools on demand through a tool search mechanism. Parra shows Claude Code before and after integration, and the reduction in token consumption is substantial ^[5]. The second pattern is programmatic tool calling. The agent receives a code execution environment and composes tool invocations as scripts, instead of executing each call as a separate inference step. Latency and cost drop, composition becomes richer. For software vendors, the implication is that servers with structured output and composable tools fit better into the usage patterns that are consolidating now. Flat REST wrappers fit worse.

The third block covers concrete deliverables for June 2026. A stateless transport protocol originating in a Google proposal that makes MCP servers deployable on standard hyperscaler infrastructure ^[5]. Cross-app access, which lets enterprise users sign in once with their corporate identity provider and gain access to every connected MCP server. Server discovery over well-known URLs so that crawlers, browsers, and agents can automatically detect whether a site exposes an MCP server. And the extension Parra himself flagged as important, skills over MCP, where server authors ship domain knowledge as skills alongside their server and can update it continuously without waiting for clients to catch up.

The line from the talk that stayed with me afterwards came almost in passing. Parra said of REST-to-MCP conversion tools: „Every time I see someone building another REST to MCP conversion tool, it's a bit cringe. It just results in horrible things. Design for agents" ^[5]. That isn't a style comment. It's a product architecture statement, and it marks the fault line along which B2B software valuations will diverge over the next two years.

David Soria Parra, The Future of MCP, keynote at AI Engineer Europe 2026 in London, approx. 40 minutes. Source: AI Engineer YouTube channel.

Why is value creation shifting away from the frontend?

The classical B2B software business rests on two value layers. A frontend that structures the daily work of sales reps, analysts, and service teams, and a data and workflow layer behind it that encodes the processes. Seat pricing is the economic translation of that logic. Each human who opens the interface each day pays a licence.

When the primary consumer of that interface becomes an agent calling capabilities through a protocol, two things happen at the same time. The moat around the frontend erodes, because an agent needs no UX training, no onboarding, no change management. And the number of paying human seats per customer drops, because one agent can cover the work of several users.

Gartner has given this a trajectory. By 2028, AI agents rather than human developers will consume the bulk of enterprise APIs ^[4]. Over the same period, one third of user experiences will shift from native applications to „agentic front ends". These are top strategic predictions, not edge forecasts.

The market reaction has already shown up in prices. On 24 February 2026, Anthropic launched Claude Cowork, a demonstration of sustained autonomous knowledge worker workflows. In the 48 hours that followed, the SaaS sector lost 285 billion dollars in market capitalisation ^[1]. The financial press labelled it the SaaSpocalypse. The operational signals arrived in the same quarter. Atlassian reported its first ever decline in enterprise seat counts. Workday cut 8.5 percent of its own workforce, citing AI productivity. Monday.com replaced 100 sales development roles with agents ^[7].

Pricing experiments are running in parallel along several tracks. Intercom Fin charges 0.99 USD per resolved ticket, which is an outcome model. Salesforce Agentforce charges either 2 USD per conversation or 0.10 USD per standard action, staying in an action model ^[7]. The „agent-as-employee" model positions an AI SDR at around 2,000 USD per month as a functional substitute for a 90,000 USD human role ^[6]. The common direction is away from the human seat as the paying unit.

A quick „outcome pricing wins" narrative is too neat for the operational picture, though. Enterprise deals that are being signed now price along multiple layers. A platform base fee covers access, data, and governance. Capability credits sit on top for individual agent actions. An outcome component is added where the outcome can be cleanly measured. Vendors that commit to a single dimension risk either cash flow erosion or a growth ceiling. Deloitte expects at least 40 percent of enterprise SaaS spend to move to usage-, agent-, or outcome-based models by 2030 ^[3].

Agent-native and agent-wrapped as a new divide

Parra's comment on REST-to-MCP wrappers is not a stylistic aside. It describes two starting positions that B2B software vendors can take today, and those two positions translate directly into valuation.

Agent-wrapped software starts from a legacy data model, an existing REST API, and a human-oriented frontend. An MCP server is added on top as an additional surface. The capabilities were designed for human developers writing integrations against the REST API. The MCP server translates. Agents end up parsing verbose outputs, orchestrating multiple calls for a single task, and handling unstructured responses. It works. It's expensive and slow.

Agent-native software is built for agent consumption. The data model exposes structured capabilities with typed outputs. Progressive discovery is implemented. Skills over MCP ships alongside. Governance, authorization, and observability are designed for autonomous workflows rather than patched in after the fact. Agents reach the same outcome with fewer calls, lower latency, lower token cost, and better reliability.

Bain's Technology Report 2025 presents a twelve-indicator matrix that classifies SaaS workflows by replication risk. Two indicators are directly relevant here: agent protocol maturity and external observability. Workflows scoring high on both are easiest for agentic systems to replicate. Bain labels this category „spending compresses". Third-party agents hook into exposed APIs and pull usage and margin away. The report names HubSpot list building and task boards in project management tools as examples ^[2].

The counterpart category in Bain's matrix is „AI outshines SaaS". Here vendors hold exclusive data and proprietary rules, export full capability chains over MCP, and can price for outcomes. Cursor in the code editor segment and Guidewire in insurance claims are the named examples ^[2].

For private equity diligence this produces a review item that few sponsors apply systematically today. In the technical due diligence of a SaaS target, four questions gain weight: How agent-ready is the data model? Which capabilities are exposed over MCP? Which skills can an external agent consume directly? How mature are identity and governance? A fifth question belongs on the defensive side: Which workflows are observable enough that a third-party agent could substitute them?

The valuation differential between an agent-native target and an agent-wrapped target will become meaningful at exits from 2027. The drivers are unit economics. Lower inference cost per interaction, better scalability across agent channels, stronger defensibility against third-party wrappers. US sponsors who already bake agent readiness into their operating playbooks are positioned to price this correctly on entry. European sponsors relying on generic digital transformation theses will negotiate against better-informed counterparts.

Agent-wrapped and agent-native software: technical and economic differences
Criterion	Agent-wrapped	Agent-native
Architectural starting point	MCP server on top of existing REST API	Data model designed for agent consumption
Output format	Verbose, unstructured	Typed (structured output)
Progressive discovery	Missing	Implemented
Skills over MCP	Not shipped	Shipped with server
Identity and governance	Patched in later	Part of the architecture
Inference cost per task	High	Low
Latency per workflow	High, many calls	Low, composable capabilities
Defensibility against third-party wrappers	Low	High
Signal for exit multiple from 2027	Discount	Premium

How do you review a SaaS target for agent readiness?

Four concrete review items for the next six months.

Map the capability inventory. Which capabilities does the business actually expose? Not the feature list from the marketing one-pager. The list of capabilities that an external agent could consume today. How mature is the data model, how clean are output types, where does governance exist? This exercise typically shows more is exposed than assumed, and that many capabilities live only behind the frontend rather than in the API.
Prioritise the agent roadmap against the frontend roadmap. Most product roadmaps for 2025 were frontend-dominated. Better UI, more integrations, more self-service. For 2026 the board-level question is how much engineering capacity flows into agent-native architecture versus classical frontend work. A plausible split for mid-market SaaS with an exit horizon of 2027 to 2028 is 30 to 40 percent agent-native share, depending on workflow profile (own estimate).
Open up the pricing architecture. A single per-seat contract as the only option is strategically fragile in 2026. Move toward a layered architecture: platform base, capability credits, and an outcome component where the outcome is cleanly measurable. The credit layer is valuable even as transitional scaffolding, because it gives CFOs budget predictability while making agent usage monetisable.
Audit capability ownership. Which of the company's capabilities are replicable, which are not? Replicable means a standard workflow, a public data set, a generic rule engine. Harder to replicate means proprietary data depth, regulatory positioning, industry-specific ontologies, customer relationship effects. Bain and Gartner converge on the same point. Verifiable operational data becomes, in Gartner's phrasing, a currency ^[9]. Vendors without that data layer get undercut by wrapper competitors. With it, the frontend premium can be released and a capability premium built in its place.

My Take

My main observation after the talk and the research that followed is that B2B software vendors will need to pick between two postures over the next two years. A platform strategy with deep capability ownership, an open MCP surface, and their own skill distribution on one side. A commodity position with a replaceable frontend and steady price pressure on the other. The middle ground is narrowing.

The parallel to my 2008 thesis, written at the University of Augsburg, is less spectacular than it might sound. The economic question of how to organise modular capabilities in situational value networks has not changed. The nodes are agents today rather than human operators or ERP systems. The protocols are MCP, A2A, and ACP rather than EDIFACT or OAGIS. The customer-individual production that was discussed back then in the context of capital goods supply networks is today the situational orchestration of capabilities by agents. Anyone who lived through the standardisation debates around EDI and web-based B2B integration in the 1990s and 2000s recognises the patterns. Network effects, lock-in, governance shifts, the emergence of marketplaces. All of it has happened before, just at a slower tempo.

My sharpest prediction for the next 18 to 24 months concerns vertical capability marketplaces. I expect the first industry-specific MCP registries to emerge, with skill catalogues, a governance layer, and discovery through well-known URLs. What Salesforce AppExchange became for horizontal SaaS extensions from 2010 onward, these marketplaces will become for agent-first vertical workflows. The winners will be platforms that get their data model and capabilities protocol-ready now. Companies that start this work in 2028 will walk into an already distributed market.

One thing I missed in the talk, to be honest. Parra speaks about protocol, adoption, and technical roadmap. He says less about what sat at the centre of my thesis work, which is the business-side question of network governance beyond the technology. Who coordinates, who is liable, who earns on the handoffs? Those questions will grow in importance over the coming quarters, more than the protocol details. For private equity boards that means the MCP adoption status of a target is relevant but not the core. The core is who controls the context-bound capability and on what legal basis it gets orchestrated.

For strategic orientation on AI topics from an executive perspective, Convios Consulting runs a KI-Strategie-Readiness-Check and offers regulatory and compliance advisory for mid-market and PE portfolios.