Mondovo

Set up appointments

set_up_appointments

DestructiveIdempotent

Turn on appointments for a business. First call get_appointments_status with include_setup_defaults: true and show the owner those defaults (appointment name and length, instant or request mode, weekly hours, time zone, where people can book) in ONE message, asking only what you cannot know — usually just "does this look right?". Then call this, passing only the fields they changed; anything omitted takes the proposed default. Provided hours replace the whole weekly schedule and supplied settings overwrite those values. Chat and voice take appointments at once; the website's booking form goes live on the next publish. Confirm the owner wants these changes before calling. Never creates items in the Services list. ON A SITE THAT STILL HOLDS SEVERAL DESIGNS this builds the site: Mondovo copies the chosen design into the working site (or reuses the copy made earlier), adds to that, and the response carries its new site_id and a build_transition — relay its tell_user and use the new site_id from then on. Pass variation_id for the design the user picked; omitted, Mondovo uses the design already built or the only one edited, and otherwise answers choose_design so you can ask the user.

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)
`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.
`variation_id`	No	On a site that still holds several designs: the design to build the site from (from list_variations). Mondovo copies it into the working site and adds to that. Omit on a site that is already built.
`duration_minutes`	No	How long the default appointment lasts

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"
+}

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / variation_id

Added value: +{
+  "description": "On a site that still holds several designs: the design to build the site from (from list_variations). Mondovo copies it into the working site and adds to that. Omit on a site that is already built.",
+  "maxLength": 200,
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, but the description adds substantial context beyond them: omitted fields inherit defaults, `hours` replaces the entire weekly schedule, website booking goes live only on next publish while chat/voice activate immediately, no Services items are created, and a multi-design site is built with a new site_id plus a build_transition whose tell_user must be relayed. That is the kind of behavioral disclosure annotations cannot carry.

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?

Purpose and correct sequencing are front-loaded, and nearly every sentence adds concrete information rather than restating the schema. It is dense and long for an 11-param tool, with mid-paragraph ALL-CAPS emphasis that slows reading, but there is little outright filler to cut.

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, non-read-only mutation tool with no output schema, the description covers the pre-call discovery step, field-merging semantics, activation timing per channel, the design-build branch and its returned site_id/build_transition, and a safety confirmation step. An agent has enough to call this correctly without guessing.

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 real semantics beyond the schema: `hours` replaces the whole schedule rather than merging, omitted fields take the proposed default, and `variation_id` has a documented fallback chain (already-built design → only edited design → choose_design). Only minor gaps remain, such as no discussion of what happens to pre-existing appointment data.

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 — 'Turn on appointments for a business' — and then delineates the exact scope, including the non-obvious side effect of building the site on a multi-design site. It names get_appointments_status as the prerequisite sibling and implicitly separates itself from manage_appointments/update_appointment by being the enable/setup call.

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 a precise ordered workflow: call get_appointments_status with include_setup_defaults: true, present all defaults in ONE message, ask only what is unknowable, then call this tool passing only changed fields, after confirming the owner wants the changes. It also gives an explicit alternative path (ask the user via choose_design) when variation_id is ambiguous. This is as explicit as when-to-use guidance gets.

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?