moose_practice

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as the authoritative hierarchy ('always outrank community code') and the output nature ('small, precise rule records'). While it does not explicitly state read-only behavior, the verb 'Returns' strongly implies it, and the added context goes beyond a basic description.

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 core purpose and includes actionable guidance. It is slightly repetitive (the word 'Returns' appears twice), but no sentence is wasted; each adds value—purpose, authority, phase meaning, workflow, and output format.

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 tool lacks an output schema, but the description partially compensates by stating the return format ('rule records'). It covers phase semantics and the authoritative ranking. It does not specify detailed fields of the rule records or edge-case behavior, but given the tool's moderate complexity, the description is reasonably complete.

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?

With 100% schema description coverage, the baseline is 3. The description adds practical meaning beyond the schema by explaining the Plan/Act workflow, linking phase values to specific times in the workflow (planning vs coding). This enriches the schema's simple enum 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 clearly states the tool's function: it returns AUTHOR-curated rules for MOOSE usage, with a specific verb (returns) and resource (rules). It distinguishes itself from sibling tools by emphasizing that author rules are authoritative and outrank community code, and by referencing 'Pillar 2'.

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 gives clear workflow guidance, explaining when to use phase=plan vs phase=act ('fire phase=plan during planning, phase=act while writing code'). However, it does not explicitly name alternative tools or state when not to use this tool, relying on the authority claim to imply preference.

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