Draft a level-1 capability map

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

There are no annotations, so the description carries the burden. It is candid about limitations: it deliberately does not ensure content correctness, and it refuses to infer industry from the description due to past misjudgments. It also states that industry sets apply only with an explicit parameter; however, it does not disclose output format details or whether the draft is persisted/visible to the business, so a 4 is appropriate.

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 somewhat long but all content is functional; the core purpose and the key caveat come first in both languages, and the sibling tool comparison is useful. The dual-language structure is slightly repetitive but serves this bilingual tool appropriately.

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 drafting tool with no output schema and no annotations, the description covers the main points: what the output contains, how to use it, when to use the alternative, and how the industry parameter behaves. It does not specify whether diagrams are editable or persisted, but given the large sibling set and the parameter richness in the schema, this is close to 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?

The schema already has 100% coverage with detailed Japanese/English descriptions for all three parameters, so the schema does the heavy lifting. The description adds decision-relevant context beyond the schema: it tells the agent that industry sets are applied only when `industry` is explicit (schema says omit and no set is applied, but description explains the rationale), and it frames businessDescription concreteness as a quality lever. That is meaningful but modest value beyond the schema.

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 drafts a level-1 capability map (diagram + table) plus questions to ask the business side. It explicitly says it produces shape and questions, not correct content, and even names the faster alternative, check_capability_map, so its purpose is unambiguous and distinct from siblings.

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 explicitly says when to use this tool versus the faster and more accurate alternative, check_capability_map: use this when you want the shape and questions; if you've read the source material, pass your own names to check_capability_map. It also clearly states when industry sets apply—only when the `industry` parameter is passed explicitly, not inferred—and that omission merely suggests candidates.

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