Updated on 2nd April 2026 by Fraser Davidson

As we’ve been rolling out our MCP PaaS, one pattern has become very clear: SaaS and software companies tend to fall into two distinct camps.

• Those wrestling with Day One MCP challenges
• Those who’ve moved on to Day Two MCP challenges

Understanding which camp you’re in – and what’s coming next – is critical if you want MCP to be more than a lab experiment in your product.

Day One: Concept Challenges

Day One is where most teams are today. The questions sound like this:

• How do I create an MCP?
• What are my customers actually going to do with an MCP?

These are concept MCP challenges. You’re defining the shape of your first MCP server, mapping your product capabilities into tools, and trying to identify the initial use cases your customers and their agents will care about.

At this stage, success is usually measured by:

• Getting something working end‑to‑end
• Proving that your product can be “made MCP‑accessible”
• Finding those first internal champions or design partners

If you’re here, you’re not late. Despite what the social media MCP echo chamber might suggest, this is where most SaaS/software companies are.

Day Two: Scalability and Control

Once you clear the conceptual hurdle and see MCP usage in the wild, a very different class of problems emerges. The questions shift from “can we?” to “how on earth do we manage this at scale?”:

We’ve Seen This Movie Before: Lessons from Integrations

If you’ve worked in the integration space, none of this is new.

For years, SaaS/software companies have been able to self‑code integrations. A good engineer can wire up APIs between systems; technically, a platform like Cyclr doesn’t do anything magical that a strong dev team couldn’t do once.

The problem was never the first integration.

The real challenge was:

• Multiple integrations
• Across multiple customers
• Each with slightly different requirements
• Over time, as APIs change, products evolve, and usage grows

That’s where embedded iPaaS emerged as the control and scalability layer: providing standardisation, tenant isolation, monitoring, governance, and a sustainable way to deliver integrations as a product capability rather than a series of one‑off projects.

MCP is following the same trajectory.

• Day One: build an MCP server, prove the concept.
• Day Two: you need an embedded layer that manages configuration, isolation, monitoring, throttling, and monetisation across many customers and use cases.

Companies that plan for Day Two early will avoid the “spaghetti MCP” problem that many teams hit in the integration world.

The Coming Day Three: APIs for Intelligence, Not Just Applications

There is a third phase coming, and it will be more transformative than most teams expect.

Day Three MCP challenges will be driven by a simple but profound shift:

“MCP will force an evolution in API functionality that traditional integrations never required.” Cyclr CEO, Fraser Davidson

So far, most APIs have been function‑oriented: “Get customer”, “Create invoice”, “Update subscription”. They were designed for deterministic application workflows orchestrated by humans or tightly scripted logic.

MCP, and agentic systems more broadly, demand purpose‑oriented APIs:

• “Optimise this customer’s billing configuration”
• “Generate the most relevant insights for this account team right now”
• “Safely execute the series of steps needed to onboard this customer”

These are APIs for (artificial) intelligence, not just for applications. They need to:

• Expose higher‑level intents and policies, not just low‑level CRUD calls
• Encode business constraints and guardrails so agents don’t go rogue
• Provide rich context so models can make good decisions without endless back‑and‑forth calls

We are only at the beginning of this shift. But Day Three will belong to companies that deliberately redesign their API surface area around agent‑friendly purposes, not just endpoints.

What SaaS Leaders Should Do Now

1. Be honest about your stage. Are you still wrestling with concept questions, or are Day Two issues already appearing at the edges? Don’t let the hype make you feel late; design for where you are.
2. Design Day Two into your Day One. As you stand up your first MCP, think about multi‑tenant control, monitoring, and monetisation from the start. Borrow patterns from embedded iPaaS rather than reinventing them.
3. Start a Day Three workstream. Even if it’s exploratory, begin asking: If an agent had to use our product purely via APIs, what higher‑level intents would it need? What guardrails? What “purpose‑built” methods?

MCP is not just another integration technology. It is going to reshape how APIs are designed, how SaaS products expose capability, and how value is packaged and sold.

Day one is exciting, day two is where the real operational work begins, and day three is where competitive advantage will be decided.

You may also like these…