The case for MCP proxies

Almost every software vendor ships an MCP server now or is in the process of creating one. That’s great for your AI assistants. It’s bad news for IT.

Here’s how it usually goes. Sales ops connects Claude to the CRM’s MCP server. Finance connects the ERP’s. Someone pastes an API key into a config file and shares it so the team can “just try it.” A month later you have a dozen direct connections, three shared keys, and nobody can tell you who asked the AI to do what.

Nobody did anything wrong. But a direct line to a vendor server is fine for a demo and wrong for a company. My recommendation: every MCP server your people use, vendor-built or homegrown, runs behind one governed gateway.

What can’t you see when AI connects directly to vendor MCP servers?

At Celigo we govern AI with five questions, answered once at the platform level: what can it see, what can it do, how is the data handled, who’s accountable, and can we audit it. The opposite of that is a direct connection answers those on the vendor’s terms, one server at a time. In practice that creates problems that look like:

• One identity for ten people. The fastest way to connect a team is one service account. Now everyone acts as that account, with all its permissions.
• Logs that name the app, not the person. The vendor’s log says the integration user did something at 2:14 pm. It doesn’t say it was a customer success rep asking about a refund.
• Every tool, handed to the model. Read tools, write tools, admin tools. “Allowed actions” is where IT pushes back hardest, and they’re right to. In our greatest dreams, AI can do everything for you. That’s also IT’s worst nightmare.
• No off switch. When something goes wrong, you revoke keys app by app and hope you found them all.
• A token bill with no names on it. Anthropic’s engineering team measured a typical five-server setup at 58 tools and about 55,000 tokens of definitions before the conversation even starts. Somebody spent a million tokens last month, and you have no idea what it was for.

What changes when you proxy MCP servers through a gateway?

With Celigo MCP Management, you connect the vendor’s server to the MCP Gateway, pick the tools you want to expose, and they show up on your Celigo MCP server next to anything you built in Celigo.

Your people stop talking to the vendor server directly. They talk to the gateway, and its rules apply to everything behind it. They sign in through your identity provider, like Okta or Microsoft Entra ID, and see only the tools assigned to their group or role. Every request lands in Celigo’s log with their name on it. New vendor tools don’t appear until you add them. And if you need to stop everything, you turn off one server instead of hunting for keys.

Your team still works in Claude, ChatGPT or Cursor. The governance moved. The work didn’t.

What does an MCP gateway look like in a real workflow?

Say a customer success rep asks Claude: “Order 10418 shipped last week, but the customer says the refund never showed up. What happened?”

That question spans two systems. The order and the credit memo are in NetSuite. The refund is in Shopify.

Connected straight to both vendor servers, the assistant has every tool from each one in context. It searches orders in one system, searches refunds in the other, pulls raw records back through the conversation, and then guesses how they line up. Your data team knows the ERP field doesn’t match the storefront field. Claude doesn’t. So it makes something up. And both calls ran under a shared key, so neither vendor knows who asked.

Through the gateway, the rep signed in with Okta, so the call is theirs. Their group sees a handful of read-only tools, and nothing that writes. Better still, the question can hit one composite tool built in Celigo that joins the order, the shipment and the refund, then comes back with a verdict, the evidence and the next step. The model reads three lines instead of three payloads. (Illustrative example.)

The model matters. What matters more is how the information reaches it.

Proxying is where tool design starts

Once a vendor server sits behind the gateway, you control what the model sees. You can switch off tools a role doesn’t need. You can rewrite a vague tool description so the model knows exactly when to use it. And you can replace the vendor’s generic “update record” with a Celigo tool that does one business job, with reads split from writes.

That last move is where the savings are. A vendor server is organized the way software is sold. A composite tool is organized the way work is done, so the model makes one call instead of six. Anthropic published one example where keeping intermediate data out of the model’s context took a workflow from 150,000 tokens to 2,000. That’s one example, not a promise. But it shows where the cost hides.

Is an MCP proxy always the right choice?

Proxying is the right default, but it isn’t magic. Two limits to note:

• The vendor still sees one identity. Proxied calls reach the vendor through the credentials on the MCP connection, so Celigo’s log knows the person and the vendor’s log does not. Scope that connection to what your users need as a group. If every user has to reach the vendor app as themselves, a direct connection may be the better fit for that one server.
• The server must be reachable over HTTP at a public address. Local-only MCP packages cannot be proxied.

How do you start proxying MCP servers?

Start with one server, not all of them. Don’t proxy everything on day one.

1. Pick the vendor MCP server with the most users and the least oversight.
2. Put it behind the gateway and connect your identity provider.
3. Switch off every write tool.
4. Read the request log for two weeks. You will learn more about how your people actually use AI than any survey will tell you.
5. Turn tools back on one role at a time, and replace the noisiest ones with composite tools.

That is how agents earn autonomy instead of being handed it.

Ready to take action? Reach out to our forward engineering team to learn more and get started.