> ../patterns/tool_gateway.md
The first agent usually gets its tools wired in directly: an API key for the CRM, a database connection, a function that sends email. By the third agent the same integrations exist three times, with three sets of credentials and three different ideas of what is allowed. By the tenth, nobody can say which agent can touch what. The tool gateway pattern fixes this before it starts: every tool call from every agent goes through one service.
§ 01 · What the gateway does
◆ Discovery. Agents ask the gateway which tools exist for their task instead of loading every tool definition up front. Fewer tools in context means better tool choice and lower cost.
◆ Identity. Every call carries which agent made it and on whose behalf. The gateway, not the agent, holds the real credentials for each system.
◆ Permissions. Each agent gets an allow list of tools and, where it matters, of actions within a tool, such as read orders but not refund them.
◆ Limits. Rate limits, value limits and daily caps are enforced in the gateway, in code, where a confused model cannot talk its way past them.
◆ Approval. Calls that need a person go into a queue instead of executing. See the approval queue pattern.
◆ Logs. One record of every call: agent, tool, arguments, result, time. This is the record you need when someone asks what the agent did.
◆ Switches. One place to turn off a tool for every agent at once when a system misbehaves.
── ◆ ──
§ 02 · A real example at scale
Uber described its version in November: an MCP Gateway hosting over 800 MCP servers and over 5,000 tools, with incremental discovery so agents search for the tools they need instead of loading all of them (Uber Engineering). You do not need that scale. The same idea works with a few agents and a dozen tools.
── ◆ ──
§ 03 · A small version you can build this week
◆ One service that exposes your tools, as MCP or as plain HTTP, and holds the credentials. Agents get a token for the gateway, never the system keys.
◆ A config file per agent listing its allowed tools and limits.
◆ Validation of every argument against the tool's contract before the call goes out. Our notes on tool contracts apply here.
◆ A log table with one row per call.
◆ A flag per tool to disable it.
That is a few days of work, and it pays back the first time you need to rotate a key, find out why an agent did something, or stop one tool in a hurry.
── ◆ ──
§ 04 · What goes wrong
◆ The gateway becomes a single point of failure. Run it like any other critical service: health checks, retries with backoff, and a clear error the agent can handle. See what happens when an agent hits a 429.
◆ Permissions drift. Agents collect tools over time and nobody removes them. Review each agent's allow list when its job changes.
◆ Tool output is still untrusted. A gateway controls what agents can call. It does not make the data that comes back safe. Treat tool results as input, not instructions, as in the hijacked tool output.
◆ Logging secrets. Mask credentials and personal data in the logs from day one.
── ◆ ──
§ 05 · When you do not need it
One agent, two or three tools, one system. Wire them directly, keep the credentials scoped, and log the calls. Add the gateway when the second agent needs a tool the first one already has.
── End of pattern ──
If your agents already reach your systems in five different ways, a two week architecture audit maps them and gives you a plan to put one door in front. Details are on our Hire page.
ORBIRESEARCH