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

Beyond the annotations, the description discloses that the old time remains theirs until the new one is written, which clarifies atomicity and aligns with destructiveHint=false. It also adds a real-world caveat about the business redirecting the customer to messaging close to the start time. It does not cover authentication or failure behavior, but the annotations already lower that burden.

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?

The description is short and has no wasted words, but the first sentence is a grammatical fragment that does not front-load the tool's purpose. The second and third sentences are efficient and informative, but the overall structure forces the agent to parse an incomplete opening statement.

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 three-parameter mutation tool with no output schema, the description covers the key behavioral context: when to use it, where the new start comes from, atomicity of the old time, and a near-start caveat. The main omission is an explicit statement of the action itself and differentiation from move_booking, but most operational context is present.

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?

With only 33% schema description coverage, the description adds important meaning for the start parameter by requiring it to come from find_times. booking_id is obvious from its name, and reply_token is documented in the schema. It does not compensate for every gap, but it meaningfully supplements the most ambiguous parameter.

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 is an elliptical fragment ('Only when the customer asks, to a start from find_times') that never states the action verb explicitly; the agent must rely on the name and title 'Move a booking' to infer that this reschedules a booking. It also does not distinguish this tool from the sibling move_booking, leaving ambiguity about which one to call.

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?

It gives a clear when-to-use condition ('Only when the customer asks') and a prerequisite source for the new time ('a start from find_times'). It also notes an alternative path near the start time ('the business may ask them to message it instead'), though it does not explicitly name a sibling alternative tool.

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