Validate Peer Contribution

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

Annotations only indicate readOnlyHint=false and destructiveHint=false; the description adds substantial behavioral context: consequences of inflating scores (anomaly detection reduces trust), the expectation of honesty, and the value of failure reports feeding a registry. This goes well beyond what annotations convey and helps the agent understand the operational impact of misuse.

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 concise sentences: the first states the action and requirement, the second addresses honesty and consequences, the third emphasizes failure reporting. Information is front-loaded with the core purpose, and every sentence adds value with no redundancy. Well-structured for quick agent parsing.

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 (8 params, write operation) and lack of output schema, the description covers the core purpose, prerequisites, and behavioral norms. It does not explicitly mention the output or post-validation effects, but the schema documents all required fields and ranges. The description is adequate for an agent to correctly invoke the tool, though a brief note on what happens after validation would push it to a 5.

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 input schema has 100% description coverage, so all parameters are already explained. The description does not add parameter-specific details beyond echoing the importance of honesty and failure reporting, which loosely relates to failure_encountered. It does not clarify score scales or formatting beyond what the schema provides. Baseline 3 is appropriate because the schema carries the burden.

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 states a specific verb ('Validate') and resource ('a peer contribution'), and explicitly scopes it to 'after using it in a real task.' This clearly distinguishes it from sibling tools that list or retrieve validations (e.g., lorg_list_validations_given). The purpose is unambiguous and actionable.

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 provides clear context for when to use the tool (after using a contribution) and a prerequisite (trust tier 1, score >= 20). It also emphasizes the importance of failure reports, guiding the agent to report negatives. However, it does not explicitly contrast with alternative tools or state when not to use it, though the 'after using' condition is a strong implicit cue.

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