console_method_template

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

Annotations already mark it as non-destructive, idempotent, and not read-only, and the description goes well beyond that: it states that detection/alignment conditions are inherited unchanged, that the empty `Lbm file path` is always resolved, that ambiguous candidates halt with `METHOD_FILE_CHOICE_REQUIRED` rather than silently picking the newest, and how `library_mode=msp_only` rewrites library paths. That is exactly the operational context annotations cannot carry.

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 critical guidance (try console_plan first) is front-loaded before any parameter detail, and each paragraph maps to a decision the caller must make. It is on the long side with heavy bold emphasis, but for a 7-parameter tool with zero schema descriptions every sentence does real work; only minor tightening is possible.

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?

For a 7-parameter mutation tool with no output schema, the description covers purpose, prerequisites, exact mutation surface, stop conditions, and mode behavior. Remaining gaps are small: what the call returns (a path? a confirmation?) is not stated, and the `omics` parameter is undocumented.

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 0% schema description coverage the description carries the full burden, and it does so for six of seven parameters: `polarity` values ('positive'/'negative'), `based_on` being polarity-agnostic, `dataset_root` search scope, `library_mode` values and their effect, and `msp_file` usage. The `omics` parameter (default 'lipidomics') is never mentioned, leaving one gap in an otherwise thorough mapping.

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 opens with a specific verb and resource (creates a method/parameter file for the opposite polarity from existing parameters) and immediately distinguishes this from the sibling tool console_plan by framing itself as a last resort. It also scopes the change precisely (only `Ion mode` and `Searched adduct ions` are swapped), which tells an agent exactly what artifact it produces.

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?

It gives an explicit when-not ('まず console_plan の method_file 省略を試してください') with the reason (the GUI auto-saves `<project>_param_<終了時刻>.txt` on every run), and an explicit when ('その極性で一度も処理していない場合だけ'). The alternative and the decision rule that selects it are both named, so no inference is required.

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