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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds material behavioral context: the KPIs are computed live from the systems themselves, counts are privacy-bounded with no customer identities or per-agent details ever, new counters carry a counting-since date, and the tool is free with no x402 payment challenge. It also explains the consistency guarantee that the same result object powers the human board page.

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?

The purpose is front-loaded in the opening clause and the enumerated counters are informative rather than padding. A few clauses, notably the human-board-page consistency point and the HTTP equivalent URL, are nice-to-have rather than essential, keeping it just short of maximally tight.

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 input params and no output schema, the description correctly carries the burden of explaining the return contents, and it does so in detail (counters plus printed definitions plus counting-since dates). What it lacks is an explicit statement of when to prefer it over the sibling fleet_activity and fleet_what_changed tools.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description spends its words on the response shape instead, which is the appropriate use of space for a parameterless tool.

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 description names a specific resource (Fleet KPIs for ExchangeRebel) and enumerates exactly which counters are returned, so an agent knows precisely what it will get. It implicitly distinguishes itself from sibling tools like fleet_activity by stating it returns aggregate counts rather than per-event or per-agent detail, though it never names a sibling explicitly.

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?

Usage is only implied: an agent can infer this is the call for a fleet-wide summary, and the description usefully states it is free and callable without a payment challenge. There is no explicit 'use this instead of fleet_activity / fleet_what_changed when...' guidance or exclusion, so the agent must infer the boundary from the counts-only wording.

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