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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and the description adds substantial context beyond them: exactly what gets mutated versus preserved, that constraints travel with their task, that deadlines require moveDeadlines: true, that the project end shifts by the same working days, the required project.edit permission, and that the response carries an undo move.

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?

Purpose is front-loaded in the first sentence and each subsequent sentence carries a distinct scheduling rule rather than filler. It is dense and long for a tool description, but almost all content is load-bearing exception logic an agent would otherwise guess wrong.

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?

With no output schema and no annotations covering scheduling semantics, the description compensates fully: it tells the agent what moves, what stays and why, what the return counts and undo field contain, and the permission needed. The only blemish is the phantom dryRun parameter, which is captured under parameter semantics.

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, and the description earns above that by defining semantic behavior for start (equal value returns changed: false and writes nothing) and moveDeadlines (deadlines move only when true). However, it describes a dryRun parameter that does not exist in the input schema, which has additionalProperties: false — an agent may attempt to pass dryRun and be rejected.

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?

Names a specific verb and resource ('Move a whole project to a new start date') and anchors it to a known reference behavior ('the way Microsoft Project's Move Project does'). An agent can distinguish this from update_project or duplicate_project without opening another schema.

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?

Gives rich when-to-use context: it enumerates which tasks move (no actual work) and which stay (actual start, progress, Done status, Planner-sourced dates), plus the dryRun preview path and the no-op case when start equals the current start. It never names a sibling alternative such as update_project for a single-field change, so it falls just short of 5.

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