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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, and the description adds substantial context on top: default behavior drops already-published keys, the result row shape including 'topValues (top 8, Others omitted)', and the ~10-minute propagation delay before changes appear in Explorer. These are non-obvious operational traits not derivable from the schema.

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-loads purpose and return shape, then packs workflow guidance into tight sentences, ending with a concrete example call. It is dense and slightly redundant with schema defaults (limit, offset, default sort), which costs a point but the density is information-bearing rather than padding.

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?

Despite having no output schema, the description enumerates the returned columns and the topValues truncation rule, covers filtering/sorting/paging, and describes the full publish loop with preview and confirmation semantics. An agent can invoke this correctly and understand its downstream workflow without further context.

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 100%, so the baseline is 3, but the description goes further by naming the sort enum values and explaining why includeImported matters (keeping keys already used in a published label) rather than merely restating the type. Some entries (limit cap 50, offset) duplicate the schema, which holds it below a 5.

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?

Opens with a precise verb+resource ('List native billing label keys that can be imported as label dimensions') and immediately disambiguates scope with '(not virtual dimensions)', separating it from list_virtual_dimensions and list_label_dimensions. It also enumerates the returned row fields, so the agent knows exactly what it gets.

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?

Explicitly routes to siblings and states the workflow: use publish_label_dimensions to add/change, call list_label_dimension_usages before rename/delete, and notes there is 'No suggestion engine — pick merges and value maps from topValues yourself.' It also gives the dryRun-then-commit sequence, which is exactly the guidance an agent needs.

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