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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description goes beyond that by disclosing that the booking and any attached payment are moved together, and that eligibility (how close to the appointment, how many moves) varies per pro, which is genuinely useful behavioral context not captured in the schema or 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?

Three dense sentences, front-loaded with the action and identifier source, followed by preconditions and behavioral caveats. Every sentence carries information; the caveat sentence is slightly long but not padded.

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 3-param mutation with no output schema, it covers purpose, identifier source, precondition tool, alternative-avoidance, and payment/policy side effects. The only real omission is what happens on invalid or unavailable target times (error behavior), which is minor given no error contract is exposed.

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 67%; the 'id' parameter is undocumented in the schema but the description tells the agent where to source it (my_bookings), which is the most important clarification. It also reinforces 'same service' as an implicit constraint on the target time, adding meaning beyond the date/time format notes already in the schema.

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/reschedule) and resource (the client's own appointment) and pins the operation to the same service. The parenthetical '(id from my_bookings)' makes clear which identifier to supply, distinguishing it from sibling scheduling tools.

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?

Explicitly prescribes the workflow: verify the target slot with pro_open_times and confirm with the client before acting, plus an explicit anti-pattern ('never book a second one to reschedule') that rules out book_appointment. No explicit when-not conditions or naming of the pro-side move_appointment sibling, so not a full 5.

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