What Is MCP Call Filtering? How to Filter MCP Tool Calls at the Gateway

The Model Context Protocol gives an AI agent a clean, standard way to discover and invoke tools. What it does almost nothing about is controlling which tools an agent should be allowed to use. Standard MCP exposes every registered tool to every connected client. The tools/list response is unfiltered, and the official MCP security best practices are explicit that the protocol does not enforce security at the protocol level. That gap is exactly where MCP call filtering comes in.

This guide is for the platform and security engineers, AI platform leads, and security architects who already run MCP servers and now need to filter MCP tool calls in a way that scales. It answers the question this page owns: how do you allow, block, and inspect which MCP tool calls an agent can make, and where should that enforcement actually live? You will get what call filtering is, the threats it addresses, the dimensions you can filter on, allowlist versus denylist posture, common policy patterns, the per-server-versus-gateway tradeoff, and the implementation details that decide whether your controls hold up in production.

What is MCP call filtering?

MCP call filtering is the practice of intercepting, inspecting, and selectively allowing or blocking MCP tool calls (and their responses) at the gateway that sits between an AI agent or client and the MCP servers it connects to. It enforces which tools an agent can see and invoke, with what parameters, under whose identity. In short, it turns an open protocol into a governed one. This is also known as MCP tool call filtering.

In practice, a filtering layer can act on several points in a tool call's lifecycle. What gets filtered typically includes:

• The tools an agent can discover - trimming the tools/list response so a model never even sees tools it is not entitled to use.
• The tools an agent can invoke - allowing or denying each tools/call request by tool name or server.
• The arguments of a call - inspecting parameters and payloads, and blocking or rewriting calls whose inputs violate policy.
• The caller's identity - binding every decision to a verified agent or user so the same tool can be permitted for one identity and denied for another.
• The response - inspecting or sanitizing what a tool returns before it reaches the model, for example redacting sensitive data.

The objects being filtered here are MCP tools: the discrete, callable capabilities an MCP server advertises. Call filtering doesn't change what those tools do. It governs who may reach them, and when.

Why MCP needs call filtering

The protocol gap: no identity-aware filtering by default

MCP was designed for interoperability, not authorization. When an agent connects to a server, it receives the full catalog of tools that server exposes, and the protocol itself has no native concept of filtering that catalog per identity or per agent. There is no built-in rule that says "this agent may call read_file but not delete_record." The specification is explicit that security is not enforced at the protocol level and that implementations must layer their own controls on top.

The same specification also forbids unsafe token handling. An MCP server must not accept tokens that were not issued for it, a pattern known as token passthrough, and it calls for minimizing the scope of any access granted, a posture the MCP security best practices set out as normative. Those rules describe the posture filtering should enforce, but they do not implement it for you. Without an added control layer, an agent that can reach a server can, in principle, call everything that server offers.

Threats call filtering mitigates

The reason this matters is that unconstrained tool access is a real attack surface. Call filtering is a primary control against several documented agentic-AI risks:

• Excessive agency and over-broad tool access. An agent with access to more tools than its task requires can be steered into destructive or out-of-scope actions. It maps directly to the OWASP Top 10 risks for agentic AI, which call out tool misuse and identity and privilege abuse as primary threats. Standards bodies frame this as a least-agency problem: agents should not hold broad, persistent permissions.
• Tool poisoning. A malicious or compromised tool description can manipulate an agent into harmful behavior. Filtering limits which tools reach the model in the first place. We cover the mechanics in our guide to MCP tool poisoning.
• Prompt injection. Injected instructions often try to trigger high-impact tool calls. Filtering and human review on sensitive tools blunt the payoff.
• Data and PII exfiltration. A tool that can reach internal systems or return sensitive records is an exfiltration path. Response filtering and egress controls reduce what can leave.
• Token passthrough. Filtering at a single enforcement point lets you stop calls that would forward credentials to systems they were never issued for.

For the broader picture of how these risks fit together, see our overview of MCP security risks and the MCP security hub.

Where call filtering belongs: the gateway as the single choke point

If filtering has to be added on top of MCP, the next question is where. The most defensible answer is to filter MCP tool calls at the gateway: a layer that every agent-to-server connection passes through, so it can intercept each call, inspect it, and allow or deny it before it reaches an MCP server.

The flow is straightforward. The agent or client sends its requests to the gateway rather than directly to each server. The gateway intercepts both discovery (tools/list) and invocation (tools/call), evaluates them against policy, and forwards only what is permitted. Responses pass back through the same point and can be inspected on the way out. Because every call funnels through one place, the gateway becomes the single choke point where policy is consistent and auditable.

An MCP gateway is the natural home for this enforcement, and the same idea applies when the enforcement layer is implemented as an MCP proxy in front of your servers. This page focuses on the filtering mechanism itself. For what a gateway is and the full range of functions it performs, follow those links rather than expecting the whole picture here.

What you can filter: the dimensions matrix

Most explanations treat filtering as one thing. It is more useful to think of it as two axes: what you filter on, and where in the call lifecycle you act. Getting both right is the difference between a real control and a checkbox.

Filtering dimensions: by tool, server, parameter, and identity

The what axis covers several dimensions of MCP request filtering:

• By tool. Permit or deny specific tools by name (for example, allow search, deny execute_shell).
• By server. Allow an agent to reach some MCP servers and not others, useful when servers map to different trust levels or data domains.
• By parameter or payload. Inspect a call's arguments and block, rewrite, or flag calls whose inputs violate policy, for example a file path outside an allowed directory or a query targeting a restricted table.
• By identity or agent. Bind the decision to a verified agent or user identity so the same tool is allowed for one caller and denied for another. This is how you actually restrict which MCP tools an agent can call rather than applying one blanket rule to everyone.

Identity is the dimension that makes the rest trustworthy. A filter that doesn't know who is calling can only make crude, global decisions. Tying each decision to authenticated identity is what enables least-privilege, per-agent policy, and it connects filtering to MCP access control and MCP identity.

Discovery vs invocation vs response

The where axis is the one competitors most often collapse. There are three distinct points to act on:

• Discovery (tools/list filtering). Filter the catalog the model can see. If a tool never appears in the list, the model is far less likely to attempt it, and you reduce the attack surface for tool poisoning at the description level.
• Invocation (tools/call filtering). Filter what the agent can actually run. Even if a tool is visible, the call can be blocked at invocation. Filtering both layers matters: hiding a tool is not the same as preventing its use, and a determined or compromised client may attempt calls it was never shown.
• Response or output filtering (MCP output filtering). Inspect and sanitize what a tool returns before it reaches the model, for example masking PII or stripping secrets. This is the axis most filtering layers ignore, yet it is where data exfiltration is actually caught.

Crossing the two axes gives a practical matrix of what is enforceable at each stage:

Dimension	Discovery (tools/list)	Invocation (tools/call)	Response / output
By tool	Hide tools the identity may not use	Block disallowed tool invocations	Apply per-tool output rules
By server	Hide servers outside the trust scope	Block calls routed to denied servers	Sanitize responses from sensitive servers
By parameter	Not applicable (no args at discovery)	Inspect, rewrite, or block on argument values	Redact fields in the returned payload
By identity / agent	Tailor the visible catalog per identity	Allow or deny per verified caller	Mask data per caller's entitlements

Allowlist vs denylist: a default-deny posture

Once you can filter, you have to decide the default. A denylist permits everything except an enumerated set of blocked tools. An MCP tool allowlist denies everything except an enumerated set of permitted tools. For agentic systems, the allowlist (default-deny) posture is the safer choice, and it is the one standards consistently point to.

The principle is least privilege, or in agent terms, least agency: grant only the tools a task genuinely needs, as the OWASP AI Agent Security Cheat Sheet recommends. The MCP specification's call to minimize scope points the same way, and the NIST AI agent standards work directs that agents should not inherit broad, persistent permissions but operate task-scoped with action-level approval. A denylist inverts this. Every tool you forget to block is permitted by default, so the failure mode is silent over-exposure. With an allowlist, the failure mode is a blocked call you can see and fix.

	Allowlist (default-deny)	Denylist (default-allow)
Default for unknown tools	Blocked	Allowed
Failure mode	Over-restriction (visible, fixable)	Over-exposure (silent)
New tool added to a server	Denied until explicitly allowed	Live immediately, even if unreviewed
Alignment with least privilege	Strong	Weak
Best for	Production agents, sensitive tools	Low-risk, fully trusted internal tooling only

The practical guidance is simple: block MCP tool calls by default and allow by exception. A denylist is acceptable only for low-risk, fully trusted internal tooling, and even then a new tool added to a server goes live unreviewed, which is exactly the gap default-deny closes.

Policy patterns for MCP call filtering

How you express and evaluate filtering policy ranges from simple static rules to dynamic, context-aware decisions. Here are the common patterns, roughly from simplest to most powerful:

• Static allowlists. A declarative map of which identities may use which tools and servers. Easy to reason about and audit, and the baseline for most deployments.
• Dynamic interceptors and webhooks. A policy hook the gateway calls at decision time, letting you make context-aware choices (time of day, request volume, recent behavior, external risk signals) rather than only static matches.
• Pre-call vs post-call interceptors. Pre-call interceptors evaluate and can block a request before it reaches the server. Post-call interceptors inspect the response and can sanitize or block it on the way back. Strong MCP runtime protection uses both.
• Output sanitization. A post-call pattern that redacts or masks sensitive fields in responses, supporting MCP PII protection without blocking the call outright.
• Human-in-the-loop on high-impact calls. For destructive or sensitive tools, require explicit human approval before the call proceeds, instead of trusting the agent's judgment.

These patterns compose. A mature policy might use a static allowlist as the floor, a dynamic interceptor for risk-based decisions, output sanitization on responses, and human approval gating the few genuinely dangerous tools. This is the heart of MCP policy enforcement, and it is most effective when expressed once at a central layer rather than reimplemented per server.

Per-server config vs centralized gateway filtering

You can configure filtering on each MCP server individually, or centralize it at a gateway. The per-server approach looks simpler at first and breaks down as you scale. Each server enforces its own rules in its own way. There is no single place to see or change policy, new servers ship with inconsistent defaults, and you have no unified audit trail. Policy drifts, gaps open quietly, and identity is rarely bound consistently across servers.

Centralized MCP gateway tool filtering puts one policy engine in the path of every call. This is the scaling argument competitors assert but rarely prove:

Concern	Per-server config	Centralized gateway filtering
Policy consistency	Per-server, drifts over time	One policy, applied everywhere
Coverage of new servers	Manual, easy to miss	Covered the moment they route through the gateway
Identity binding	Inconsistent or absent	One verified identity model across all calls
Audit trail	Fragmented per server	Centralized, complete
Change management	N places to update	One place to update
Scaling behavior	Gaps grow with server count	Constant control surface

The takeaway is not that per-server rules are useless, but that they cannot be the system of record. Filtering belongs at a centralized choke point so policy is consistent, identity-bound, and auditable across every MCP server, no matter how many you add.

Implementation considerations

Getting filtering into production safely involves more than writing rules. Keep these factors in view.

Identity binding is the foundation

A filtering decision is only as trustworthy as the identity it is bound to. If the gateway can't verify which agent or user is behind a call, its rules degrade to blunt, global toggles. Authenticate the caller, bind every decision to that verified identity, and apply per-identity policy. This is where filtering meets authentication and authorization, and it is the part most teams underinvest in. Frontegg's work on securing AI agents covers identity-bound, least-privilege authorization, step-up auth, and human-in-the-loop controls for exactly this layer. For how identity and access fit the MCP stack, see MCP identity and MCP access control.

Audit logging and governance

Every allow and deny decision should be logged with the identity, tool, server, and outcome. A central gateway makes this a single, complete audit trail rather than fragments scattered across servers, which is the backbone of MCP governance and the evidence you need when something goes wrong. Set and review MCP tool permissions as a governed process, not an ad hoc edit.

Latency and parameter parsing

Filtering adds a hop and some inspection work. For allow/deny by tool, server, or identity, the overhead is typically negligible. Parameter and response inspection cost more because they require parsing payloads against a schema, so reserve deep inspection for the tools and fields that warrant it rather than every call. Validating arguments against each tool's declared input schema also keeps inspection accurate.

Layering with access control and egress

Call filtering is a layer, not the whole defense. It complements authorization (who is allowed what), and it pairs with network egress controls to limit where a tool can actually send or fetch data. That is an important backstop against exfiltration when a tool reaches internal resources, the kind of server-side request forgery (SSRF) risk OWASP documents. Treat filtering as one control in a defense-in-depth stack alongside identity, authorization, and network policy.

Frequently asked questions

What is MCP call filtering?

MCP call filtering is intercepting, inspecting, and selectively allowing or blocking MCP tool calls and their responses at the gateway between an AI agent and the MCP servers it uses. It governs which tools an agent can discover and invoke, with what parameters, and under whose identity.

How does a gateway filter MCP tool calls?

The agent connects through the gateway instead of directly to each server. The gateway intercepts discovery and invocation requests, evaluates them against policy and the caller's verified identity, forwards only permitted calls, and can inspect or sanitize responses on the way back.

What is the difference between filtering tools/list and tools/call?

Filtering tools/list trims the catalog the model can discover, so it never sees disallowed tools. Filtering tools/call blocks invocation even when a tool is visible. You need both: hiding a tool does not stop a client from attempting to call it.

Can you filter MCP responses, not just requests?

Yes. Post-call or output filtering inspects what a tool returns before it reaches the model, allowing you to redact or mask sensitive data such as PII and secrets. Response filtering is where data exfiltration is most often caught, and many filtering layers overlook it.

Allowlist or denylist for MCP tools: which is safer?

An allowlist (default-deny) is safer. Everything is blocked except an explicitly permitted set, so a forgotten or newly added tool is denied by default. A denylist permits anything you have not blocked, which silently over-exposes new and unreviewed tools.

How do I restrict which MCP tools an agent can call?

Bind filtering to the agent's verified identity at a gateway, then apply a per-identity allowlist of tools and servers. Add parameter checks for sensitive arguments and human-in-the-loop approval for high-impact tools so each agent gets only the least-privilege access its task requires.

Why doesn't MCP filter tool calls natively?

MCP was designed for interoperability, and the specification states it does not enforce security at the protocol level. Discovery is unfiltered and there is no native identity-aware authorization, so implementers must add filtering and access control as a layer on top.

Per-server config or centralized gateway: which approach scales?

A centralized gateway scales; per-server config does not. Per-server rules drift, miss new servers, and fragment the audit trail. A gateway applies one identity-bound policy to every call through a single choke point, so coverage stays complete as you add servers.

How does call filtering relate to authentication and authorization?

Authentication establishes who the caller is and authorization defines what they may do; call filtering enforces those decisions on each tool call and response. Filtering is only trustworthy when bound to a verified identity, so it sits on top of, and depends on, strong auth.

Does MCP call filtering add latency?

Some, but usually little. Allow/deny by tool, server, or identity is near-instant. Parameter and response inspection cost more because they parse payloads, so apply deep inspection selectively to the tools and fields that need it rather than to every call.

Bring MCP call filtering to one choke point

MCP gives agents reach. Call filtering gives you control over how that reach is used. The durable pattern is clear: filter at a single gateway, default to deny, bind every decision to a verified identity, and inspect both requests and responses, rather than scattering inconsistent rules across individual servers.

The Agen MCP gateway is built to be that choke point. It filters every tool call across all of your MCP servers with identity-bound, default-deny policy, inspects parameters and responses, and gives you one consistent, auditable place to enforce safe tool use. See how the Agen MCP gateway filters every tool call and bring consistent call filtering to every agent and server you run.