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

Annotations already establish read-only, idempotent, closed-world behavior, and the description adds substantively on top: a required Bearer API key, a cost of exactly 1 request, plan-tier caps on history depth (trial 30, Light 365, Pro full series), the [date, value] row shape, and an attribution requirement. It also flags a real provenance caveat (ECB reference rates, not the ICE U.S. Dollar Index), which prevents a plausible misinterpretation.

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?

Coverage and scope are front-loaded, followed by the 'days' semantics, then the return shape, then auth/cost. Every sentence carries an operational fact; the closing 'informational market data only' line is short compliance framing appropriate for a financial data tool.

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 output schema, the description still specifies the return shape ([date, value] rows), the request cost, auth requirements, and depth limits tied to plan tier. Nothing an agent needs to call this correctly or to interpret the response is missing.

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 100%, so the baseline would be 3, but the description adds semantics the schema lacks: the concrete per-plan caps behind 'days' (30 / 365 / full series) and the fact that dxy_style_index is ECB-derived rather than ICE. Those details materially change how an agent sets 'days' and interprets a topic value.

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 states a specific verb and resource ('Daily history for one MacroTape topic') and immediately bounds the data domain: 14 Treasury tenors plus 5 curve spreads since Jan 2, 2025, and 29 FX pairs plus a DXY-style index for the last year. An agent can tell this apart from the sibling brief tools (get_latest_brief, get_brief_by_date) and the alert/webhook tools without inspecting the 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?

Usage context is clear: this is the historical time-series endpoint, and '/api/history/index.json' is pointed to as the way to enumerate valid topics. It does not explicitly name get_latest_brief or get_brief_by_date as alternatives, nor state when not to use it, so it stops short of full alternative routing.

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