review.make_prompt

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

The description discloses one behavioral detail: automatic conversion of 'main' to 'origin/main' for the base parameter. However, without annotations, it fails to disclose other important behaviors such as whether the tool modifies any files, how the diff is obtained, or what the output package actually contains. It does not explain side effects or return format.

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 exceptionally concise, consisting of two short sentences. It is front-loaded with the primary action and includes a crucial behavior note. Every word serves a purpose, with zero redundancy or 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?

Given 5 parameters, no output schema, and no annotations, the description is far too minimal. It does not explain the content or structure of the returned prompt package, how parameters like contextLines or maxDiffChars affect the output, or whether the tool has side effects. The description answers the 'what' but not the 'how' or 'what to expect'.

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 40% (only 'base' has a description). The description merely repeats the same base conversion info already in the schema, adding no new semantic value. It completely ignores other parameters like contextLines and maxDiffChars, which are not described in the schema either. The description fails to compensate for the low coverage.

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 creates a 'review prompt package' by combining rules and diff, using a specific verb ('만들어줍니다' - creates). It distinguishes itself from sibling tools like review.collect_diff (which collects the diff) and review.save (which saves). The resource and action are unambiguous.

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?

Usage is implied: the tool is for creating a prompt to pass to a model. However, it does not explicitly state when to use this versus alternatives, nor does it mention any exclusions or prerequisites (e.g., need for a git repository or populated rules). No sibling tools are referenced.

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