Garenne Bigby

Home / Build / AI / To MCP or Not to MCP: Should Your SaaS Expose a Model Context Protocol Server?

To MCP or Not to MCP: Should Your SaaS Expose a Model Context Protocol Server?

What MCP servers actually do for your SaaS, what they cost, and when to ship one.

Over the past year, I’ve shipped three Model Context Protocol (MCP) servers across two products: the DYNO Mapper Platform MCP, the IATO Platform MCP, and the IATO WordPress MCP. That work has given me a pretty grounded view of what MCP actually is, what it gets you, and what it costs you. This post is the explainer I wish I’d had on day one, written for SaaS founders and product leads weighing whether to add an MCP server to their roadmap.

What an MCP server actually is

Model Context Protocol is an open standard, introduced by Anthropic in late 2024 and adopted broadly across the AI ecosystem since, for connecting AI assistants to external tools and data. If you’ve heard the line “MCP is USB-C for AI integrations,” that’s roughly the right mental model. One standard plug, many devices.

In practice, your MCP server exposes a list of capabilities (tools your AI can call, resources it can read, prompts it can use) to any compatible AI client. The AI assistant discovers what your product can do at runtime, decides when to call it, and surfaces the results back to the user inside whatever interface they’re already in: Claude, ChatGPT, Cursor, a custom agent, and so on.

Concrete example: instead of a user copying a sitemap URL out of DYNO Mapper into Claude, asking Claude to summarize it, then pasting the answer somewhere else, the assistant just calls our MCP server, pulls the sitemap structure directly, and reasons over it in place. Fewer tabs, fewer steps, less friction.

MCP vs. a traditional API

I get this question constantly: “Don’t we already have an API for this?” Yes, and you should keep it. But APIs and MCP servers are built for different consumers.

A REST or GraphQL API is designed for developers writing code. The integration logic, error handling, parameter shaping, and auth all live in the developer’s head and codebase. An MCP server is designed for AI agents reasoning at runtime. The server itself describes what each tool does, what parameters it expects, and what it returns, all in a format an LLM can read and act on.

A few practical differences worth knowing:

  • Discovery is built in. With an API, integration is a project. With MCP, the agent introspects your server and figures out the surface area itself.
  • One integration, many clients. Build once, work in Claude Desktop, Claude Code, ChatGPT, Cursor, and a growing list of agent frameworks.
  • The caller is non-deterministic. Code calls your API the same way every time. An LLM might call your tool in ways you didn’t quite anticipate, with creative parameter values and unexpected sequencing.
  • Auth and transport are standardized. MCP defines patterns for OAuth, scoped tokens, and HTTP/SSE or stdio transports, so you’re not reinventing them per integration.

The simplest way to think about it: your API is for systems you can predict. Your MCP server is for an agent making judgment calls on a user’s behalf.

The case for building an MCP server

Here’s what I’ve actually seen play out across our three servers.

Distribution shifts to where users already are. People aren’t going to leave Claude or ChatGPT to come to your dashboard for a quick task. If your product can be invoked from inside the assistant they’re already using, you become the answer when they ask “how do I audit this site’s structure” or “can you publish this to my WordPress blog.” That’s a new top-of-funnel channel that didn’t exist two years ago.

One surface beats N integrations. Before MCP, every AI integration was a custom build. You’d write a Claude integration, a ChatGPT plugin, a LangChain tool, and they’d all drift. With MCP, the same server works across compatible clients. The maintenance math gets dramatically better.

Friction collapses for power users. The agentic workflows people actually want involve chaining multiple tools together. With our IATO WordPress MCP, a user can ask Claude to draft a post, run it through a content audit, optimize it for SEO, and publish it, all without leaving the chat. That isn’t a feature you can replicate in your own UI without rebuilding Claude.

You signal that you’re built for the next platform shift. Right now, “we have an MCP server” reads similarly to “we have a public API” did in 2010. It’s a credibility marker for technical buyers. Within the next year or two, I’d expect it to be table stakes for any serious B2B SaaS.

The case against, or at least the trade-offs nobody mentions upfront

Now the honest part. MCP isn’t free, and a few of the costs aren’t obvious until you’ve shipped.

Token economics are real. Every tool definition your server exposes gets loaded into the agent’s context window. Every call and response eats more tokens. If your server exposes 40 tools with verbose descriptions, you’re burning context (and dollars) before the user has even asked anything. We’ve spent real effort trimming tool descriptions and being thoughtful about what gets exposed by default vs. on demand.

Your UI stops being your moat. A beautifully designed dashboard turns into a JSON schema. For products where the interface is most of the value, that’s a strategic problem. For products where the interface is mostly a way to get to the data and actions underneath, MCP is a gift.

Authorization gets harder. Scoping what an AI can do on a user’s behalf is meaningfully trickier than gating a human. A human won’t accidentally delete 400 pages because they misread a prompt. An agent might. We’ve leaned heavily on scoped tokens, explicit confirmation patterns for destructive operations, and audit logging.

Hallucination and misuse risk. Agents will call your tools in ways you didn’t design for. Wrong parameters, weird sequencing, attempting operations that don’t quite make sense. Your server has to be defensive in ways an internal API doesn’t.

Observability is a new discipline. “The AI did something strange” is a hard support ticket. You need logging that captures the agent’s reasoning context, not just the request payload, or you’ll spend hours reconstructing what happened.

The spec is still moving. Auth flows, streaming, server registries, and discovery patterns are all evolving. We’ve had to update our servers multiple times to keep current. That’s manageable, but it’s not zero work.

It’s another surface to maintain. You already have an API, SDKs, webhooks, and probably a Zapier integration. MCP is one more thing. Make sure you have the team bandwidth before you commit.

When MCP makes sense (and when it doesn’t)

Based on what I’ve seen, here’s my rough heuristic.

Strong fit:

  • Data-heavy products where the value is in the data, not the UI (analytics, SEO tools, CRMs, ticketing systems, knowledge bases)
  • Productivity and workflow tools that show up inside chains of other tasks
  • Developer tools, where the user is already comfortable with agentic workflows
  • Anything with a clear, well-scoped set of read and write operations

Weaker fit:

  • Products where the UI is the value (design tools, video editors, real-time collaboration canvases)
  • Highly visual or spatial work that doesn’t translate well to text-based tool calls
  • Products where the user really does need to see the whole interface to make decisions

Middle ground:

  • Expose a slice. Read-only access, reporting, search, and lookups are low-risk ways to get into MCP without betting the whole product on it. You can always expand the surface area once you see what users actually do with it.

A pragmatic approach if you decide to ship one

If you’ve talked yourself into building one, a few things I’d do differently if I were starting over:

  1. Start narrow. Ship a small set of read-only or low-risk tools first. See what gets called, what confuses the agent, and what users actually do. Don’t expose your full API surface on day one.
  2. Reuse your existing API. Our MCP servers are mostly thin adapters over the same endpoints our web app uses. Don’t build a parallel backend.
  3. Decide hosted vs. self-hosted early. Enterprise customers will ask. Have an answer about where the server runs, who sees the data, and how auth works.
  4. Instrument from day one. Log which tools get called, with what arguments, and what the outcomes are. You’ll want this data for prioritizing what to build next.
  5. Write your tool descriptions like documentation, not marketing copy. The agent is your reader. Tell it exactly what each tool does, what the inputs mean, and what it returns. Vague descriptions lead to wrong calls.
  6. Plan for the spec to change. Build with the assumption you’ll be updating your server every few months for a while.

The strategic bottom line

The honest answer to “should we build an MCP server” is “probably, eventually, and maybe a small one now.” It isn’t all-or-nothing. Most SaaS companies will end up with both an API and an MCP surface, the same way most ended up with both a web app and a mobile app a decade ago.

The real question isn’t “MCP or API.” It’s “where do our users want to invoke our product from?” If the answer is increasingly “from inside an AI assistant,” then you need a presence there, and MCP is the cleanest way to build one.

The companies that show up inside AI assistants over the next 18 months will quietly own a new distribution channel. The ones that don’t will find themselves explaining, again and again, why users have to leave their AI to get to their product.

I’d rather be on the first list. That’s why we built three.