Why should you build an MCP-first product?

Have you connected other products into your Claude or ChatGPT?

Probably your email and calendar, maybe your CRM or call transcription tool, you might even have connected your accounting system and banking.

These connectors use the Model Context Protocol (MCP) and give AI models a way to retrieve, reason and add to data that you hold in these other systems.

Over the last twelve months we've seen SaaS vendors, including Salesforce, switch from "no connector - we want our customers to come to our UI to experience the value we offer" to "we need to provide our data in the tools where work is getting done - Claude and ChatGPT"

This trend has a name - headless software. Their product stops being a place that you go, and becomes a system of record, which is no longer accessed via their own UI, but via an AI platform - headless.

Note:MCP is the name of the industry protocol - and the products have varying names - with Claude we talk about a "connector" and a "plugin" which is a wrapper around an MCP connector and some skills, in ChatGPT we talk about an "app", and a similar "plugin", and in Copilot "agents"

In this series of articles I'm going to walk through our learning building an MCP-first product, giving you some tactical advice as you look at your own product roadmap.

This will be useful for product leaders if your company provides any kind of software or platform for your customers to access - a SaaS product, a customer service portal, a reporting platform.

The series includes three articles:

1. Why would you do MCP-first - this article
2. How do you design MCP-first?
3. How do you operationalise MCP-first

What does MCP-first mean?

MCP-first means that your customer's primary entry point into the product is via the MCP - they get their value from your product primarily from within another product - ChatGPT, Claude or their chosen AI tool of choice.

This differs from the connectors I listed above (email, calendar, CRM) where there are existing UIs and data that are the primary source of value, and the connector is just one other entry point into the platform.

Here's the challenge - connecting into an existing platform is valuable if you have existing CRM or accounting data within that platform - and the opposite is true if you connect to a new platform or tool you have never used.

Connecting into Hubspot if you are not a Hubspot customer adds very little value - there are no records to read. Connecting into a new email account with no email to search is useless.

Kowalah is the operating system for organisations in an AI future - mapping their processes, AI workflows, agents and skills. For a customer that hasn't yet mapped out their org structure and processes there is nothing for a Kowalah connector to serve up to them.

MCP-first solves the cold start problem, allowing us to offer value to our users from day one, without needing a seeded database. The MCP itself is the source of that data and future value.

Take note that we're saying MCP-first - not MCP-only. The MCP is the initial and primary source of value to the user but they may well use your UI for more complex tasks that don't lend themself to a chat or voice interface (complex reporting for example)

Become a spoke not a hub

When building a SaaS product you position yourself at the centre of the customer's world.

You sit in the middle (the hub), then all of the other tools a user requires are the spokes around you - it is a very egotistical view!

This means you need to get busy building integrations into your platform, so that when your user is in your interface they can see and interact with the rest of their world - emails, call transcriptions, calendar events, projects and so on.

As a result, every SaaS platform has an integrations page with a long list of the same logos - Google, Microsoft, Linear, Asana, Monday, Hubspot, Salesforce and so on.

With MCP-first we aren't trying to be the hub, instead we explicitly want to be the spoke - because we recognise that the user will get more value by chatting with their AI model that is already connected up with all of their other spokes.

When a user asks the question in their AI, they are already connected into their email, their calendar, their documentation. The connectors built by those vendors gives the AI access to far more data that we might have access to via a direct integration, and we can design our own MCP to look for those other connectors.

As a hub, your work building integrations is never done. As a spoke, let the user's AI tool do the work for near zero cost.

Let the customer's agent do the work.

By giving up our desire to be a hub, and choosing to be a spoke, we get another benefit - the workload shifts from our agent (if we'd chosen to build one) to the user's agent.

The user's ChatGPT, Claude, Gemini or Copilot subscription, their Grok Bot, their Muse, their Instinct, is what drives the conversation - and in turn what consumes the tokens.

You'll see plenty of discussion about VC-funded AI wrappers whose inference costs to support their customers is a significant portion (if not more than 100%) of their revenue.

As a hub, your best users are your most expensive (causing you to look at offloading to lower cost models, limiting usage, or increasing power user fees). As a spoke - they are effectively free and you can encourage their adoption.

This allows you to offer generous free tiers without having to deploy significant capital to sustain the usage. A free self-service user costs us approximately storage.

What are you giving up?

Its not all good news though - in passing the workload to your users you give up control of the model they use - one user may be using GPT-6 Astra, another Gemini, another Sonnet 5 - they might be on a weaker tier, get rate limited, or hit their own cap mid-task which could impact their experience.

You give up control of the UI. By their very nature AI's are probabilistic, so the same task will get differing responses depending on how the user has set up their AI tool.

You have no control over, or knowledge of which other spokes the user has enabled. User A may have their email and CRM connected, User B may be in a personal account with no connectors - we have no control or way of tracking that.

We also lose the ability to do more detailed reporting. We can't see what they asked, or how well their model supported their request using our connector.

And we are limited in how we can charge for the service - tool calls into the MCP server become the unit of measurement.

These seem like big problems - but my view is ship has already sailed - your user is already getting their work done within their AI tool of choice and you need to serve them there.

Launching a new product using MCP-first approach

The biggest reason for going MCP-first is when you don't have an existing product at all.

The barrier to building software has collapsed - building is not the bottleneck - distribution is.

And increasingly, getting users to visit your application's URL in their browser, or tap into your app on their phone is seeming an antiquated approach.

In the future - you'll have two main ways that users find and engage with your new product:

1. The human chooses to interact with your new product via their preferred AI interface (ChatGPT, Claude etc)
2. The human's agent chooses to interact with your new product (Muse, Grok Bot, Instinct, Hermes, Codex, Claude Cowork etc)

In the SaaS world, user onboarding and getting the user to the 'wow moment' when they get value for the first time is normal practice - onboarding calls, guided walkthroughs, data seeding from other systems.

With AI we now have a super powerful onboarding assistant for new products, that can help guide the user or their agent through the early stages of product use, providing them value at day zero through skills that help the user to complete tasks, and harvesting (with permission) the ways of working to seed the system of record your product provides.

This shift reminds me of the launch of the App Store in 2008. Suddenly there was a new surface to attract customers and deliver value to them. New app-native companies were launched - without a worry of whether those customers would ever visit their website.

We are entering that era for AI-native products - and the opportunity to learn is now.

Up next: designing your MCP-first approach

In this article we've looked at why you should explore MCP first:

• Becoming a spoke puts you in the flow of your user's work
• You let the customer's agent do the work (and they pay for it)
• Its ideal for launching a new product in an AI-future

In the next article I'll look at how to design an MCP-first product and some of our lessons learned.

———-

As background I'm Charlie, the CEO ofKowalah, we build agents and AI-native workflows for Enterprises.

If you're considering building AI products for you internal teams or customers, our Kowalahs would love to learn more about your current processes - or you can start MCP-first at kowalah.com