Skip to main content
Glama
Sign In

HomeMaster

by co.homemaster
OverviewDiscussionsAdmin

Cancel a booking

cancel_booking
DestructiveIdempotent

Cancel a booking this connection made, for the customer, under HomeMaster's usual rules. Two calls. (1) Send reference (the hmb_ or hmr_ request_booking returned), no phone needed; for one visit of a weekly or every-2-weeks plan add visit_date, without it the whole booking is cancelled. The answer (outcome confirm_needed) says what will be cancelled, the fee, the refund and why, with a confirm_code; nothing changes. Tell the customer all of it and get their yes. (2) Call again with the same fields, confirm_code and customer_confirmed: true; the answer (outcome cancelled) says what was refunded or kept. A paid booking our team has not placed an expert on yet cancels free, refunded in full. Other outcomes say why nothing changed and what to do: refused (for a booking not made on this connection or a visit under 2 hours away, the customer manages it on My Bookings or with HomeMaster on WhatsApp; refund_failed: nothing was cancelled, try again in a few minutes). A repeat of a used code returns the first answer, never a second cancel.

Input Schema

NameRequiredDescriptionDefault
phoneNoOptional: only this connection's own bookings can be changed. If sent, the customer's number as they booked with it; it must match. Leave it out rather than ask the customer again.
referenceYesThe reference request_booking returned for this booking (starts with hmb_ or hmr_).
visit_dateNoOptional: the date of the one visit to cancel, YYYY-MM-DD, from booking_status. Without it, the whole booking.
confirm_codeNoSecond call only: the confirm_code the first call returned. Good for 15 minutes.
customer_confirmedNoSecond call only: true when the customer heard the change, its cost and why, and said yes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / phone / description
      Previous value: -"The customer's number, as they booked with it, e.g. 9123 4567. It must match the booking."New value: +"Optional: only this connection's own bookings can be changed. If sent, the customer's number as they booked with it; it must match. Leave it out rather than ask the customer again."
    • changedInput schema / required
      Previous value: -[
-  "reference",
-  "phone"
-]New value: +[
+  "reference"
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive and idempotent, but the description adds the crucial non-obvious trait that the first call changes nothing and returns a 15-minute confirm_code, then spells out fee/refund disclosure obligations and the free-cancel condition. The 'repeat of a used code returns the first answer, never a second cancel' statement corroborates and explains idempotentHint rather than contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The two-step flow is front-loaded and ordered, and each sentence carries operational weight. It is dense with parenthetical asides (outcome names, the refused/refund_failed branches), which slows scanning slightly but does not waste space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, multi-call tool with no output schema, the description covers the full lifecycle: initiation, confirmation, outcome vocabulary, error branches, and retry semantics. There is no material gap an agent would need to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that reference comes from request_booking, that visit_date only applies to weekly or every-2-weeks plans and cancels the whole booking if omitted, and that confirm_code is good for 15 minutes. It stops short of adding anything for phone beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Cancel a booking this connection made') and scopes it to bookings originating from this connection, which cleanly separates it from request_booking and move_booking. An agent can identify the operation and its boundary without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It lays out an explicit two-call protocol with the exact conditions for each step, and names the alternatives for cases it won't handle ('the customer manages it on My Bookings or with HomeMaster on WhatsApp'). It also gives the retry rule for refund_failed and the repeat-code behavior, leaving nothing to inference.

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

All HomeMaster toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources