Do you need an MCP gateway? Often, no

Do you need an MCP gateway, honestly

We sell one, so treat the rest of this accordingly. It is still worth writing, because the fastest way to make a category look untrustworthy is for every vendor in it to answer this question yes.

Most teams asking whether they need an MCP gateway do not need one yet. Buying early does not buy safety. It buys an administration surface: roles to define, restrictions to maintain, and a seat count to justify, in exchange for controlling a risk that has not shown up.

What follows is four situations where the answer is no, one where it is not yet, and the three events that genuinely change it.

No, if the accounts are genuinely personal

The clearest case. If each person is connecting their own account to their own assistant, and that account already carries exactly the access their job gives them, a gateway adds a checkpoint in front of a door they are already entitled to open.

An agent acting for a person inside that person's own permissions is not a new risk category. It is the same access, used faster. The thing worth watching there is blast radius on destructive actions, and that is better handled by the client's own approval prompts than by a procurement cycle.

No, if you are still finding out whether this is useful

A great many teams are two weeks into discovering whether agents help at all. Buying governance at that point answers a question nobody has asked yet, and it slows down the experiment that would have told you whether to care.

Find out the cheap way. Use the connectors already in the client, give it a month, and see what people actually reach for. If the answer turns out to be "not much", you have saved a budget line. If it turns out to be "constantly, and against the customer database", you have learned something specific enough to act on.

No, if the honest problem is shared credentials

This one comes up disguised as a gateway question and is not one.

If a single service account is pasted into several people's clients right now, that is worth fixing this week, and a gateway is only one of the ways to fix it. Individual accounts with the right permissions fix it too, often faster and for nothing.

The reason it matters more than it looks: once several people act through one identity, no logging downstream can tell them apart. Buying an audit trail that records the same shared account for everybody is buying a record of nothing. Fix the identity first, then decide whether you still have a governance problem.

No, if one trusted operator runs everything

A single team with a handful of systems and one person who sets things up does not need a control plane to know who has what. They know. Writing it down in a shared document is a legitimate answer at that size and it costs nothing.

We wrote the longer version of this case in running your own MCP servers, including the point where the self-hosted answer stops working. The summary: the cost of self-hosting is not compute, it is the per-person work of issuing credentials, removing them, and answering questions afterwards. That work scales with people multiplied by systems, while the server count scales only with systems.

Not yet, if you can still answer the three questions from memory

Here is the test that actually decides it, and it is not a headcount.

Ask yourself three things. Who may reach the system you would least like an agent to write to. How you would remove one person's access to it by tomorrow morning. And what an agent did with it last Tuesday.

If you can answer all three from memory, you do not need a gateway. You need to write the answers down somewhere other than your memory, and check again in a quarter. The moment any one of those answers becomes "I would have to ask around", the situation has changed and so has the answer.

The three events that change it

They arrive in a predictable order.

A second team. Access stops being self-evident once the people using a system are not all in one room. This is usually the first real signal, and it tends to be mistaken for a headcount threshold when it is actually a boundary count.

A departure. The first time somebody leaves and you have to work out what they still hold, you find out whether your setup has a revocation story. If the answer involves finding URLs that were pasted into clients, you have learned that the address was the credential all along.

A question from outside the team. Security, compliance or a customer asks what an agent did. Per-person setups produce per-person histories, which is a different artifact from an organization's audit trail, and the difference only becomes visible when somebody asks.

If one of those has happened

Then the question stops being whether and becomes which, and the useful axis is narrower than the feature grids suggest: what varies from one person to the next, and what the log can answer afterwards.

For what it is worth, Elaichi's answer is one organization-wide endpoint where the grant varies rather than the URL, so removing a member revokes every live grant in the same transaction as the membership change. Role and restriction changes are slower and we say so: about two minutes. The MCP gateway comparison puts that alongside four other approaches, with sources, including the places where somebody else is the better fit.

And if none of the three events has happened to you, close this tab. The built-in connectors are doing their job, and we would rather you come back when something has actually changed than buy a control plane for a problem you are not having.