What does this equation mean?

Put the three costs together and a deployment question comes into focus: given a fixed context window, how many tools can actually be offered before something has to give? A simple ceiling model makes the trade-off explicit. Let C be the model’s usable context window, $T_{\mathrm{system}}$ the fixed cost of operator instructions, and $T_{\mathrm{reserve}}$ a reserved allowance for the user’s message and the model’s own answer. If every tool schema costs on average $\bar{t}_{\mathrm{tool}}$ tokens and all of them are injected in full on every turn, the maximum number of tools a deployment can nominally offer before it must start pruning or retrieving is $n_{\max} = \left\lfloor \frac{C - T_{\mathrm{system}} - T_{\mathrm{reserve}}}{\bar{t}_{\mathrm{tool}}} \right\rfloor$. The assumption doing the work in that formula — every schema injected in full, on every turn, uncompressed — is exactly the assumption Gorilla and ToolLLM abandoned once their tool catalogues grew past a few dozen entries, replacing blanket injection with retrieval that surfaces a handful of relevant tool descriptions per request instead of the whole catalogue [ 5 , 6 ] . That substitution changes $\bar{t}_{\mathrm{tool}}$ from “every tool’s cost, always” to “a few tools’ cost, most of the time,” which is the only lever in the equation that scales sublinearly as the number of available tools grows. It is also, notably, a departure from what MCP’s own discovery model assumes by default: tools/list is designed to hand back the full capability set a server offers, and nothing in the base protocol specifies how a host should decide to show only part of that set to the model [ 1 ] .