delete_elements

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

With no annotations, the description carries the full behavioral burden and does well: it discloses irreversibility (削除は取り返しがつかない), cascade deletion of descendants, and the dry-run semantics of confirmed, including that the dry run returns the paths and descendant counts. It stops short of stating permission requirements or limits on how many elements may be deleted at once.

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 sentences, front-loaded with the destructive action and cascade scope, then the safety workflow. Every sentence carries required information and nothing is padded.

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 destructive, annotation-free tool with no output schema, the description supplies the missing safety profile and explains what the dry-run returns (paths and descendant counts). An agent has everything needed to call it safely and correctly.

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 100%, so the schema already documents mapId, elementIds and the dry-run meaning of confirmed. The description restates the confirmed workflow rather than adding syntax, format, or edge-case detail beyond it, so the baseline 3 is right.

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?

States a specific verb and resource ('既存マップから要素を削除する') and immediately clarifies scope via the cascade rule (指定した要素とその配下(子孫)を丸ごと削除する). This clearly separates it from siblings like edit_element and move_element, which touch the same resources without removing them.

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?

Prescribes an explicit two-call workflow: first call with confirmed omitted/false to obtain the target list, present it to the user for explicit consent, then re-call with confirmed: true. The when-not condition (do not delete before consent) and the alternative call mode are both spelled out.

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