Keepp

Change a bookable offering

update_booking_unit

DestructiveIdempotent

Changes an offering. Send only what changes: fields left out keep their values, and inside config each setting left out keeps its value too — so changing the image or title never touches the schedule. Changing the mode (slots to nights) needs the whole config for the new mode. Bookings already taken are not moved. If the offering is on the page, the page is republished so it shows the change. Show what changes, including price, currency and timezone. Before calling, show the person exactly what will be saved and get their explicit yes in the conversation. Never assume a currency.

Input Schema

Name	Required	Description
`mode`	No	"slots" for appointments of a fixed length on a weekly schedule; "nights" for stays. They take different config fields and mixing them is refused.
`name`	No	What the offering is called.
`config`	No	Only the settings that change; the rest keep their values. Changing the mode needs the whole setup for the new one.
`status`	No	Defaults to active.
`business`	Yes	The page handle, as it appears in keepp.link/<handle>.
`bookingUnitId`	Yes	From list_catalog.

Output Schema

Name	Required	Description
`updated`	Yes	False when the person declined, and nothing was updated.
`bookingUnitId`	No
`pageRefreshed`	No	Whether the published page was republished to show the change. False when it is not on the page.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / config / properties / googleConnectorId / description

Previous value: -"The Google account whose calendar this offering checks: an account id from list_connectors. New bookings are refused at any time that calendar shows as busy, bookings are added to that account's Keepp Events calendar, and Google Meet links are made there. Leave it out to check no calendar. Required when meeting.provider is \"google_meet\"."New value: +"The Google account whose calendar this offering checks: an account id from list_connectors. Appointments are refused at any time that calendar shows as busy, and a night of a stay when the calendar is busy for that whole day. Bookings are added to that account's Keepp Events calendar, and Google Meet links are made there. Leave it out to check no calendar. Required when meeting.provider is \"google_meet\"."

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / config / properties / googleConnectorId

Added value: +{
+  "description": "The Google account whose calendar this offering checks: an account id from list_connectors. New bookings are refused at any time that calendar shows as busy, bookings are added to that account's Keepp Events calendar, and Google Meet links are made there. Leave it out to check no calendar. Required when meeting.provider is \"google_meet\".",
+  "type": "string"
+}

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / config / properties / pricing / description

Previous value: -"How it is paid for. \"stripe\" takes real money and needs Stripe connected; \"display\" only shows a price; \"free\" is no charge. Free and display need a Pro plan. Ask the person which currency they charge in before suggesting a price — never assume US dollars, and say the currency whenever you quote an amount."New value: +"How it is paid for. \"stripe\" takes real money and needs Stripe connected; \"display\" only shows a price; \"free\" is no charge. Ask the person which currency they charge in before suggesting a price — never assume US dollars, and say the currency whenever you quote an amount."

First observedOct 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond annotations, the description discloses critical behavior: omitted fields preserve existing values, nested config fields also merge, mode changes need the full new-mode config, existing bookings are not moved, and page publication is a side effect. It also adds the required human confirmation and currency behavior, so the agent knows the operational risk profile.

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?

The description is front-loaded with the core action and then moves through merge semantics, mode changes, side effects, and confirmation requirements. Every sentence adds practical guidance, and there is no redundant restatement of schema details.

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 complex mutation with nested objects, side effects, and a destructive annotation, the description covers the important gaps: partial-update behavior, mode transitions, booking preservation, page republishing, and confirmation before saving. With a full schema and output schema present, no essential invocation context is missing.

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 description coverage is 100%, so the schema already documents most parameter meanings. The description still adds important update semantics not fully captured elsewhere: omitted top-level and nested config fields keep their values, and a mode change requires the whole config for the new mode.

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

Purpose4/5

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

The description gives a clear verb and resource: it "Changes an offering." Combined with the title "Change a bookable offering" and required business/bookingUnitId identifiers, an agent can tell what object is being updated. It does not explicitly differentiate this from siblings like update_product, which keeps it from a 5.

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 concrete operating guidance: send only changed fields, config is merged key by key, changing mode requires the whole new config, and the user must be shown the exact save and explicitly confirm. It does not name alternative tools or state when not to use this one, so it is strong but not a full alternative-routing guideline.

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

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