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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the useful scope statement that data is aggregated overall plus per-location and per-coach, but says nothing about time range, permissions needed, or freshness of the totals.

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?

A single efficient sentence with the main payload (clients and revenue totals) front-loaded. No filler, though it is terse enough to leave gaps unaddressed.

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?

For a read-only aggregation tool with no output schema and three undocumented parameters, the description omits the reporting period, whether coachId/locationId narrow or expand results, and required access level. It is not adequate to call the tool confidently beyond the happy path.

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% for all three parameters, so the description carries the full burden and fails to say what organizationId, coachId, or locationId do. It only obliquely implies filtering via the 'per location and per coach' breakdown, which is not tied to the actual filter parameters.

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 resource (organization-wide totals) and enumerates its content: clients and revenue, broken down per location and per coach. It is clear, but it does not distinguish itself from overlap-prone siblings such as billing_summary, get_organization_earnings, or get_gym_home.

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?

No when-to-use guidance and no named alternatives, despite several sibling tools that also surface revenue or organization-level aggregate data. The agent must infer which dashboard-type tool to pick.

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