compute_lrs_composite_v2

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses the default weights, the sum of weights, the equal-weight baseline rationale, the buildComplexityPenalty subtraction, the sectorProfile behavior, and the label thresholds. This is unusually transparent about the scoring 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 compact and information-dense, with the core purpose stated first, followed by weights, output behavior, penalty, sector override, and labels. Every sentence adds value and there is no redundant filler.

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?

The description covers the algorithm well but leaves gaps for a complex 8-parameter tool with no output schema: it says 'returns BOTH weighted score and equal-weight baseline' but does not specify the return shape or value ranges, and it does not clarify how this v2 differs from the v1 sibling. The label thresholds imply a 0-100 scale but that is never explicitly stated.

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 only 13%, so the description must compensate, and it partially does: it maps the six component abbreviations to the scores, states the default weights, and explains buildComplexityPenalty and sectorProfile roles. However, it does not explain what each underlying score measures, the full sector weight reshuffle for all components, or how the penalty interacts with the final label thresholds.

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 clearly identifies the resource as 'LRS composite v2', lists its six score components, and states that it produces both a weighted composite and an equal-weight baseline. It is specific about the compute behavior, but it does not explicitly contrast itself with the sibling compute_lrs_composite (v1), so a route-taking agent would have to infer the difference from the version and weight details.

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?

No guidance is given about when to use this tool versus the alternative compute_lrs_composite or the individual component scorers such as compute_search_velocity_v2. The description explains what the computation does, but not which scenarios select this tool or when the sectorProfile option should be used.

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