LobbyStack

Reschedule an appointment

reschedule_appointment

DestructiveIdempotent

Moves an appointment to a new open time for the same service, with the same staff member unless you pass staff_id. Works only when booking_mode is instant. Find the new time with check_availability for the appointment's service_id. Fails with slot_unavailable if the time is taken.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "appointment_id": "<appointment_id>",
      "starts_at": "<starts_at>"
    },
    "name": "reschedule_appointment"
  }
}

Input Schema

Name	Required	Description
`staff_id`	No	Move the appointment to this active staff member. Defaults to the current one. Check availability with the same staff_id first.
`starts_at`	Yes	A starts_at value from check_availability, unchanged.
`appointment_id`	Yes	The appointment id (UUID).

Output Schema

Name	Required	Description
`id`	Yes	Stable identifier (UUID).
`notes`	Yes	Notes on the appointment. The receptionist can read them to a verified caller.
`source`	Yes	Where the booking came from, for example voice, web_chat, dashboard or api.
`status`	Yes
`ends_at`	Yes	ISO 8601 timestamp in UTC.
`staff_id`	Yes	Stable identifier (UUID).
`timezone`	Yes
`starts_at`	Yes	ISO 8601 timestamp in UTC.
`contact_id`	Yes	Stable identifier (UUID).
`created_at`	Yes	ISO 8601 timestamp in UTC.
`service_id`	Yes	Stable identifier (UUID).
`staff_name`	Yes
`updated_at`	Yes	ISO 8601 timestamp in UTC.
`contact_name`	Yes
`service_name`	Yes
`contact_phone`	Yes
`calendar_sync_status`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Adds meaningful context beyond the annotations: the booking_mode gate and the specific failure mode 'slot_unavailable' if the time is taken. It also explains that service and staff are carried over by default. However, with destructiveHint=true declared, it never says what happens to the original slot/booking, which is the main risk an agent needs to know.

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

Conciseness5/5

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

Three short sentences, front-loaded with what the tool does, then the precondition, then the discovery step and error mode. No redundant or filler wording.

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

Completeness4/5

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

Covers the core workflow (find slot via check_availability, then reschedule), the mode restriction, and the error path; an output schema exists so return values need not be described. The only gap is the destructive side effect on the existing booking, which is left unexplained despite destructiveHint=true.

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

Parameters3/5

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

Schema description coverage is 100%, so both required parameters and staff_id are already documented. The description adds the useful constraint that the service cannot change and restates the staff_id default, but contributes no new syntax or format guidance beyond the schema, which is the baseline expectation at full coverage.

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?

States a specific verb and resource ('Moves an appointment to a new open time') plus the scoping rules (same service, same staff unless staff_id passed). This clearly separates it from book_appointment and cancel_appointment without needing 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 Guidelines4/5

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

Gives a hard precondition ('Works only when booking_mode is instant') and routes the agent to check_availability for the appointment's service_id before calling. It does not explicitly contrast with cancel_appointment or book_appointment for edge cases (e.g., when to cancel-and-rebook instead), so it stops short of full when/when-not coverage.

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

All LobbyStack tools Inspect

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

Need Help?