Mondovo

Change appointment settings

manage_appointments

DestructiveIdempotent

Change how a site takes appointments. Name only what changes: enabled false pauses bookings (nothing is deleted) and true resumes; mode; the default appointment title / duration_minutes; hours (the whole weekly schedule); timezone; where people can book (website, chat, voice — voice needs the voice add-on); limits (max_per_slot, min_notice_minutes, max_advance_days, buffer_minutes); days off (time_off_add, time_off_remove); emails (remind_day_before / remind_hour_before — reminders to the visitor before a confirmed appointment, on by default; morning_agenda_email — the owner's morning email of the day's appointments). Provided hours replace the whole weekly schedule, time_off_remove deletes selected time-off rows, and supplied settings/reminder switches overwrite those values. Confirm before changing existing schedules or notifications. The result lists what changed in plain words.

Input Schema

Name	Required	Description
`chat`	No	Let the site's chat assistant take appointments
`mode`	No	"instant": visitors pick a free time (still pending until the owner confirms). "request": visitors ask for a time and the owner picks one.
`hours`	No	The WHOLE weekly schedule on the business's clock; replaces the current one. Several ranges per day are fine.
`title`	No	Name of the default appointment, e.g. "15-min intro call"
`voice`	No	Let the voice assistant take appointments (needs the voice add-on; ignored without it)
`enabled`	No	false pauses appointments; true turns them back on
`site_id`	Yes	The site, from list_sites
`website`	No	Let people book on the website
`timezone`	No	IANA time zone the business works in, e.g. "Asia/Kolkata"
`user_goal`	No	Optional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
`max_per_slot`	No	How many people can book the same time
`time_off_add`	No	Days (or parts of days) off, YYYY-MM-DD with optional HH:MM start/end
`remind_by_sms`	No	Also text the reminders to visitors who gave a phone number
`buffer_minutes`	No	Gap kept free between appointments
`time_off_remove`	No	Ids of days off to remove, from get_appointments_status
`duration_minutes`	No	How long the default appointment lasts
`max_advance_days`	No	How far ahead people can book
`remind_day_before`	No	Email the visitor a reminder a day before (confirmed appointments)
`min_notice_minutes`	No	Shortest notice a booking needs
`remind_hour_before`	No	Email the visitor a reminder an hour before
`morning_agenda_email`	No	Email the owner each morning with the day's appointments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / user_goal

Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds substantial context beyond the annotations: `enabled` false pauses bookings with nothing deleted, `hours` replaces the whole weekly schedule, `time_off_remove` deletes selected rows, and supplied settings overwrite existing values. These details explain what is destructive and what is merely paused, complementing destructiveHint=true and idempotentHint=true.

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?

It is front-loaded with the core instruction and the "Name only what changes" rule. The single dense paragraph is long, but for 21 mutable settings it stays mostly free of repetition and each clause carries relevant information.

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?

For a complex 21-parameter mutation tool with no output schema, the description covers partial updates, destructive replacement/deletion behavior, confirmation needs, and what the result contains. It could be more complete on permissions or error cases, but it is sufficient for correct invocation.

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 carries most parameter meaning. The description still adds value by explaining whole-schedule replacement, row deletion, reminder defaults, the voice add-on requirement, and overwrite semantics beyond the field descriptions.

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: "Change how a site takes appointments." It then enumerates the setting families (enabled, mode, hours, limits, emails), making the site-level configuration scope unmistakable and distinguishing it in practice from appointment-instance tools like update_appointment.

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?

It gives useful operating guidance: "Name only what changes" establishes partial-update behavior, and "Confirm before changing existing schedules or notifications" sets a safety norm. It does not explicitly name alternative tools or when not to use this one, so it falls short of full when/when-not guidance.

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

All Mondovo 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?