MCP Integration for SaaS: A 5-Step Playbook From 2 Builds

MCP support for a SaaS — what it means

MCP support for a SaaS means adding a layer — an MCP server — on top of your existing REST API so that AI clients such as Claude and Cursor can operate it directly. We have implemented and run this in production on two of our own SaaS products (a CMS with 8 tools and an email API), confirming it can be done without rebuilding the API.

Hi, I’m Masato, and I run Webharu, a company that builds AI websites and AI systems. We also develop and operate our own SaaS products: a CMS and an email API.

“Our customers are asking us for MCP support.” “The board flagged AI agent support as a competitive gap.” Inquiries like these have been increasing from companies that already operate a SaaS or a membership platform. This article sets out the implementation playbook we arrived at by actually adding MCP support to two of our own SaaS products — a CMS (8 MCP tools) and an email API — and running them in production. The intended reader is the CTO or product lead of a company that already operates a SaaS, an internal business system, or a membership platform. Individual and small-scale developers about to build something new are outside its scope (we are preparing separate training material for them).

Here is the conclusion first. MCP support for a SaaS is fundamentally a thin MCP layer added on top of your existing REST API. You do not need to rebuild the API, and you do not need to stand up a separate system for MCP. Most of the effort should go not into the implementation itself but into three design decisions: tool granularity, how you stop dangerous operations, and keys and permissions.

What MCP support for a SaaS means

MCP support for a SaaS means adding a layer — an MCP server — on top of your existing REST API so that AI clients such as Claude and Cursor can operate it directly. MCP (Model Context Protocol) is a common standard for AI to operate external systems, so once you support it you are not building something specific to one AI service.

An explanation of the MCP standard itself, and the full set of design decisions from when we built our first one (the CMS), is in our article on implementing an MCP server for our own CMS. This piece is the sequel, narrowed to the SaaS-side methodology we could confirm was repeatable once the second one, the email API, was built too.

The 5-step playbook for SaaS MCP integration

Let me go through the five steps in order. Code-level procedures, such as how to write a tool definition, are split out into our article on how to build an MCP server. This one stays on judgment and design.

1. Tidy the existing REST API — the API remains the source of truth

An MCP server holds no business logic of its own. MCP is a translation layer for the API, and the REST API remains the source of truth. So the first job in supporting MCP is not writing MCP code — it is getting the existing API into a state you can hand to an AI. Is authentication unified? Do errors come back structured? Are operations at a consistent granularity?

In our CMS, writing from the browser editor, from the REST API, or from MCP all passes through the same validation, history, and audit log. If behavior differs by entry point, you get holes like “the editor rejects it but the API lets it through.” If your SaaS has no external API yet, you build the API first. The order cannot be skipped.

2. Design tool granularity — too many tools eat the context window

This is the most design-like work in the whole effort. The conclusion is simple: keep the number of tools down, and keep what each tool returns small.

My evidence is my own measurement. When I tried to use an external SaaS’s general-purpose MCP (Webflow MCP 1.0) on a real project, merely connecting loaded a huge amount of information, consumed most of the AI’s context, and never reached practical use (the details are in our article on trying Webflow MCP). Tool definitions and returned data occupy the AI’s desk directly. An AI whose desk is buried in paperwork cannot do the job that actually matters.

Learning from that failure, our CMS fits the basic operations — creating, fetching, updating and deleting posts, plus categories and image upload — into 8 tools. Growing one tool per API endpoint, one to one, is the most tempting design and the one that lowers usability most.

3. Make dangerous operations two-stage — prevent structurally, not by prompting

This is the design we were strictest about in our email API (HaruMail). Every sending tool can go no further than creating a draft, and the actual send can only be executed by a separate tool called confirm_send. A path by which the AI sends an email in one move does not exist in the first place.

We did not adopt the approach of asking in the prompt, “please always confirm before sending.” Instructions fade as a conversation grows long, and the way people write them varies. Irreversible operations should be split into two stages structurally, not prevented by asking. Sending, publishing, deleting, charging — list the operations inside your own SaaS that become an incident if they run in one move, and insert a confirmation tool. As design it is a small move, but it changes the safety of AI integration completely.

4. Keys and permissions — a design where suspending one thing stops everything

An API key handed to an AI client gets written into a config file and lives on for a long time, so it tends to be handled more carelessly than a human login. Our design has three points.

• Separating pk (public key) from sk (secret key). What may sit on the front end and what may only ever be held server-side are distinguished at the level of the name itself
• Suspend a member and the keys that person issued expire automatically. The hole where “we disabled the leaver’s account, but writes still go through the API key they created” is closed by the mechanism, not by an operational rule
• Every write operation is recorded in an audit log. When, with which key, and what was done — always traceable after the fact

Incidents in AI integration take the shape of “a broadly privileged key survived” far more often than “the AI went rogue.” Tying the key lifecycle to people is the invisible core of MCP support.

5. Documentation and llms.txt — the reader is an AI

The readers of an MCP-enabled SaaS’s documentation are not only human. The side adopting it now tells its own AI agent to “read the usage docs and wire it in.” On top of our human-facing developer documentation, we published llms.txt too, so that an AI can read the essentials. You can see the real thing in the CMS public documentation.

With machine-readable documentation in place, the adopting company’s AI can read the spec and write the integration code itself. The machine readability of your documentation becomes, directly, how easy you are to adopt — your adoption rate.

What happens once you support MCP

Let me raise the viewpoint one level at the end. MCP support is not merely a technical exercise; it is the addition of a channel.

Once you support MCP, your product starts being used through AI agents. Users stop opening the admin screen and simply tell the AI at hand, “draft this and take it through to publishing.” When the actor doing the operating shifts from a human to an AI, the basis on which a product gets chosen widens from “is the screen easy to use” to “is it easy to use from an AI.”

There is a second effect: AI clients also become a sales channel. If a prospect’s AI can read your llms.txt and documentation and write the integration code, the friction of trial sign-up, tutorial, and habit-forming disappears entirely. Putting an API, MCP, and machine-readable documentation in place while competitors still have only an admin screen is, we think, a sharper differentiator than adding features — which is why both of our own SaaS products are built this way.

Conversely, the design work for the side that connects AI agents to its own internal systems, rather than the side providing the SaaS, is covered in our article on connecting AI agents to existing systems.

Summary: a thin MCP layer, thick design

Here is the playbook for SaaS MCP support once more.

• 1. Tidy the existing REST API (the API is the source of truth; if there is none, start from the API)
• 2. Design tool granularity (fewer tools, smaller returns)
• 3. Make dangerous operations two-stage (prevent it with the structure of a draft plus a confirmation tool)
• 4. Keys and permissions (pk/sk separation, automatic expiry on suspension, audit logs)
• 5. Documentation and llms.txt (published on the assumption an AI will read it)

We have productized our two in-house implementations as they stand, and offer them as API & MCP Development, delivered as a full set including authentication, rate limiting, audit logs, and public documentation. Pricing is ¥2,500,000 for the MCP Starter (read-only), ¥5,000,000 for the API + MCP Full Pack, and from ¥10,000,000 for a full integration that connects an entire internal system (all excl. tax, quoted individually). The one we recommend as a first step is the Starter configuration. Because it only puts a read-only MCP layer over your existing REST API, the risk of write incidents is removed structurally (roughly 4–6 weeks), and you can show your board and your customers what your product looks like when it is “used from an AI.” Even if you are still at the stage of judging “how would this go for our SaaS?”, please start with a free consultation.

FAQ

How much effort does MCP support for a SaaS take?

It is decided almost entirely by how tidy your existing REST API already is. If you already have an API with settled authentication and error formats, the MCP layer itself is thin; of the five steps, the heavy ones are designing tool granularity and designing keys and permissions. In our client work, an MCP Starter that puts a read-only MCP layer over an existing API is ¥2,500,000 (excl. tax, roughly 4–6 weeks), and an API + MCP Full Pack including authentication and authorization, audit logs, and public documentation is ¥5,000,000 (excl. tax).

Can a SaaS with no external API yet still support MCP?

Yes, but the API comes first. An MCP server is a translation layer with no business logic of its own, so you design the REST API that will be the source of truth — authentication, error structure, audit logs — and add the MCP layer on top of it. Tidying the API side is never wasted, because it can be used as-is for external integrations that have nothing to do with AI.

If an AI is doing the operating, can mis-sends and unwanted deletions be prevented?

There are three ways to prevent them: making dangerous operations two-stage, separating key permissions, and keeping audit logs. In our email API, every sending tool is limited to creating a draft, and the actual send can only be executed by a separate tool called confirm_send. The principle is to structurally remove any path by which the AI can send in one move, rather than relying on a cautionary note in the prompt.

How many tools should an MCP server have?

Our CMS fits the basic operations — create, fetch, update, delete, categories, and image upload — into 8 tools. A granularity that keeps the basic reads, writes, and checks in single digits is my rule of thumb. Because tool definitions and returned data consume the AI’s context directly, creating one tool per endpoint, one to one, damages practical usability.

Which SDK should we implement with?

Official MCP SDKs are published (TypeScript, Python, and others), so the basic rule is to match the language and stack of your existing API. MCP is a common standard, so whichever SDK you implement with, supported AI clients see the same tools. Rather than agonizing over SDK choice, we recommend spending the time on tool granularity and permission design.

We have no AI engineers in-house. Can MCP support be outsourced?

Yes. We use the playbook settled by implementing and running two of our own SaaS products, and take on an API + MCP Full Pack covering authentication, rate limiting, audit logs, and public documentation (llms.txt included) for ¥5,000,000 (excl. tax). If you would rather start small, a phased approach from the MCP Starter — a read-only MCP layer only — at ¥2,500,000 (excl. tax) is possible. If you already have an API we start from adding the MCP layer; if you do not, we start from designing the API.