Move project to another organisation

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

Annotations already flag readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false. The description adds value beyond that: it discloses the dual-role requirement (editor/owner in BOTH orgs), the 409 conflict behavior, and the idempotent-vs-conflict distinction when `name` collides. Useful behavioral context not present in the annotations.

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 front-loaded sentences with no filler. The first sentence delivers the core action and destination constraint; the second packs the source-default semantics, permission requirement, conflict behavior, and a pointer to a sibling tool. Every clause earns its place and everything an agent needs is presented in order of importance.

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 mutating, permission-gated tool with 4 parameters and no output schema, the description covers itself fully: purpose, parameter roles, permissions, error behavior, and a resolution path. Nothing required to call it correctly (roles, destination resolution, name-clash handling) is missing.

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 100%, so the baseline is 3. The description goes further by clarifying the relationship between parameters: `toOrg` is the destination, `org` is the source with default behavior, and `name` is specifically for settling a destination name clash as part of the move. This adds interaction semantics beyond the standalone schema descriptions.

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 states a specific verb and resource ('Move a project out of its current organisation into another one'), names the destination constraint ('the token user can write to'), and clearly differentiates from siblings by describing the move semantics rather than mere rename/delete. It also names the permission requirements, making the operation's scope and target unmistakable.

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 explains when the move conflicts (name taken → 409), how to resolve it (pass `name`), and recommends check_project_name against `toOrg` as a pre-check. This gives clear context and one explicit alternative, though it does not formally enumerate exclusions such as 'use rename_project when staying within the same org'. Clear but not exhaustive on when-not-to-use.

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