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

Annotations already cover read-only, idempotent and non-destructive, so the bar is lower; the description still adds useful behavior beyond them, namely that output renders as an in-chat chart with a 'plan them' button, and that it uses the same numbers as weekly_report. 'Free and read only' mildly restates the annotations, and it does not mention data freshness or limits on the comparison window.

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?

Usage trigger and examples come first, then output contents, then parameter hints, then exclusions — a logical front-loaded order with no filler sentences. The trailing 'Free and read only' duplicates the annotations and is the one line that does not earn its place.

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 values need not be explained, yet the description still tells the agent what the chart contains. Combined with the sibling routing and parameter semantics, an agent has everything needed to choose and invoke it correctly.

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%, so the description must carry both parameters, and it does: `days` is defined as the lookback window defaulting to 7, and `timezone` as an IANA name with a concrete example. It omits the timezone default (UTC) and any bounds on `days`, so it is strong but not exhaustive.

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 gives a specific verb and resource ('show how their week went as a chart'), enumerates the contents (views by day/platform, comparison period, top posts, best time, clips to post next), and explicitly separates it from weekly_report and get_post_stats.

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?

It states the trigger condition ('when the user wants to see their week as a chart in the chat') with example utterances, and adds an explicit 'Not for:' clause routing written answers to weekly_report and per-post tables to get_post_stats.

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