MCP Gateway
Foo Guard Gateway sits between an agent's MCP client and the MCP servers you connect. It checks each routed tool call, resource read, or prompt retrieval against the policy you reviewed, records its decision, and either forwards or stops the request. Decisions are deterministic: an LLM does not decide whether a request is allowed, flagged, or blocked.
How a request is checked
- Identify the agent. Gateway validates a workspace-specific agent credential. Revoked, expired, or invalid credentials are rejected before anything is sent upstream.
- Check the tool. Gateway compares the requested tool with the definition you reviewed, validates its arguments, and checks your allowlist and agent controls.
- Record the decision. The decision is stored before the request is forwarded. If that cannot be done safely, the request is not forwarded.
- Forward or stop. Allowed requests proceed. Policy violations are flagged and forwarded in Monitoring, or blocked in Enforcement.
What Gateway checks
- Tool allowlist (
tool_not_allowed): only the tool names you approve are allowed. A policy that allowsread_noteflags or blocksdelete_note. - Definition changes (
definition_changed): Gateway fingerprints each reviewed tool definition, including its schema and description, and compares it with the server's current catalog on every call. A changed, removed, or new tool produces a finding. - Argument validation (
arguments_invalid): arguments are checked against the reviewed input schema, including required properties, types, enums, lengths, and numeric ranges. - Deny rules and agent blocks: from a request in history, an administrator can deny one tool for one agent, or block an agent entirely. A block stops that agent's future routed requests in both modes.
See Gateway policy decisions for every rule, temporary exceptions, and the operational safeguards that stop requests in both modes.
Monitoring and Enforcement
Start in Monitoring to learn which tools your agents actually use. Violations are flagged and forwarded, and each request appears in history with its rule. When the policy matches real usage, switch a Team workspace to Enforcement to block violations before they reach the server.
Try it without risk
Connect the inert demo server https://fooguard.com/api/gateway/demo, allow read_note, and call delete_note. That tool only simulates a deletion. Monitoring flags and forwards the simulation; Enforcement stops it before forwarding. Never use a destructive production operation as your first enforcement test.
Plans
- Pro: one personal monitored connection to a public HTTPS MCP server. Violations are flagged as in-app alerts, not blocked.
- Team: up to eight servers per workspace, Enforcement, deny rules, temporary exceptions, agent blocks, signed webhooks, and agent credentials that expire after 1, 8, or 24 hours.
Compare plans on the pricing page.
What Gateway does not do
Gateway only sees traffic routed through it. An agent that still holds the upstream URL and credential can bypass it, so restrict direct upstream access when you need enforced protection. A gateway you can walk around explains why.
Definition-change detection covers the advertised definition. It cannot prove that a server implements what it advertises, or detect an implementation change that leaves the definition unchanged. Gateway supports public HTTPS MCP servers and a limited JSON Schema subset; private-network servers are not supported. Gateway is in beta.
How this fits the rest of the product
The MCP security scanner reviews your MCP configuration before an agent runs. Gateway checks the calls that agent makes once it is routed. Use both: scan the configuration in GitHub and CI, then monitor or enforce the tool calls it is allowed to make. Read how Gateway works for setup, investigation, and recovery guides.