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

With no annotations provided, the description carries the full burden and does well: it discloses the full pipeline (resolve universe, fetch prices, compute raw scores, convert to z-scores, rank), warns about dropping tickers with insufficient history or fetch failures, reports warnings, describes the output structure, and even states the pricing. It does not explicitly state read-only safety or authorization needs, but the described behavior is thorough for a computational tool. This exceeds a 3, though not a 5 due to a few omissions (e.g., default universe behavior).

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 front-loaded with the primary purpose, then systematically explains process, signals, parameters, and output. It is lengthy due to the necessary signal definitions, but every sentence adds value. No filler or redundancy is present, making it appropriately concise for the tool's complexity.

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?

Given the tool's complexity (5 parameters, 3 enums, no output schema, no annotations), the description is highly complete: it explains the algorithm, signal definitions, parameter semantics, output structure, and edge-case handling (dropping tickers). Minor gaps remain, such as unspecified defaults for 'universe' and 'top_n' and no explicit statement about what happens when neither universe nor tickers is provided. Overall, it is thorough and well above the minimum viable.

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 all parameter meaning, and it does. It explicitly defines 'range' with its enum values and default, explains 'top_n' as truncating output, describes 'universe' as either SP500 or TSX, and provides detailed definitions for each 'signal' enum value. It also covers the relationship between 'tickers' and 'universe' (override). This fully compensates for the lack of schema-level descriptions.

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+resource: 'Score and rank a universe of tickers by a cross-sectional signal.' It clearly defines the tool's function, differentiates it from individual indicator tools by mentioning cross-sectional scoring and ranking, and specifies the output ordering (rank 1 = highest z-score). This is unambiguous and distinguishes it from siblings like compute_indicator or compute_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?

The description implies context (use when you need to cross-sectionally rank a universe) and details how the tool resolves universes and signals, but it does not explicitly state when to use this tool over alternatives or list exclusions. Sibling tools like screen_with_scores or compare_tickers could overlap, but no explicit guidance or named alternatives are provided. This is clear context without exclusion guidance, matching a 3.

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