A hidden MCP tool can still run while another call is counted twice

A developer blocked a tool from an MCP catalog and then called it by name. In a separate test, a request quota of four allowed five or more keyword searches. A third test found the opposite accounting error: one wrapper call consumed two quota slots but produced no configured tool charge. These are three distinct reporter reproductions against LiteLLM, not evidence of one coordinated intrusion. Together they expose a recurring implementation error: the policy and accounting meaning of an operation changes according to the route used to reach it.

These measurements come from the listing guard report, the keyword search report and the virtual call report. The test version was 1.105.1 and the public issues were still open when inspected on October 25, 2026. The reports are detailed enough to inspect their proposed control flow, but independent deployment prevalence and an upstream corrected release are not established.

The first finding is about metadata carried between stages. During discovery, the guardrail sees a tool description containing a prohibited instruction and omits that tool from the catalog. On direct invocation, it sees only tool name and arguments. The forbidden description is no longer part of the decision input, so the same policy is not equivalent. This failure can occur even with a correctly authenticated caller and without prompt injection into the language model. The observed boundary is catalog visibility, not execution permission. The Case dossier records the reproducible discrepancy.

The second and third findings concern accounting, but they point in opposite directions. A keyword search takes a short path around the normal pre-call reservation and audit writer. A virtual tool call instead passes through an outer pre-call reservation and an inner real-tool reservation, then misses pricing and logging of the actual tool effect. Correcting only the visible request counter would leave the audit and billing gaps unresolved. The distinct investigations are recorded in keyword-search quota and virtual-call accounting.

One logical operation needs an identity that survives tool discovery, routing, nested dispatch, permission checks, execution and completion. Its ledger should distinguish admission attempts from actual external effects and should not count the wrapper as a second physical action. A denied tool should remain denied on direct calls and aliases, not merely hidden in the browsing UI. Every attempted search should be visible to the relevant quota and audit system, regardless of keyword or embedding ranking. For an executed tool, the result should be reconcilable with precisely one completed effect, its configured price, and an auditable caller identity; cancelled or refused calls should release any held concurrency slots.

This is an implementation-level test plan derived from the three reports, not a claim that a new upstream patch has passed. Catalog and execution drift describes the permission failure; tool-effect accounting describes the independent measurement failure. Treating those as separate boundaries prevents a fix to logging from being mistaken for an authorization fix.