LiteLLM guardrail hid a prohibited MCP tool but did not block direct invocation

A reporter configured LiteLLM 1.105.1 with a default-on pre_mcp_call guardrail rejecting a prohibited phrase in an MCP tool description. During tools/list, the guardrail examined the description and omitted the tool. The same tool was absent from keyword search results, but a caller who already knew its exact name could use tools/call and obtain the benign upstream response. In that request path, the guardrail received the invocation arguments rather than the description that had triggered the earlier block. Reproducible issue report.

The discrepancy is not simply that a user guessed a hidden name. It is that a control applied to one representation of a tool does not accompany that tool to the execution boundary. Catalog visibility helps users or models discover capabilities; it is not evidence that direct dispatch will deny a disallowed action. An implementation can preserve one canonical tool identity and check the relevant policy inputs on both discovery and invocation, including aliases or virtual wrappers, without assuming a model is unable to guess names.

The public reproduction returned a harmless weather response. It did not demonstrate credential theft, an unauthorized file read or a completed attacker campaign. The separately reported keyword-search quota issue and virtual-call accounting issue concern metering and audit behavior, not the same guardrail failure. No corrected upstream release was established from the inspected issue page on October 25.