Should Your SaaS Ship an MCP Server? A Plain-English Founder Guide

Short answer: if you sell B2B software and your customers already use Claude, ChatGPT, or Copilot at work, you should probably ship an MCP server within the next two quarters, and the July 2026 spec update made that far easier than it was a year ago. If you sell a consumer app with no "do this for me" workflows, you can wait. Either way, the protocol is the easy part. The real work is permissions, confirmation for dangerous actions, and making sure your server never becomes the way an attacker reaches your customers' data.

A question now comes up on nearly every SaaS call I take, phrased a little differently each time: "A customer asked if our product works with their AI agent. What do we tell them?" What they are asking about is an MCP server. Here is what it is, why it stopped being optional for a lot of B2B products this year, what it actually takes to do right, and where the security risk really sits.

What an MCP server is, in plain English

MCP stands for Model Context Protocol. It is an open standard for how an AI assistant (Claude, ChatGPT, Copilot, Cursor, Gemini, and the agent tools built on top of them) connects to outside software. Your product runs an MCP server: a small service that says "here are the things an assistant is allowed to do with this account" and exposes each one as a tool. Search invoices. Create a ticket. Pull this week's numbers. The assistant on the customer's side is the client. It reads your list of tools, decides which to call based on what the person asked, and calls them using that person's own permissions.

If you already have a documented API, an MCP server is mostly a thin, authenticated layer over it. It does not replace the API. It gives the API a second audience: agents instead of developers.

Two terms matter for the rest of this post. A remote MCP server is one you host at an HTTPS URL, which is what the directories and enterprise customers want. A local server is something a developer runs on their own laptop, which is fine for developer tools and irrelevant for most SaaS.

Why this got urgent this year

Three things happened between December 2025 and September 2026.

The protocol grew up. On July 28, 2026, the maintainers shipped the 2026-07-28 specification, which removed protocol-level sessions and the initialization handshake, so a remote MCP server is now a stateless HTTP workload you can host right next to your existing API. The same release introduced a formal deprecation policy with a minimum twelve-month window, which is the kind of boring guarantee a business needs before it builds on something. Netlify's Sean Roberts summed up the change as making MCP "a first-class HTTP workload with no session management to work around." Earlier versions carried session IDs and long-lived streams that were awkward to load-balance, which is why so many first-generation MCP servers were flaky in production.

Adoption went vertical. When Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation in December 2025, co-founded with OpenAI and Block, the project reported over 97 million monthly SDK downloads and 10,000 active servers. By the July 2026 release, the maintainers reported close to half a billion SDK downloads a month, with the TypeScript and Python SDKs each past one billion total. That is not a developer fad. That is the plumbing every major AI product settled on.

The distribution channels are all MCP. Anthropic's Connectors Directory accepts remote MCP servers and surfaces them inside Claude on the web and desktop. OpenAI's plugins for ChatGPT bundle skills, MCP servers, and optional UI, and ChatGPT uses remote MCP-backed tools supplied by plugins. Cursor, VS Code, Claude Code, and GitHub Copilot connect to any MCP server by URL. Build one server and you are reachable from all of them.

Companies you know are already there. Stripe runs a remote MCP server at mcp.stripe.com that lets an agent read and write customers, invoices, subscriptions, and refunds under OAuth. Shopify's Storefront MCP exposes a store's catalog, cart, checkout, and policies so shopping agents can buy from the merchant. I covered what that means for merchants in agentic commerce and AI checkout. The point for a SaaS founder: your customers' expectations are being set by the biggest platforms they use, and those platforms all answer "yes" to the agent question.

Should you build one? A short test

Build in the next one or two quarters if most of these are true:

• You are B2B and you are a system of record. Customers keep data in you that they want to ask questions about, or take repeated actions on. CRM, billing, support, analytics, project tracking, inventory.
• Your customers already use an assistant at work. If they are on Claude, ChatGPT, or Copilot, the "can our agent use this" question arrives whether you plan for it or not.
• Integrations are on the evaluation checklist. If you already get asked about Zapier and a public API, MCP is the next line on that list.
• You have a real API and a real auth model. Per-user permissions, not one master key per account.

Wait if these describe you:

• You are consumer-facing with no "do this for me" workflows. An agent has nothing useful to do inside a meditation app.
• Your API is undocumented or changing weekly. An MCP server inherits every problem in the API underneath it.
• Nobody can own the security surface. More on this below, but if that sentence made you uneasy, that is the right instinct.

One more honest thing: an MCP server is an integration surface, not a growth hack. It makes you stickier and easier to evaluate. It does not, by itself, send you customers.

What it actually takes to do properly

The protocol work is small. With the official SDKs, wrapping an existing REST or GraphQL API takes days, not months. Everything that makes it safe and useful takes longer, and that is where I spend most of the time on these projects.

Authentication is OAuth, not API keys. The Claude directory requires OAuth 2.0 for authenticated services, and the spec's own security guidance is blunt: MCP servers must not accept tokens that were not explicitly issued to them. "Just forward the customer's existing token" is a forbidden pattern, not a shortcut. If your product does not have an OAuth flow today, that is the first real piece of work.

Fewer tools, described precisely. An assistant chooses tools by reading their descriptions. Twelve well-named tools beat sixty auto-generated ones. Every tool needs a title and a read-only or destructive annotation, which the Claude directory checks before it will list you. I split every server into read tools and write tools from the start.

Human confirmation for anything that costs money or cannot be undone. Stripe's server is the model here. Certain write actions such as refunds and outbound payments require a human to approve the request in a browser before the agent can retry it, and the approval expires after 24 hours. Copy that for refunds, deletions, sending email, and anything that touches a third party.

Stateless from the first commit. The new spec has no sessions, so any state you need across calls (a draft, a cart, a report in progress) lives behind an explicit handle bound to the authenticated user on the server side. The spec says it directly: possession of a handle is not authentication.

Logs, an off switch, and revocation. Stripe logs every tool call, lets an administrator disable MCP access for the whole team, and shows OAuth sessions that can be revoked one by one. Your enterprise customers will ask for exactly those three things in the security questionnaire.

Host it like an API, because it is one. After July 2026 there is no special infrastructure. Your MCP server runs where your API runs, scales horizontally, and sits behind the same gateway, rate limits, and monitoring.

The security part most guides skip

This is the section I would read first if I were you.

In May 2026 the NSA's Artificial Intelligence Security Center published a cybersecurity information sheet titled Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. It says that gaps in MCP design, implementation, and operational posture "have created significant and evolving security concerns including serialization risks, trust boundaries, and agent misuse." When a national security agency writes a threat model for a protocol that is two years old, the protocol has arrived, and so have the attackers.

The attack that matters most is not against your server. It is through it. OWASP now classifies MCP tool poisoning as an indirect prompt injection attack: text that reaches the assistant through a tool result or a tool description gets treated as instructions, and the assistant follows them. In April 2026, researchers showed exactly how cheap this is. Malicious text in pull request titles and issue comments was enough to make Claude Code's review action, Gemini CLI, and GitHub Copilot's agent leak API keys and tokens. The researcher's summary of the root cause applies to every agent your customers will point at your product: the agent has access to secrets because it needs them to do its job, it processes untrusted input because that is its job, and those two requirements are in direct conflict.

The scale of the problem has been measured. A large-scale study of 12,230 tools across 1,360 MCP servers found the ecosystem "rife with real-world exploitable gadgets," and put the root cause on MCP lacking context-tool isolation and least-privilege enforcement. Read that as: the protocol does not protect you. Your implementation has to.

So here is what I build into every server, and what you should ask any developer who builds yours:

• Least-privilege scopes, no omnibus scope. The spec's guidance warns against wildcard or "full-access" scopes. A stolen token should be able to do one narrow thing, not everything.
• Enforce permissions on the server, never in the prompt. OWASP's advice is to enforce restrictions server-side. If a tool should not delete records for a viewer-role user, the server refuses, regardless of what the assistant asks for.
• Return structured data, not free text. Constraining tool output to a JSON schema removes most of the room for injected instructions to ride along.
• Never put customer-supplied text where an assistant reads instructions. Tool descriptions are code. Customer data goes in fields that are clearly data.
• Destructive tools require confirmation and are marked as such. The annotation is not decoration. Clients use it to decide when to ask the human.
• Rate limits and audit logs per user, from day one. You will need both for the first incident and for the first enterprise deal.

And the mirror image, if you are the one connecting an assistant to other people's servers inside your own product: treat every tool result as untrusted input, allowlist the servers you connect to, and keep the assistant that reads outside content away from the credentials that matter. That is the exact lesson from the April research, and it is the one most teams learn the expensive way. I wrote about the broader version of this in is your vibe-coded MVP a data breach waiting to happen.

What a realistic timeline looks like

For a SaaS with a clean, documented API and working OAuth, I plan a credible v1 remote MCP server in about one to two weeks: a handful of read tools, two or three write tools with confirmation, scopes, logging, and a test harness that runs each tool the way a reviewer will. If OAuth or per-user permissions do not exist yet, add the time to build them properly, because that work is the product. Directory review comes on top and varies with the queue. Anthropic's portal requires a Team or Enterprise organization to submit, and walks you through documentation, a privacy policy, test credentials, and seven policy acknowledgments before you can send it in.

The part that takes longest is rarely code. It is deciding which actions an agent should be allowed to take on a customer's behalf at all. Get that decision made with whoever owns the product, write it down, and the build goes fast.

Do you need a developer for this?

If you have a senior backend engineer who understands OAuth and has the time, they can do this with the official SDK and the spec's security pages. If you do not, this is a scoped project with a clear finish line, which is the kind of work I take on. I have written about whether you still need to hire a developer in 2026 and the cost difference between a freelancer and an agency if you are weighing that.

Most of the AI agent projects that fail fail on integration, permissions, and guardrails rather than on the model. An MCP server is where all three of those meet. Done right, it is the cheapest way to make your product show up wherever your customers' assistants already are, without becoming the weak point in their security. If you want it built properly, see what I work on or book a call.