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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description must add value beyond safety, and it does: it discloses that the quote mode executes nothing ('nothing runs') and that a call consuming a quarter or more of a monthly allowance returns needs_approval instead of running. That approval/quota mechanic is genuinely useful ecosystem context. However, the sentence is ambiguous about whose behavior it describes – get_usage's own response or the quoted target tool's – and nothing is said about the shape of the usage payload (limits, remaining, period boundaries).

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?

Three compact sentences with the primary purpose front-loaded and no filler. The cost is clarity: 'With action and args, what that call would use first (nothing runs)' is a verbless fragment, and the final sentence mixes the approval mechanic into the same breath as the tool's return behavior, forcing the reader to reconstruct the subject.

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?

With no output schema, the description carries the burden of explaining returns, and it only partially does so – it lists which categories are reported and names the needs_approval/approvalId response but never describes the numbers themselves (allowance vs. used vs. remaining). For a read-only reporting tool with an approval side-effect path, that is adequate but incomplete.

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 coverage is 67%, so the schema documents action and args on its own; the description only adds that the pair must be supplied together to trigger a quote. The third parameter, projectId, is undocumented in both schema and description, leaving a real gap at a 67% coverage level. Baseline 3 is appropriate – some meaning is added, but not enough to compensate for the undocumented parameter.

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?

The first sentence names the resource and scope precisely: the workspace's plan plus month-to-date consumption across a specific enumeration (exports, transcription, voice, music, background removal, frames). The second sentence adds a second mode – quoting a prospective call's cost. It is clearly distinguishable from every sibling (nothing else in the list reports usage or quota), though the description never uses a verb for the tool itself, so the two modes have to be inferred from telegraphic phrasing.

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?

It gives concrete when-to-use context for the quote mode ('With action and args, what that call would use first') and an explicit follow-up workflow for the approval case: 'ask the user, then call again with its approvalId.' What is missing is a negative case – nothing says when to skip the tool (e.g., during routine edits) or contrasts it with alternatives such as listing projects.

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