How to Ship an MCP Server for Your SaaS

Why this is a distribution decision, not an integration chore

Your product has a UI for humans and an API for developers. An MCP server adds a third surface: the assistant your customer already has open. The difference matters commercially, because the thing choosing whether to call you is no longer a person comparing tabs — it is a model comparing tool descriptions.

That reframing decides most of the design choices below. You are not writing an integration; you are writing something that has to be picked, by a reader that will not investigate, from a list of alternatives it can see all at once.

Decide what to expose before you write any code

The instinct is to mirror your REST API. Resist it. An API is designed for a developer who reads documentation and composes calls; an MCP server is consumed by a model that will call one tool, look at the result, and decide what to do next.

Three questions narrow it quickly. Which jobs do customers actually ask an assistant to do — not which endpoints exist? Which of those jobs can be completed in one call rather than four? And which results are compact enough to be useful in a context window, rather than a 400-row JSON dump that crowds out everything else?

A good first server is three to six tools that each finish a job: find the thing, summarise the state of the thing, make the small safe change. Read-only tools are a legitimate v1 and they ship a week earlier.

Scope permissions like an API key, not a docs page

An MCP server exposes real capability to a system that can be talked into things. Assume any tool you publish will eventually be invoked with arguments you did not anticipate, from a conversation you cannot see.

Practically: authenticate the connection to a specific account, not to your service generally. Give each tool the narrowest scope that lets it work — the search tool does not need write access because the update tool exists. Validate arguments server-side against the schema rather than trusting that the model respected it. And put the irreversible actions behind a confirmation step your own application owns, not behind an instruction in a prompt.

Rate limit per connection. A model in a retry loop is an unusually enthusiastic client.

Write the tool descriptions as if they were the product

This is where most servers fail, and the failure is silent: the model simply never calls you. It has no way to discover that your tool was the right one except the sentence you wrote about it.

Name one job per tool. Describe when to use it and when not to — "use for invoices; for subscription changes use billing_update instead" saves more wrong calls than any amount of parameter tuning. Prefer enums to free-text strings so the model cannot invent a status that does not exist. And give an example argument in the description, because an example is worth three sentences of specification.

Then test with the assistants your customers actually use. The same server behaves differently across clients, and "it works in my terminal" is not evidence about the surface your buyers are on.

Instrument it from day one

Log every call: which tool, which arguments, what came back, how long it took. Without that you cannot answer the only questions that matter — which tools get used, which get called and then abandoned because the result was unusable, and which are never chosen at all.

The abandoned ones are the most informative. A tool that gets called and whose result does not lead anywhere is usually returning too much, too little, or the wrong shape, and it is a cheaper fix than adding features nobody asked for.

What to ship first

A read-only server with three well-described tools, scoped to one account, logged, and tested inside two clients. That is a week of work, it is safe to publish, and it will teach you more about what customers want automated than a quarter of planning will.