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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and side-effect behavior need no restatement. The description adds the useful fact that the output is pre-aggregated metrics rather than raw records, but says nothing about freshness/caching, computation window semantics beyond 'recent', or cost, so the added value is modest.

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?

One tightly packed sentence that front-loads the verb and resource, then uses a parenthetical to enumerate returned metrics. The metric list is dense but each item earns its place by telling the agent what questions this tool can answer; no filler or redundancy.

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?

An output schema exists, so return-value explanation is not required, and the sole parameter plus all four annotations are covered structurally. What remains missing is only the routing guidance against sibling listing tools, which is a minor gap for a zero-required-parameter read-only tool.

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 100% and the single 'days' parameter is fully documented there with default 30 and max 90, so the schema does the heavy lifting. The description's phrase 'recent time window' gestures at the same concept but adds no syntax or boundary information beyond it; baseline 3 applies.

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?

Specific verb ('Get') plus a clearly named resource ('dashboard summary') with an enumerated payload (lead counts by status, conversion rate, call volume/duration, top agents, business outcomes by type) and a stated scope ('recent time window'). This is distinguishable from the sibling list_*/get_* tools, which return raw entities rather than aggregates, though the description never names a sibling to make the contrast explicit.

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 tool for aggregate/overview questions and that list_leads or list_recent_calls are for row-level data, but the description never says when to prefer this over those alternatives or what question types it is meant to answer. No exclusions or prerequisites are given.

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