MCP servers are a button now. Here is what actually costs money.

There is a moment in every new technology where the hard part becomes a button. For MCP servers, that moment has arrived. Point a generator at your API, and out comes a working server that an AI assistant can call. It feels like magic, and it is genuinely useful.

It is also a trap, because the generated wrapper is the cheapest part of the whole endeavor. The wrapper was never where the cost lived. The cost lives in the decisions the generator cannot make for you, and those decisions are exactly the ones that determine whether your MCP server is something you can put in front of customers or something you quietly take down after the first incident.

Let me walk through where the money actually goes.

Tool design is the real product

A generator takes your existing API and exposes every endpoint as a tool. That sounds efficient. In practice it produces a server that an AI assistant uses badly.

Your API was designed for programmers who read documentation, hold context in their heads, and chain calls deliberately. An AI assistant is none of those things. It picks a tool from a name and a description, fills in arguments from a fuzzy understanding of the situation, and has no memory of how your endpoints relate to each other.

Good tool design means deciding which capabilities to expose and which to hide, naming them so an assistant chooses correctly, shaping the arguments so they are hard to get wrong, and writing descriptions that are instructions rather than documentation. It often means collapsing five low level endpoints into one well shaped tool, or splitting one overloaded endpoint into three. This is design work, and it is the difference between an assistant that helps and one that flails. No generator does it for you.

Auth is where the stakes live

The generated server probably authenticates with a static token in an environment variable. That is fine for a demo on your own machine. It is not fine the moment a real assistant, acting for a real user, calls your tools against real data.

Production auth for an MCP server means OAuth 2.1, so that access is scoped, revocable, and tied to a real identity rather than a shared secret that lives forever in a config file. It means DPoP, so that a stolen token is useless without the key it was bound to. It means row level access, so that an assistant acting for one user can never reach another user’s data, no matter how the request is phrased.

These are not optional hardening steps you add later. They are the foundation. An MCP server without real auth is a hole in your perimeter that talks. Getting this right is careful work, and it is most of what separates a safe server from a dangerous one.

Hosting is a forever cost, not a one time one

A generated server runs until you close the terminal. A production server runs until you decide to retire the product, which might be years.

That means uptime you can stand behind, secrets stored somewhere better than a file, logs you can actually search, deployments that do not require a person to babysit them, and recovery when a region falls over. It means someone is responsible at three in the morning. Hosting is not a line item you pay once. It is an ongoing operational commitment, and pretending otherwise is how teams end up with a server nobody owns.

Evals keep it honest over time

Here is the uncomfortable part. An MCP server can pass every test on launch day and degrade silently over the following months, because the assistants calling it change, the prompts around it change, and the world it operates in changes.

The only defense is evals. A suite of representative interactions, with expected behavior, run continuously, so that you find out an assistant has started misusing a tool before your customers do. Without evals, your MCP server’s quality is whatever it happened to be the last time someone looked, which could have been a long time ago.

Governance is what lets you sleep

Once an assistant can act through your tools, you have to be able to answer hard questions. What did it do. On whose behalf. Was it allowed to. Can you prove it.

That requires a hash chained audit trail, where every tool call is recorded in a way that cannot be quietly altered after the fact. It requires clear boundaries on what each integration is permitted to touch. It requires the ability to revoke access cleanly when something looks wrong. Governance is the layer that turns “we think it is fine” into “we can show you exactly what happened”, which is the only acceptable answer when money or sensitive data is involved.

What the button actually saved you

So what did the generator save? It saved you the boilerplate of translating your API into the MCP shape. That is real and worth taking. But it left untouched every decision that carries weight: which tools to expose and how to shape them, how to authenticate and authorize, where and how to run it, how to measure quality over time, and how to prove what happened.

That is the work that carries the weight. An MCP server you can put in front of customers needs OAuth 2.1, DPoP, row level access, evals, and a hash chained audit trail built in from the first commit, and someone to carry the forever costs rather than discover them later.

The wrapper is free now. The judgment is not. We are a small studio in Montreal, and this is the kind of work we love. If you are building one, we would love to hear about it.