MCP tool catalog restrictions can diverge from invocation authorization

Definition & limits

An MCP proxy commonly exposes tool discovery, selection and execution through different handlers. A policy applied to tools/list might inspect descriptions or labels that are absent from the later tools/call payload. If the decision is not bound to an authenticated tool identity and re-enforced at invocation, hiding the catalog entry becomes a visibility filter rather than denial of execution. The same mismatch can arise through virtual wrappers or aliases. This pattern is illustrated by the reported LiteLLM listing-versus-call reproduction; it is not a claim that all MCP clients behave identically. A robust boundary authenticates the tool and caller on the actual effect path and retains a stable reference to the policy inputs.

The LiteLLM tools/list report demonstrates why discovery filtering cannot stand in for execution authorization: the guardrail examined descriptions during enumeration, whereas tools/call arrived with a name and argument object that did not carry the same description. The separate mcp_tool_search report concerns missing request-limit checks rather than access to a prohibited tool. A canonical executable-tool identity must be used at discovery, direct invocation, virtual dispatch and audit, with the same binding to allowed actions throughout.

Examples

• [Known-name invocation despite list filtering](db:CASE-2026-LITELLM-MCP-DISCOVERY-GUARD).
• [Separately authenticated actions at effect time](db:CONCEPT-LIVE-AUTHORIZATION-AT-SIDE-EFFECT).

Explicit mappings

Research using this topic (1)