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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), so the bar is lower; the description still adds real behavioral detail by disclosing pagination behavior – a hard cap of ten rows per page and a next_offset cursor when more exist. It does not cover rate limits, auth requirements, or what fields a row contains, but the pagination disclosure is genuine added value.

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?

Three tightly packed sentences with no filler; the primary use case is front-loaded, followed by return behavior, then filters, then exclusions. Every sentence carries distinct information an agent needs.

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 five optional parameters and no output schema, the description supplies the scoping, filtering, sorting, and pagination context needed to invoke it correctly. It omits any indication of what a returned trader row looks like and what 'qualified cohort' means, which is the main remaining gap.

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 the load, and it does substantially: it clarifies that asset is an exact match, that leverage_tier is a filter, that sorting is between score and Sharpe, and that limit/offset drive ten-row pagination. It does not name the limit default (3) or reconcile the schema's 'offset' with its own 'next_offset' cursor terminology, 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 a specific verb and resource: a historical score or Sharpe ranking of the qualified trader cohort. It also draws a boundary with three named exclusions (market-wide ranking, 30-day PnL sort, personalized recommendation), which helps separate it from siblings, though it never names the actual sibling tools that cover those cases.

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 opening clause tells the agent when to reach for this tool, and the closing sentence enumerates three things it is NOT for, which is clear exclusion guidance. It stops short of pointing to the alternative tool for those excluded cases, so the routing is implied rather than explicit.

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