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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds context the annotations do not carry: that the operation is gated on approval from both the root owner and the node owner, and that only human actors may invoke it. It stops short of saying what happens to existing tokens, leases, or child agents in the detached subtree.

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 compact clauses, front-loaded with the effect and followed by the approval constraint and actor restriction. Nothing is wasted, though 'People only' is clipped to the point of near-crypticism.

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?

An output schema exists, so return values need no explanation, and the annotations cover the destructive nature. Still, for a destructive hierarchical mutation with an undocumented required parameter, the description should say more about the confirmation workflow and the consequences for the detached subtree.

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 coverage is only 33%, with idempotency_key the sole documented parameter. The description's mention of owner confirmation gives indirect meaning to confirmation_id, but the required 'node' parameter's format and how to reference a subtree node are 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 gives a concrete verb and effect: 'Make a subtree its own tree', which tells an agent this is a structural re-parenting operation. It does not explicitly contrast with the closely related siblings attach_tenant and move_tenant, so the distinction must be inferred from the names.

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?

'People only' excludes agent actors, and 'the root's and the node's owners confirm' implies a two-party approval precondition. However, there is no explicit guidance on when to pick this over move_tenant or attach_tenant, nor on how the confirmation is obtained before calling.

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