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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds the null-unassign semantics and hints that linked-file movement is not automatic, but leaves critical behavior unexplained: what happens to jobs when unassigned, whether partial batches can fail, and what permissions are required for a destructive operation.

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 short sentences with the core action front-loaded and no filler. The final sentence is compact to the point of being cryptic, but nothing is wasted.

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?

This is a destructive, non-idempotent batch mutation with no output schema and zero parameter documentation in the schema, yet the description is two lines long. It omits partial-failure behavior, permission requirements, the effect of unassignment on the moved resources, and the meaning/default of move_linked_files — all of which an agent needs before invoking a destructive call.

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. It explains the null case for target_project_id (schema only says null is allowed) and gestures at move_linked_files via 'Linked file movement is explicit', but that phrase is ambiguous and never states the parameter is a boolean toggle or what its default is. The resources array's batching limits (1-6 groups, up to 500 ids) are undocumented.

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 ('Move ... into a project') plus the exact resource types (jobs, files, workflows, workflow runs), which an agent can match against the type enum. It is clearly a mutation rather than a listing/creation tool like create_project or list_projects, though it never names a sibling explicitly.

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 one real usage rule given is 'Set target_project_id to null to unassign', which is genuinely useful and not inferable from the schema alone. There is no guidance on when to prefer this over creating a project or moving items individually, and no prerequisites or preconditions are stated.

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