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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description goes far beyond by detailing data sources (FRED), calculation method (equal-weight z-scores vs trailing 130-observation window), scale anchor (50=neutral), historical coverage (monthly since 1953), and update cadence. This provides essential behavioral context not available from annotations alone.

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?

The description is compact and well-structured: first sentence states the return value and methodology, second gives usage scenarios, third states update frequency. Every sentence earns its place with no filler or redundant restatement of the title.

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 tool with no output schema, listing all returned fields, methodology, and typical use cases is strong. The only minor gap is a slight ambiguity between the description's 'monthly since 1953' / 'Updates: monthly' and the schema's 'daily HISTORY series' for the `days` parameter, which could confuse an agent about data granularity in history mode.

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?

The only parameter `days` is fully documented in the schema with 100% coverage, including its behavior and Gold tier requirement. The description itself adds no parameter-level detail beyond the schema, so a baseline 3 is appropriate per the rubric.

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 ('Returns') and identifies the resource as a corporate credit-spread stress index with clear methodology (Baa spread and high-yield OAS, z-scores, 0-100 scale, 50=neutral). It lists concrete output fields, making the tool's purpose unambiguous and distinct from generic market indicators.

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?

Explicit call triggers are provided: 'Call when the user asks about credit spreads, corporate default risk, high-yield stress, or bond market risk' plus specific hedging/de-risking timings. However, it does not mention when not to use this tool or name alternative sibling tools, so it lacks full exclusion/alternative guidance.

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