Your MCP server is an interface, not an integration

If a customer asks whether they can point an AI agent at your product, the answer they want is yes. What follows is not really an engineering problem. It is a decision about what an agent is allowed to do inside a customer's account, and what that customer sees while it happens. The Model Context Protocol will not settle either question for you, and it is honest about that.

The specification's section on how tools reach a user is short. Tools are model-controlled: the model discovers them and calls them. Then it says that implementations are free to expose tools through any interface pattern that suits their needs.

The protocol itself does not mandate any specific user interaction model.

That sentence is why this is design work. Everything the protocol leaves open is the part your customer actually experiences.

Should your SaaS have an MCP server?

Eventually, if technical buyers are already automating against your API, yes. The weak reason to build one is that a competitor announced theirs. The strong reason is that you can name three jobs a customer would genuinely hand to an agent, and you are willing to be answerable for how those jobs go.

Start there, because the tool list is a product surface, not a config file. Every tool name, every description, every parameter you expose is read by a model deciding what to do next. You are writing for a reader who will never ask a colleague what you meant. That is closer to writing documentation than to shipping an endpoint, and most teams hand it to whoever has spare sprint capacity.

An agent cannot see your interface

Think about where the safety actually lives in your product today. The disabled button. The confirmation modal on delete. The amber banner when an account is near a quota. The two-step flow before a plan downgrade. None of it exists on the tool path. If your guard against dropping a production database is a dialog box, an agent has no guard.

The protocol anticipated the obvious patch and closed it. Tools can carry annotations that describe how they behave, but the spec warns that clients must treat tool annotations as untrusted unless they come from trusted servers. You cannot assume any client will warn anyone just because you flagged an operation as dangerous.

So the first real MCP decision is a subtraction. Read-only to begin with. Destructive operations behind a separate, deliberately boring tool that has to be asked for by name. Anything irreversible stays off the list entirely until you have watched the reversible things behave for a few months.

Where the human goes

The specification does want someone in the loop. It says there should always be a human able to deny a tool invocation, and it asks applications to make clear which tools are exposed, to show a visual indicator when one is called, and to confirm sensitive operations before they run.

Read that carefully, though. Those obligations land on the client, which is whichever assistant your customer happens to be using. You do not control it, and clients vary. The question for your product is therefore what you show afterwards, inside your own interface, where you do have control. If an agent changed a setting overnight, somebody needs to be able to establish the next morning what ran, with what inputs, and on whose authority. That is an activity log, and it is the same design problem as showing customers what their usage is costing them: it gets treated as logging, and it belongs in the interface.

There is a second reason to build that view early. People quietly abandon automation they cannot verify, which is the pattern behind AI features nobody ends up using. It bites harder here, because the stakes are a customer's live environment rather than a draft email.

This is arriving on your website too

On 2 November 2026 the W3C's Web Machine Learning Community Group published a fresh draft of WebMCP, an API that lets an ordinary web page offer JavaScript tools to an agent. It is a Community Group draft. It is not a W3C standard and not on the standards track, so treat it as a direction rather than a deadline.

The direction is the part worth noticing. What a machine is permitted to do on your site, and what it is told while doing it, stops being a question for the API team and becomes a question about your signup, your plan comparison, your docs. Technical buyers already read the documentation before they speak to anyone. Increasingly their agents read it as well, and act on it.

The question underneath

"Should we have an MCP server" is the wrong sentence to argue about in a planning meeting. The useful one is harder to answer: what would we let a stranger's software do to a customer's account, unattended, at three in the morning, and how would that customer find out?

A team that can answer that has done the difficult part, and the build is comparatively dull. A team that cannot has not shipped an integration. It has shipped a product with no interface, and left the designing to whoever turns up.