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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral context not in annotations: data coverage begins 2008-09-02 and results are one row per trading day, warning about row volume. It does not describe the returned columns, but no output schema exists to lean on.

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?

Four short sentences, front-loaded with purpose, then usage, then the coverage constraint and volume warning. Every sentence carries distinct information and none repeats another.

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 three-parameter read tool with a fully described schema, no output schema, and complete annotations, this covers purpose, coverage window, granularity, and a range-size caution. The only gap is the shape of the returned rows beyond row-per-trading-day granularity.

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%, so all three parameters are already documented, and the description's curve descriptions largely restate the enum meanings in the schema. The added value is limited to restating the 2008-09-02 floor and the default curve behavior, which the schema also states. 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?

The description opens with a specific verb and resource: "Get a history of U.S. Treasury yields between two dates," and enumerates the three curve variants. It does not explicitly distinguish itself from the sibling get_treasury_curve, though the phrase "one row per trading day" and "how have rates moved" implies the historical series rather than a point-in-time curve.

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 names the question shape it answers ("Use this for 'how have rates moved' questions") and gives a concrete operating constraint ("Keep ranges tight — a decade is thousands of rows"). It stops short of naming an alternative tool for single-date curve lookups, which would have made routing unambiguous.

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