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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld; the description adds the non-obvious behaviors on top: the result lands in FileStore rather than being returned inline, and the tool does not fan out across Locations. It doesn't mention cost, runtime, or what happens when no Locations exist, but the added context is genuine value beyond the annotations.

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?

Two short blocks: the core action first, then the one parameter constraint that matters. No filler, no restatement of the title, and the most decision-relevant fact (no cross-Location fan-out) is placed where it will be read.

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?

The output schema and annotations relieve the description of explaining return shape and safety profile, and the FileStore destination is covered. However, for a tool with three entirely undocumented behavioral knobs (active_only, max_workers, sample_consumption) the description leaves an agent unable to tune or even trust the defaults, which is a real completeness gap.

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% and only `location` is explained (its multi-location requirement and no-fan-out rule). The other three parameters — `active_only`, `max_workers`, and especially `sample_consumption` — are never mentioned, and their meaning (concurrency level? consumption sample used to compute rate tiers?) cannot be inferred from bare names and defaults. For a 4-parameter tool with zero schema documentation this is a significant 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 specific verb and resource plus the output artifact and destination: 'Build a multi-sheet XLSX of every meter type's rate card → FileStore.' That is far more informative than the title alone. It does not explicitly contrast with the sibling get_meter_rate_card (single-card read), so the differentiation is implied by 'every meter type' rather than stated.

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 a concrete usage rule: `location` is required when the connection has several Locations, and the tool never fans out. It also routes the agent to `list_locations` to resolve the ambiguity. What's missing is guidance on when to prefer this bulk export over the sibling get_meter_rate_card, and what 'multi-location' connections should do instead.

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