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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds real value on top by disclosing that the move is implemented as deleting the old struct-{oldParent}-{id} link and creating struct-{newParent}-{id}. That explains why the operation is destructive and what side effects to expect. It stops short of covering the locked-root refusal path or the treatment of the order parameter.

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, both front-loaded: the action first, then the mechanism. No filler, no restatement of the name, and the dependency naming convention is useful rather than decorative.

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 mutation with five parameters, the annotations plus a 100%-covered schema cover safety and parameter meaning, and the description supplies the mechanism. What is missing is the failure/refusal behavior around root placement and project targeting, though those details live in the schema.

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 every parameter, including the subtle confirmRootPlacement and expectedProjectId, is already documented in the schema. The description only restates the parent concept and adds no syntax or format details. Baseline 3 is appropriate.

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 (moves) and resource (block) with the scope qualifier 'under a new parent', so an agent can tell it apart from update_cell or delete_cell. It never names a sibling explicitly nor clarifies the difference from move_content_block or arrange_cells, which keeps it below a 5.

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?

Reparenting is implied by 'Moves a block under a new parent', so the intended use case is inferable. However, there are no explicit when/when-not statements, no mention of the confirmRootPlacement precondition, and no routing to alternatives like arrange_cells for pure reordering.

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