Yes - I'd take that PR. "Over-tooling by count" is already in there, but you've named the sharper failure: token weight is what actually rides in context every turn, and it's the authors who wrote rich descriptions who get bitten - exactly the people who followed the advice.
To fit toolens (static, offline, zero-config): measure the serialized weight of the whole toolset, keep it dependency-light (a cl100k-style estimate in-tree beats pulling a heavy tokenizer - just label it an estimate), and emit a per-tool breakdown next to the total so the warning says which descriptions to trim. Open it whenever - I'll sort the rule code and threshold in review.
Extending your framing one step: "The model chooses the way a user chooses a button in an app they've never used before: by reading the label." Labels also have a total weight, not just individual clarity. Every tool definition rides along in context on every turn, so a 40-tool MCP server with beautifully written descriptions can still degrade selection simply by consuming the budget the model needs for the actual task, which is why several clients now lazy-load tool schemas behind a search step instead of presenting the full palette. That suggests a measurable check in toolens: total token weight of the toolset per common tokenizer, with a warning threshold, alongside the per-tool lints. Over-tooling by count is in there already; over-tooling by tokens is the sibling failure and it hits exactly the teams who followed the advice to write rich descriptions. Would you take a PR adding that?