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

Annotations already cover safety (readOnly, non-destructive, closed-world), so the description's job is to add behavioral context, and it does: the index view always returns both 30d and 90d figures, window only affects country ordering, and the values are a computed aggregate with no agency provenance. That last point usefully warns the agent not to expect source citations, though nothing is said about refresh cadence or stability of the aggregate.

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?

Front-loads the two view modes, then the behavioral caveat about window, then the usage cue and the sibling pointer. No filler sentences, and each clause carries information the schema or annotations do not.

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 an output schema present, return values need no explanation, and the description covers both views, the aggregation caveat, and the nearest alternative. It stops short of defining 'regime' or the z-score computation, which leaves mild ambiguity for an agent interpreting results.

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 coverage is only 25% (lang is the sole documented parameter), so the description must compensate, and it largely does: it explains the two view modes and clarifies the non-obvious meaning of window as an ordering control rather than a data filter. 'country' (2-letter code) and the lang switch are left to the schema, leaving a small 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 both concrete outputs (per-country weighted beat/miss index with regime, and a per-country daily heatmap of surprise z-scores) and names the sibling that covers the single-indicator case, el7_calendar_history. An agent can distinguish this from el7_calendar_events or el7_calendar_history without opening any schema.

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 an explicit triggering question ("is the US economy beating forecasts") and routes the single-indicator use case to el7_calendar_history, which is clear alternative-selection guidance. It does not state when-not to use it (e.g., for raw event data), so it falls short of full exclusion coverage.

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