Chatbot or MCP Server
Which AI surface to ship first
The default AI feature is a chat panel pinned to the right of the product. For most SaaS teams, that's the wrong place to start. Ship the MCP server first. If you also need an embedded chat experience — and many products do — build it as a client over your own server.
The reasons are composability, cost, and the discipline of designing a real interface. They also explain why most AI deployments don't deliver the value they promise, and what the small minority that do are doing differently. There's an obvious objection too, which we address below.
Composability is the thing only MCP gives you
Most of the AI work your customers actually want to do isn't single-system. A sales lead arrives in the CRM, but the reply needs context from the inbox and the last call's transcript. A bug report only becomes actionable once it's cross-referenced with the deploy log and the support thread. A finance question lives across the spreadsheet, the data warehouse, and the contract.
An embedded chatbot can't do any of that. It only sees your product. The customer who wants the cross-cutting answer leaves your app, pastes data into their assistant, and assembles the workflow by hand — which is exactly the work they were hoping the AI would do for them.
An MCP server changes the shape of the problem. Once your product speaks MCP, the customer's AI client can pull your data in alongside their inbox, calendar, notes, and any other connected tool, and run the whole workflow in one pass. Your product stops being a destination and becomes an ingredient. Every additional MCP server the customer connects makes yours more useful. An embedded chatbot gets none of that.
A worked example. The customer connects your CRM, Gmail, Google Calendar, and their notes app to Claude. They ask: "Draft replies to every lead from last week's webinar, using my demo notes, and book follow-ups in my open slots." Your CRM is one of four systems Claude calls in sequence, and the answer composes itself. No chatbot bolted onto your CRM can answer that question — not because the prompt isn't good enough, but because three of the four systems aren't there.
We made this call with MushRoom, our property management product. The first AI feature we wanted was a pricing assistant — somewhere to ask Claude for help thinking through nightly rates and seasonality. The obvious move was a Pricing Assistant panel calling the Claude API behind the scenes. The next AI feature would have been the same shape, then the one after. What we did instead was expose MushRoom's data and capabilities over MCP. That's what makes it possible to ask, from any AI client: "Which guest nationalities prefer which months, so I can plan ad spend?" MushRoom has no ad-campaign feature. The AI client composes one out of the data MushRoom exposes. Every workflow we didn't think to build is one users can compose for themselves.
You don't build the chat or pay for inference
A chatbot in your product isn't one feature. It's a chat surface across web, iOS, Android, and any other client your customers use, with all the work that goes with it — file uploads, voice input, conversation history, search, accessibility, internationalisation, markdown and code rendering, the full polish customers now expect from a chat experience because Claude and ChatGPT have set the bar. That's a multi-platform UI commitment, not a side project, and the bar keeps rising.
An MCP server hands that surface to Anthropic, OpenAI, Microsoft, or Google. They've collectively spent billions making the chat client good across every platform; you don't have to compete with them. Your team builds the resource model, the tools, and the auth flow, and ships them once. The chat UX is somebody else's product.
The inference cost shifts the same way. An embedded chatbot routes every customer message through your OpenAI or Anthropic account, and you absorb that cost into margin or pass it through in pricing. The arrangement holds until prompts get longer, the model gets upgraded, or someone discovers your chatbot makes a fun coding assistant. Then it doesn't. With MCP, the meter runs on the customer's Claude subscription, ChatGPT subscription, or Gemini quota — not yours.
For early-stage SaaS, lean teams, and any product where AI is meant to be a feature rather than the entire margin story, this is the most practical of the three arguments. You ship one server. You don't maintain a chat surface across four platforms. You don't pay per token. The engineering goes somewhere it actually differentiates the product.
The discipline an embedded chatbot lets you skip
Designing tools, resources, and scopes for an external agent forces decisions that an internal chatbot lets you postpone. You have to name the operations. You have to model the permissions. You have to decide what an agent can and cannot do on the customer's behalf. The output is a real product surface — one that survives a competitor with an OpenAI key shipping a chat panel of their own in a weekend.
Teams who start with the embedded chatbot tend to paper over the missing surface with prompt engineering. Six months in, that prompt is 4,000 words long, written by three different engineers, granting whatever access the model needed for whichever feature shipped. Nobody can tell you what the chatbot actually does. Nobody wants to put it in front of a security reviewer. This is the wrapper failure mode playing out inside your own codebase.
When the time comes to expose the same product over MCP — and for most products, that time comes — the team has no proper resource model, no scoped tokens, no audit trail, and a security review it cannot pass. The other order — MCP first, embedded chat as a client of it — produces one canonical surface and lets you build the chat experience without rebuilding the foundation.
Distribution happens elsewhere now
An embedded chatbot needs the customer to come into your product to ask a question. An MCP server is discovered from inside the assistant they already use. The cost of trying you drops to "approve a connector."
Anthropic created the protocol and ships it natively in Claude. OpenAI added MCP support to ChatGPT, the Agents SDK, and the Responses API in 2025. Microsoft followed with native MCP across Copilot Studio, Azure, and Visual Studio Code. Google's Gemini SDKs and Gemini CLI support MCP as a first-class tool surface. Linear, Notion, Atlassian, and GitHub all publish official MCP servers, and customers who connect them stop switching tabs to use any of them. That is the surface MCP-enabled SaaS reaches.
The objection is smaller than it looks
The obvious objection to MCP-first is the addressable market today. Plenty of B2B SaaS customers don't yet route their work through Claude or Copilot — sales ops at a mid-market manufacturer, the ops team at a regional bank, the back office at a logistics company. They sit inside your product. Building MCP for them looks like building for a market that doesn't exist yet.
The objection has more force in the abstract than in practice. Claude, ChatGPT, and Copilot all have working consumer and team tiers. Signing up takes minutes, and getting onto Claude to use your MCP server is no harder than logging into your product to use a chatbot. Anthropic, Microsoft, and Google have spent the last two years removing that friction; you don't have to do it for them. Building your own embedded chatbot when those clients exist is in the same category as building your own database when Postgres exists, or your own OS when Linux exists — technically possible, occasionally justified, almost never the right call.
Where the objection still bites is procurement-restricted environments — IT departments running approved-vendor lists, conservative organisations putting AI clients through months-long reviews. If your customers are exclusively in that segment this year, an embedded chat experience may be the only thing they can use today.
For everyone else, the choice isn't chatbot or MCP. It's MCP server first as the canonical surface, with a thin embedded chat for the cases where the customer genuinely can't bring their own client. The embedded chat is itself an MCP client over your own server. You do the integration work once. The customer who lives in Claude gets composability. The customer who lives in your app gets a familiar in-product experience. One resource model. One auth flow. Not two divergent codebases.
When in-product chat is genuinely the right answer
There are categories where embedded AI wins, and the work is to recognise them.
The clearest is the walk-up audience that doesn't have an AI client of their own. A hotel offering an in-room or lobby kiosk so guests can ask about late checkout, the spa's opening hours, breakfast, or how to get to the airport. The guest isn't going to connect Claude to the hotel's property management system for a three-night stay, and the hotel doesn't want them to. It wants a branded, on-property surface that runs in the guest's language and never sends them off to a third-party app. That's an embedded chat, and it's the right shape for the job. The same logic applies to airline check-in kiosks, retail in-store assistants, public-sector service points, and any consumer-facing surface where the audience is transient and the interaction is captive.
Latency-bound interactions also belong in the product. A code-completion popover, an inline canvas transform, an autocomplete that has to feel typed — round-tripping through an external client breaks the experience. Workflows tied to live, ephemeral UI state belong in the product, because the state isn't a resource you can meaningfully expose. Regulated and brand-critical surfaces — banking, healthcare, classified work — often can't send the customer to a third-party client at all. And if the product is itself the thinking environment — IDEs, agent platforms, document tools where conversation is the primary interaction — then the chat interface is the product.
Outside those categories, the question is whether your customer's most valuable workflow stays inside your product, or composes with the rest of their stack. If the answer is the second, the embedded chatbot is the wrong shape.
Security shifts, it doesn't vanish
MCP isn't a free upgrade on the security posture of an embedded chatbot. It moves the surface and changes the threat model. Prompt injection, tool-permission combinations that enable exfiltration, lookalike servers spoofing trusted ones — these are part of the product now, not a future concern. The MCP specification's security best practices cover protocol-level mitigations. Scoped tokens, audit logs, and a defensible consent model are work the team has to do.
This is consultancy work, not a checkbox. Teams who get value from MCP treat the server as a real product surface, with the same review they would give a public API. Teams who treat it as a cosmetic compatibility layer end up shipping the kind of CVE that ends up on Hacker News with the company name attached.
What we recommend in practice
Publish the MCP server first; treat any embedded chat as a client over the same server. The protocol is well-documented; the implementation isn't the hard part. The hard part is the design decision the rest of your roadmap rests on — which surface is canonical, what to expose, what to refuse, how to do any of it without leaking customer data. We do that work with teams who would rather make the decision once than rebuild the AI surface twice.