Guide · Architecture
MCP server vs MCP gateway: what you need for production agents
An MCP server offers one system's tools to an AI client over the Model Context Protocol. An MCP gateway is a single MCP server that sits in front of many systems: it holds the credentials, decides what each agent may do, limits what it may spend, and records every call. One server is enough for a developer trying one tool on a laptop. A production agent that touches business systems needs the gateway's controls, whether you buy them or build them. actionlake is a hosted MCP gateway with 1,000+ connectors behind one URL.
What an MCP server is
The Model Context Protocol is an open standard for how an AI application discovers and calls tools. An MCP server publishes tools such as "list invoices" or "create a ticket", and an MCP client, such as Claude Code, lets the model call them.
Most MCP servers wrap one product's API. You run one for GitHub, one for your accounting system, one for your help desk. Each has its own install, its own credential and its own idea of permissions. Many run on the user's own machine and read an API token from an environment variable.
That is fine for one person and one system. It changes when there are ten systems, twenty agents and an auditor.
What an MCP gateway adds
An MCP gateway is one remote MCP server that fronts many systems. The client connects once. Behind that one connection the gateway does the work each standalone server leaves to you.
| Concern | Separate MCP servers | MCP gateway |
|---|---|---|
| Credentials | One token per server, often in env files on each machine | Held once, sealed, never shown to the model |
| Permissions | Whatever the token allows | Per agent key: read-only, one service, one action |
| Spend and rate limits | None, or per server | A cap per key, refused before the call is sent |
| Approvals | Rarely | Chosen actions wait for a named person |
| Record of actions | Each server's own logs, if any | One ledger across every system |
| Tools the model sees | Every tool of every server | A small fixed set, with search |
| Questions across systems | The model fetches and joins rows itself | The gateway joins and returns the answer |
The four problems a gateway solves
1. Credentials end up in the wrong places
With one server per system, each machine that runs an agent holds a copy of each token. Tokens land in dotfiles, CI secrets and, sometimes, prompts. A gateway holds them in one credential vault. The agent holds a gateway key, which you can scope and revoke, and never a vendor token.
2. An agent with access has all the access
Most vendor tokens are broad. A gateway puts its own permission layer in front: this agent may read Xero, that one may only create tickets in one PSA. In actionlake a key's allowed_actions takes an action (autotask.tickets.create), a whole service (xero.*), an effect class (read:*) or an effect on one service (hubspot_crm.read:*). See AI agent permissions.
3. Too many tools
Every tool's name and schema goes into the model's context. Connect a few servers with hundreds of tools each, and the list is longer than the model can choose from reliably. Accuracy drops past a few dozen tools; this is tool overload. A gateway can keep the visible surface small. actionlake shows eight tools whatever is connected: the agent searches with find_actions, reads one schema with get_action, and runs it with do. The 289,000+ actions behind them never enter the context at once.
4. Nobody can say what happened
When something goes wrong, three questions come up: what did the agent do, who allowed it, and why did it think that was right? Separate servers leave separate logs or none. A gateway records every call in one place. actionlake records each one in a hash-chained ledger, with the agent's own one-sentence reason. See AI agent audit logs.
When a single MCP server is enough
Be honest about the small case. A standalone server is the right choice when:
- one developer is exploring one product's API on their own machine;
- the token is read-only or the data is not sensitive;
- nothing needs an audit trail, a budget or a second person's approval;
- the system's vendor publishes a server and you need nothing beyond its tools.
When you need a gateway
You need gateway controls when any of these is true:
- agents act on behalf of a business, not one person;
- an agent can write: create invoices, close tickets, change users;
- more than one system is involved, or one question spans two systems;
- someone will ask later who did what, and why;
- a runaway loop could spend money or burn a vendor's rate limit.
A checklist for choosing a gateway
| Question to ask | What a good answer looks like |
|---|---|
| Where are vendor credentials stored, and can the model ever see them? | Encrypted per tenant; never returned by any endpoint; never in a prompt |
| How fine are permissions? | Per key, down to one action, and a key can only hand on what it holds |
| Are spend limits enforced before or after the call? | Before. A soft limit that lets the crossing call through is not a cap |
| Can a person approve chosen actions? | Yes, per action pattern, with a named approver, and the run waits |
| Is the record tamper-evident? | Hash-chained and sealed, with a way to verify a single run |
| How many tools does the model see? | A small, fixed number, with search |
| Can it answer across systems without dumping rows into the context? | A join on a shared identity, returning only the answer |
| What is the billing unit, and what is free? | A clear unit; failures and cached answers free |
| Is it a remote server with OAuth? | Streamable HTTP, OAuth 2.1, dynamic client registration |
| Can you dry-run a call? | Validate inputs, permissions and cost without sending anything |
Where actionlake fits
actionlake is an MCP gateway that connects AI agents to every system a business runs. One URL, https://connect.actionlake.com/mcp, gives any MCP client eight tools: help, find_actions, get_action, do, ask, check, cost and account. Behind them are 1,000+ connectors and 289,000+ actions, counted from our signed service files. Only do and ask can cost money, and only for upstream calls actually sent to a vendor.
It is also a REST API at https://api.actionlake.com/v1, with the same eight operations. The two surfaces are one implementation.
What it does not do, by design: there are no event triggers, webhooks or polling triggers. Agents and schedules start the work. A scheduled plan that asks "what is new since the last run?" covers most trigger cases.
If you want to build a gateway yourself, the checklist above is the specification. If you would rather start with one, the quickstart takes a few minutes, and the platform page shows the rest.
Frequently asked questions
Is an MCP gateway the same as an API gateway?
No. An API gateway routes and rate-limits HTTP traffic to your own services. An MCP gateway speaks MCP to AI clients, holds third-party credentials, and adds agent-specific controls: per-agent scopes, approvals, a small tool surface, intent on each call and joins across systems.
Can I use an MCP gateway and a vendor's own MCP server together?
Yes. Your client can connect to both. Calls through the vendor's server are outside the gateway's scopes, caps and ledger, so keep the vendor server read-only, or route those actions through the gateway.
Does a gateway add latency?
It adds one hop and a permission check. A cached read can be faster than calling the vendor at all, because the gateway answers it without sending anything. actionlake records, for every run, how long the vendor took and how long the whole call took, so you can see the split.
Do I need a gateway for a single agent?
Not always. If that one agent can write to a system that matters, you still want scopes, a cap, approvals and a record. Those are the gateway's controls, at any scale.
Try it on your own systems.
100,000 free calls a month. No card. Hard caps on every key.
