Skip to main content
Glama
Sign In

HomeMaster

by co.homemaster
OverviewDiscussionsAdmin

Move a visit to another time

move_booking
DestructiveIdempotent

Move one visit of a booking this connection made to another time with the same expert, under HomeMaster's usual rules. Step by step: send reference, no phone needed (and visit_date when the booking has several visits): the answer (outcome pick_a_time) lists the times that visit's own expert is free. With the customer's pick, send new_date, new_weekday and new_start_time: the answer (outcome confirm_needed) says the move, the fee and why, with a confirm_code; nothing changes. Tell the customer and get their yes, then call again with the same fields, confirm_code and customer_confirmed: true (outcome moved; a fee, if any, comes with its payment_url). A booking not paid yet and with no visit arranged answers rebook_needed: book the new time with request_booking, then cancel this one with cancel_booking, free. Anything that cannot be moved here answers refused, with what to do instead.

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.
new_dateNoThe new date, YYYY-MM-DD, from the open times this tool listed.
referenceYesThe reference request_booking returned for this booking (starts with hmb_ or hmr_).
visit_dateNoThe date of the visit to move, YYYY-MM-DD. Needed when the booking has more than one upcoming visit.
new_weekdayNoThe weekday the customer agreed to for the new date. Required with new_date.
confirm_codeNoLast call only: the confirm_code the quote returned. Good for 15 minutes.
new_start_timeNoThe new start time, HH:MM Singapore time, from the open times this tool listed.
customer_confirmedNoLast call only: true when the customer heard the move, 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?

Beyond the annotations, the description explains the two-phase quote/confirm behavior, that nothing changes until confirmation, that the quote is good for 15 minutes, and that any fee comes with a payment_url. It also documents the outcome values an agent should expect and the fallback for refused moves.

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 description is dense but front-loaded, beginning with the core action before moving into the step-by-step sequence. It is appropriately sized for a multi-step workflow, though the long single paragraph could be easier to scan if broken into explicit steps.

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?

There is no output schema, but the description explains the relevant outcome states, fees, payment_url behavior, and fallback paths. For a destructive multi-step booking mutation, this gives the agent enough context to invoke it correctly and understand what happens at each stage.

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 schema already documents each parameter. The description still adds useful call-flow semantics, such as phone being unnecessary, visit_date being needed when there are multiple visits, and confirm_code/customer_confirmed being required only on the final confirmation call.

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 states a specific verb and resource: move one visit of a booking to another time with the same expert. It also scopes the action to bookings this connection made and distinguishes the tool from its siblings by naming the rebooking path when the booking is unpaid and has no arranged visit.

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 gives explicit step-by-step usage: first list open times, then submit a quote, then confirm with confirm_code and customer_confirmed. It also names alternatives for cases that cannot be moved here, specifically request_booking and cancel_booking for rebook_needed cases.

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