The Next Battle in SaaS Starts Above MCP

Model Context Protocol is giving AI a common way to connect with enterprise software. Vrushali Paunikar, Chief Product Officer at Carta, argues that the bigger challenge is deciding what happens after the connection is made, and how much of the job should be left to the language model.

Over the past year, Model Context Protocol has gone from a relatively obscure technical standard to one of the biggest ideas in enterprise AI.

MCP gives AI applications a standard way to connect to external software, access data and take actions. Instead of every software company building a bespoke interface for every AI model, MCP provides a common language.

Think of MCP as the electrical outlet in your wall. It’s a common standard that lets any device plug in and get power. It’s great because it’s open and works everywhere, but an outlet by itself doesn’t do anything for you. You still need an appliance.

I suspect we will eventually look back on the current enthusiasm for MCP in much the same way we look at the rise of APIs. They were foundational and changed how software was built. But over time, connectivity became expected infrastructure rather than the product itself.

Much of the SaaS industry is currently treating AI connectivity as though it is a finished product. Build an MCP server, expose the right tools and data, and let the model take it from there.

For some use cases, that is enough. For many enterprise workflows, particularly financial ones, it isn’t.

MCP Is Winning the Connection Layer

Standardisation is already changing how AI applications interact with software. MCP is supported across a growing range of major AI platforms, making it increasingly realistic for users to work with the same underlying systems from whichever AI interface they prefer.

But while interoperability solves the access problem, it doesn’t tell the model how the job should be done.

I spend much of my time thinking about software used by private markets investors and finance teams, where this distinction becomes particularly clear.

Give an AI system access to a private fund’s performance and portfolio data, for example, and there may be several ways to answer what sounds like a straightforward question.

One approach might use the appropriate calculation. Another might take a shortcut. A third might misunderstand what the user is asking for.

The user is then forced to become part analyst, part prompt engineer and part quality controller. This isn’t the frictionless experience promised.

The Product Still Needs an Opinion

This is where the next layer of the stack becomes interesting. If MCP is the connection layer, plugins and skills sit above it, telling the agent how to use that connection to complete a particular task.

Rather than simply exposing data and functions to a model, they can package instructions, workflows, deterministic calculations and interfaces around them.

Sometimes this might mean following a defined sequence of actions. Sometimes it might mean running a deterministic calculation or script instead of asking an LLM to work out the answer. In other cases, the end result might be a spreadsheet, report or small application designed specifically for that workflow.

The expertise sits in the product, rather than being left entirely to the model.

Evidence shows the combination works. Google recently tested an AI coding agent that could access its technical documentation through MCP, then gave it additional task-specific instructions explaining how best to use that information. Combining the connection with those instructions achieved a 96.3% pass rate in Google’s evaluation, while using 63% fewer tokens per correct answer than standard prompting.

For SaaS companies, this changes where differentiation sits. If every application can expose data through the same open standard, access itself becomes less distinctive. Knowing how to turn that access into a reliable outcome becomes more valuable.

Not Every Task Should Be Left to the Model

Large language models are probabilistic systems. The flexibility that makes them useful for writing, exploration and reasoning is less attractive in workflows where accuracy and repeatability matter. Finance is a good example: if someone expects the same calculation to produce the same answer every time, variation quickly becomes a problem.

Financial software has spent decades moving in the opposite direction. Audit trails, permissions, standardised calculations and repeatable processes exist because consistency is valuable.

AI shouldn’t discard those lessons. The strongest enterprise AI products will know when to let a model reason and when to constrain it. Probabilistic systems make sense when judgement and interpretation are useful. Deterministic tools make more sense when precision and repeatability are required.

The same principle applies anywhere the cost of getting an answer wrong is high.

Where SaaS Differentiation Moves Next

The layer being built above MCP is still much less settled than MCP itself.

Different approaches to plugins and skills have emerged, but efforts are already underway to make them more portable between AI platforms rather than locking them to a single ecosystem.

SaaS companies will still have to make choices before every standard has settled. They always have.

The alternative is to expose an interface and leave customers to assemble the experience themselves.

AI may follow the same path. Connecting an agent to enterprise software is becoming easier by the month. The advantage will increasingly lie in what happens next: the workflows, controls and domain expertise that tell the agent how to turn access into a reliable outcome.