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

Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds useful semantics about scoring methodology (sector-relative percentile 0-100, A-F grades, market-wide scope), which is genuine context beyond the annotations, but it omits the access constraint that limit is capped below the Corporate plan and says nothing about result volume or coverage caveats.

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 tight sentences that front-load the resource and then the output semantics and filters; no filler. Slightly dense with parenthetical factor lists, but every clause is informative.

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 an output schema present, the description needn't explain return values, and it adequately covers universe, scoring, and filters. However, for a tool sitting among many factor-related siblings it fails to position itself, and it doesn't mention the limit/plan cap that materially affects how an agent should call it.

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 baseline is 3. The description adds only a loose restatement ('Filter by sector, factor, grade') and does not mention the limit parameter at all; worse, it calls factor a filter while the schema describes it as a sort key, and its factor naming ('Growth, Quality') diverges from the schema's ('growth, profitability'), which could mislead an agent on accepted values.

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?

Clear specific verb+resource: 'Get NZ Equity Factor Model' with the six factors named and the universe (all NZX companies) and output form (sector-relative percentile, A-F grades) spelled out. It does not, however, distinguish itself from close siblings such as get_factor_grades, get_alpha_factors, or screen_stocks, which an agent would need to choose between.

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 final sentence ('Use for factor-based stock selection and quantitative screening') gives an implied usage context, but there is no explicit when-not, no named alternative, and no indication of how it differs from get_factor_grades or get_alpha_factors. Usage is inferable but not guided.

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