run_query_bounded

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and openWorldHint=true; the description goes well beyond them by disclosing the cost-bound gate, the 'refused' status sentinel, the result.hint diagnostic, and the real monetary/quota side effect of a successful call. This is exactly the extra context a mutating, cost-bearing tool needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core behavior and free of padding; the parenthetical about refusal and hint is the only slightly dense clause but it carries real information. Efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values needn't be documented, yet the description still usefully explains the 'refused'/'hint' shape. Behavior and cost implications are complete for a bounded-execution tool; the only real omission is per-parameter meaning, which keeps this from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 6 parameters, and the description never explains any of them — engine, warehouse, max_rows, max_bytes_billed, max_estimated_cost_usd are all left to the raw titles. The phrase 'your given bounds' hints at the max_* parameters but gives no mapping, units, or default behavior, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource ('run a query') plus the governing condition ('only if its pre-flight cost estimate is within your given bounds') and the failure mode ('refuses otherwise'). It explicitly names the sibling estimate_query_cost, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the selection condition against the alternative ('unlike estimate_query_cost...'), the refusal semantics, and an explicit anti-pattern warning ('don't call this repeatedly without inspecting the result of each call'). When-to-use and when-not are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.