hemmabo_booking_reschedule

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

Despite annotations already declaring destructiveHint=true and readOnlyHint=false, the description adds significant context: it warns that the original dates are released to the host calendar, the original price no longer applies, the booking is updated in place (never recreated), and that Stripe will charge/refund the difference. It also notes rate-limiting, auth requirements, and that the guestToken is required in addition to the bearer token—critical behavioral details beyond the 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?

The description is dense but every sentence adds value. It covers purpose, usage alternatives, exclusions, effects, auth requirements, and parameter specifics in a compact space. The structure flows naturally from what→when-not→behavior→parameters. There is zero filler or redundancy.

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?

Given the complexity of this tool (destructive write, auth nuance, repricing, Stripe interaction), the description is remarkably complete. It covers auth (Bearer + guestToken), destructive effects (dates released, price changes), identity (same reservationId), parameter constraints (new dates ordering), and re-pricing behavior. The output schema likely covers return values, so no need to duplicate that. This is a model of completeness.

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?

The description adds substantial meaning beyond the schema. For guestToken, it explains why it's required even with a valid bearer token, that it's a per-booking secret, and that it must be the exact token from creation. For newCheckIn/newCheckOut it reiterates the ordering constraint and hints at repricing based on night count. For reservationId it explains it's updated in place. This far exceeds what the schema provides, compensating for the 100% schema coverage by adding valuable context.

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 purpose is exceptionally clear: 'Reschedule a confirmed or pending booking to new dates with automatic repricing and Stripe charge/refund.' It names the specific action (reschedule), the target (booking), the key behaviors (repricing, Stripe), and distinguishes from the sibling cancel tool. The verb+resource combination is precise and unambiguous.

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 description provides explicit usage guidance: use when a guest wants to change dates, NOT when they want to end the stay entirely (use hemmabo_booking_cancel). It also warns against use if the booking is cancelled or completed, directing to check hemmabo_booking_status first. It clearly states when to use, when not to use, and names alternatives.

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