What is an MCP gateway?

The first MCP server in a company usually appears the way ours did: an engineer wires an agent to a database on a Tuesday, and by Friday it’s answering questions nobody wants to type SQL for.

That’s the good news. The uncomfortable follow-up question arrives a few weeks later: what else can agents reach now, with whose credentials, and who’s keeping the list?

An MCP gateway is the piece of infrastructure that makes those questions answerable. It sits between agents and MCP servers as a single control point: a catalog of approved tools, access rules deciding who may call what, credential brokering so agents never hold raw secrets, a log of every call — and, in most implementations, one endpoint for agents to connect to instead of a dozen separate servers. If you run more than a handful of agents or tools, it’s the difference between an agent platform and a pile of one-off integrations.

First, what MCP is

MCP, the Model Context Protocol, is an open standard for connecting AI agents to tools and data, stewarded under the Linux Foundation since late 2025. An MCP server wraps a system (a database, a ticketing system, an internal API) and describes its capabilities in a form any MCP-compatible agent can discover and call. The standard solved the integration problem: instead of every agent framework needing custom connectors for every system, both sides speak one protocol.

Solving the integration problem this well created a governance problem. Connecting an agent to a new system used to take an engineering sprint, which acted as an accidental review gate. Now it takes a config line. The friction that quietly protected you is gone.

What does an MCP gateway do?

Four jobs, roughly in the order they start to hurt:

1. A catalog instead of sprawl. MCP servers multiply quietly: each one gets added for a good reason, and a few months later nobody has the full list of what agents can reach. The gateway is the registry — every tool is listed and owned in one place, and agents that go through it discover only what the catalog holds.
2. Access control per team and user. The finance team’s agents may query the finance warehouse; the support team’s may not. Tool access becomes an assignable permission, scoped at org, team, group, or individual level, instead of a property of whoever happens to know the server’s address.
3. Credential brokering. The database credential lives at the gateway, not in each agent’s config. Better still is per-user auth: each user connects the system under their own identity, so the agent’s query runs with the calling user’s permissions and the row-level security your data platform already enforces keeps applying. An agent asking on behalf of an analyst sees what the analyst sees: no shared super-account.
4. An audit trail of actions. Model traffic is words; tool traffic is actions — queries run, tickets filed, records changed. “What did agents do last Tuesday?” has to have an answer, and the only place it can be recorded uniformly, across every tool, is one control point every call passes through.

None of this slows the Tuesday-afternoon experiment. It changes what happens after it works.

Why agents make this urgent

A chat assistant that only talks can leak information. An agent with tools can act — and it acts at machine speed, in loops, without a human reading every step.

Tool calls are actions, not answers.
Governance that only watches model traffic
sees the words and misses the deeds.

The first risk to reach you is a mundane one: over-permissioning. A shared service account wired into an MCP server quietly grants every agent user the union of all its permissions. Nobody decided that; it is what happens when per-user access control doesn’t exist at the tool layer. Deliberate attacks come later, and the MCP spec itself says tool descriptions should be treated as untrusted input, which is why a vetted catalog is the standing defence against servers that aren’t what they claim to be.

MCP gateway vs LLM gateway

Same governance instinct, different traffic. An LLM gateway governs model calls: which models, whose budget, what leaves the network in a prompt. An MCP gateway governs tool calls: which systems an agent may touch, with whose permissions. An agent workflow crosses both in one run, calling a model to decide and a tool to act, which is why the two end up deployed together and why bolting on only one leaves half the traffic dark.

When do you actually need one?

Honest answer: not on day one. One developer, one MCP server, one experiment — a gateway would be ceremony. The real triggers:

• Agents reach non-developers — people who can’t audit what a tool does before pressing it.
• A second team wants agents, and its tool list shouldn’t match the first team’s.
• A tool touches a system with its own permission model (a warehouse, a CRM), and a shared service account would flatten it.
• Security asks “what can agents reach, and what did they do?” and the answer is a shrug plus a grep through scattered logs.

Most companies hit the second-team trigger sooner than expected, because a working agent demo travels fast internally.

How SecondStack handles MCP traffic

In SecondStack, MCP servers are managed objects, not config files: admins register them in the platform’s connector catalog (users see them as Connectors) and scope them org-wide, per team, per group, or per user, through the same team and user directory that governs model access. Agents and chat sessions then discover only the tools their user is entitled to.

The same principle runs beyond MCP: our Databricks integration uses per-user OAuth, so an agent’s SQL runs under the asking user’s own warehouse permissions and Unity Catalog’s audit trail keeps working. We also ship a first-party read-only analytics MCP server, so admins and team supervisors can ask usage questions (“which models did we spend on last week?”) through an agent instead of a dashboard — the same access model, applied to our own telemetry.

That’s another layer of the same stack (chat, agents, LLM gateway, guardrails, cost controls) described in why we built SecondStack. If you’re at the “the demo worked, now what” stage with agents, write to [email protected]. It is usually a short conversation: which tools your agents already reach, and whether a gateway in front of them would change anything at your current scale.