The MCP Playbook for SaaS Founders

The Model Context Protocol (MCP) is the kind of standard that looks like plumbing until you realize it changes distribution. MCP is a protocol that lets AI models and agents connect to external systems — tools, data sources, APIs — in a standardized way. The analogy is USB: before USB, every peripheral had its own cable and its own driver and its own compatibility matrix. After USB, every peripheral plugged into every computer. MCP is trying to be the USB of agent-to-tool connectivity.

As a fractional CTO, I have had the "should we build an MCP server for our product" conversation dozens of times in the last year. The answer is not always yes, but it is yes more often than founders expect, and the reasoning behind the yes is strategic — not just technical. This article is the playbook I walk founders through: why MCP matters for SaaS, how to decide whether to build one, and the concrete steps for doing it right if you do.

Why MCP matters for SaaS

The strategic question MCP poses for every SaaS product is: "When an agent wants to use your product as a tool, will it be easy or hard?" Easy means agents reach your product naturally, through every client that speaks MCP, with no one-off integration work. Hard means agents reach you through whatever bespoke API work a developer happens to do, or not at all.

Over the next few years, an increasing share of SaaS usage will come through agents operating on behalf of users. Some of those agents will be built inside your product (see agents are eating SaaS). Others will be built outside your product, by your customers or by upstream agent platforms, and they will want to call into your product to get things done.

If you are easy to call into, you become a tool in everyone else's agent. That is sometimes a great position (you are the system of record, you get usage and revenue) and sometimes a dangerous position (your value migrates upward to the agent platform and you become a commodity). Either way, being easy to call is better than being hard to call, because hard means you get skipped entirely.

The three questions to ask before building

Before committing engineering time, answer three questions:

1. Do your customers want to use your product from outside? If the answer is clearly no — your product is a closed workflow nobody wants to operate from elsewhere — MCP is not urgent. If the answer is yes or unclear, keep reading.

2. What is your API maturity? Building an MCP server is much easier if you already have a well-designed, well-documented internal API. MCP is not a replacement for having good APIs; it is a way to expose good APIs to agents. If your API is a mess, fix that first.

3. Can you handle the security implications? An MCP server opens your product to a new consumer type: agents authorized by a user but operating without per-action human review. The auth model, the rate limiting, the permissioning, and the audit trails all need to be right. Do not ship an MCP server without thinking this through.

If the answers to all three are in the right range, building an MCP server is likely worth it — especially if you are at the stage where enterprise customers are asking about integration with their own agents.

What an MCP server actually exposes

An MCP server exposes three things: resources (readable data), tools (callable actions), and prompts (reusable templates). For most SaaS products, the interesting exposure is resources and tools.

Resources are the read-only views of your data. For a CRM, resources would be "contacts," "companies," "deals." For a project management tool, they would be "projects," "tasks," "comments." An agent connected to your MCP server can list and fetch these resources to understand the state of the user's account.

Tools are the write actions. For the CRM, tools would be "create_contact," "update_deal_stage," "log_activity." For the project management tool, they would be "create_task," "move_task," "add_comment." Tools are the levers the agent pulls to actually do work.

Good MCP server design is mostly about picking the right level of abstraction for tools. Too fine-grained and the agent has to string together 10 calls to do one thing. Too coarse and the tool does things the agent did not intend. The right level is usually "the thing a power user would do in a single UI operation."

The implementation outline

A practical outline for building a first MCP server at a seed-stage company, assuming you have a reasonable internal API to build on top of:

Phase 1: Scope (1–2 days)

Pick 5–10 resources and 5–10 tools for the first version. Err on the side of fewer. It is easier to add more later than to deprecate ones you shipped prematurely. Focus on the operations that represent 80% of what a user would do with your product.

Phase 2: Auth and permissioning (3–5 days)

Decide how agents authenticate. The cleanest pattern is per-user OAuth tokens — the user authorizes the agent to act on their behalf, and the agent presents a token when calling the MCP server. The token has the same permissions as the user.

Add rate limits specifically for agent traffic. Agents make 10x the requests a human does for the same work, and the load profile is bursty. Protect your database.

Phase 3: Tool descriptions (2–3 days)

The descriptions of your tools are, in a real sense, the product. A well-described tool is one an agent can use correctly; a poorly-described tool is one an agent calls wrong or avoids. Write the descriptions with care. Include: what the tool does, when to use it, what the parameters mean, what happens on success, what happens on failure, and any gotchas.

Phase 4: Implementation (1–2 weeks)

Build the server itself. There are SDK libraries for MCP in most languages that handle the protocol plumbing. Your job is to implement the handlers for each resource and tool in terms of your existing API. Most of the work is translation between MCP's shape and your own internal API's shape.

Phase 5: Observability (2–3 days)

Log every MCP request with user, tool, parameters, and outcome. This is both for debugging (agents will do surprising things) and for security (if something goes wrong, you need a trail). Make sure the logs are queryable, not just written to a file nobody reads.

Phase 6: Safety rails (1 week)

Add explicit confirmation requirements for destructive actions. Add audit logging that the user can review. Add the ability for a user to revoke agent access in one click. Decide which actions are allowed without explicit per-action approval and which require one.

Total effort for a first version: 3–5 weeks of focused engineering for a small team. The big variable is how clean your existing internal API is. Teams with well-organized APIs finish in 3 weeks; teams whose APIs need cleanup finish in 5 or 6.

The security and trust model

The single most important thing to get right is the authorization model. Some guidelines:

Agents act as the user, not as themselves. The permission model is the user's permissions. Do not introduce a separate "agent" role that has more access than the user.

Destructive actions need confirmation. Deleting, sending external messages, making payments — these should require explicit confirmation. Either the agent asks the user, or your MCP server returns a "pending confirmation" state that the user must approve in your UI.

Rate limits per user, not per IP. Agents run from everywhere. Limit by authenticated user, not by client IP.

Full audit trail. Every agent-initiated action should be in an audit log the user can review. The user should be able to ask "what has this agent done in my account" and get a complete answer.

Kill switch. The user can revoke agent access at any time, and all in-flight agent operations stop. This is non-negotiable for trust.

Get any of these wrong and you will have a security incident within the first quarter of launching the server.

The common mistakes

Building the MCP server as a thin wrapper over the internal API. Do not expose every endpoint. Pick the operations that are useful to agents and leave the rest hidden. An agent does not need your internal admin endpoints.

Weak tool descriptions. "update_deal: updates a deal" is useless. The description needs to tell the agent what to use it for. Invest real time here.

Skipping the observability step. Agents do surprising things, and without observability you cannot tell when the agent is doing the wrong thing.

Rolling out to every user at once. Flag the MCP server behind a feature flag and give it to a small alpha group first. You will find surprises. Let them be small surprises.

Thinking of MCP as a developer API. MCP is different from a developer API because the consumer is non-deterministic. A developer writes specific calls; an agent discovers what to do on the fly. The design implications are different.

Counterpoint: MCP is not mandatory in 2026

A warning. Not every SaaS needs MCP right now. The protocol is still maturing, the ecosystem is still forming, and the "agents calling your product" use case is real but not yet the majority of traffic for most products. If your customers are not asking for it and your strategic analysis says you are not in the "agents eating your category" risk area, you can defer. Just do not defer forever — building an MCP server becomes a bigger project the longer you wait, because you have more API surface to map.

Your next step

If you have an internal API and a product that agents could usefully operate, sketch the 10 resources and 10 tools you would expose. That alone is valuable — it forces you to think about which parts of your product are agent-friendly and which are not. If the list feels tractable, put the MCP server on the roadmap for the next quarter.

Where I come in

Designing and building MCP servers is a rapidly growing part of my AI practice. A typical engagement is the 3–5 week implementation outlined above, plus the strategic conversation about what to expose and how to think about agent traffic. Book a call if you are weighing whether to build an MCP server and want a second opinion.