LiteLLM virtual MCP tool calls double-reserved limits but missed actual tool cost logs

The reported invocation path performs a virtual pre-call check and then invokes the underlying MCP tool handler, where similar quota checks run again. With rpm_limit=4, only two wrapped calls passed compared with four direct calls; a concurrency limit of one could reject even the first wrapped invocation. The reporter separately configured a tool price and observed that direct use produced a charge while a wrapper use did not.

In an agent product, logical attempts, underlying tool effects, reservations, completion accounting and user billing are different clocks. Charging for two attempts while omitting the actual tool cost gives neither correct cost control nor an auditable causal record. The issue remains a reported reproduction, not a confirmed exploitation campaign. Reproduction.

The virtual mcp_tool_call entrypoint performs a pre-call reservation, then invokes a real MCP tool handler that reserves a second request for the same logical action. With rpm_limit 4, this produces only two accepted virtual calls rather than four direct calls; a max_parallel_requests value of one can reject the only virtual call in flight. In the same report, the configured direct-tool price was not charged on the wrapper path and the tool effect lacked a corresponding spend log. The correctness requirement is one stable identity from admission through actual execution, completion, release of concurrency holds, price attribution and audit receipt. De-duplicating by outer HTTP request alone would miss a nested effect.