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

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true, idempotentHint=false) by disclosing the side effects (connected calendars updated, appointment.rescheduled event fired), an explicit non-effect ('The customer is not messaged'), and internal pre-checks such as the slot-freeness test where the appointment's own slot is excluded. It also enumerates the full failure surface with status codes (400 invalid_param, 404 not_found, 409 slot_unavailable, 409 not_active), all consistent with a destructive, non-idempotent mutation.

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?

Front-loads the action and destination, then the preconditions, then error codes — a sensible ordering with no filler. The error-code run-on at the end is dense but each clause carries distinct information the caller needs.

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 destructive, non-idempotent mutation with no output schema, the definition covers preconditions, side effects, notification behavior, and every documented failure mode. The one residual gap — whether retrying after a 409 is safe — is minor against the annotations already declaring idempotentHint=false.

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 67% (id and time are documented, date carries only a pattern), and the description adds partial meaning by implying constraints on the time argument: past times yield 400, times outside business hours yield 409 for conversation-less bookings, and time is interpreted in the appointment timezone. It adds nothing about the id parameter or date formatting beyond 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 and resource ('Reschedule an appointment') and immediately narrows scope to 'Moves a pending or confirmed appointment to a new date and time', which separates it from cancel_appointment and from generic update_appointment. An agent can identify the operation without opening any 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?

It gives a clear applicability condition (only pending or confirmed appointments; 409 not_active otherwise) and a business-hours precondition, which implies when the call is valid. However, it never names alternatives — notably update_appointment, the closest sibling, or cancel_appointment — so the agent must infer which tool to pick for adjacent intents.

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