clone_case

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral scope beyond that: run history is deliberately excluded from the copy, and `changes` follows update_case semantics. It does not say what happens if the target case_id already exists, which matters for a non-idempotent mutation.

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?

Two sentences, no filler. The core action and its content scope come first, followed by the use case, with the parameter note folded into a parenthetical rather than a separate paragraph.

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 mutation with no output schema, the description covers the essentials an agent needs: what is copied, what is not, and how `changes` are expressed. Remaining gaps are the uniqueness behavior of the target case_id and the meaning of `title`/`language`.

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 0%, so the description must compensate and it only partly does: it defines the shape and meaning of `changes` ({dotted.path: value}, referencing update_case) and implies `case_id` is the identifier for the new case. The `title` and `language` parameters are never mentioned, and the language enum (ja/en/zh, default ja) is left entirely unexplained.

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 names a specific verb and resource ("Copy a case"), then bounds the operation by enumerating what is carried over (geometry, face roles, materials, settings) and what is not (its runs). This makes it clearly distinguishable from create_case, import_case, and export_case in the sibling list.

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 motivating scenario: "Use it to try a design variant without losing the original." That tells the agent when the tool is appropriate, but it never names an alternative or an exclusion (e.g. when to use create_case or import_case instead), so the routing guidance is contextual rather than decisive.

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