Skip to main content
Glama
Sign In

Belcome

by app.belcome
OverviewDiscussionsAdmin

Find open times

find_slots
Read-only

Find open times for one service at a business, up to 14 days. Each time comes with a booking_url that opens the business's booking page with the service, professional and time already chosen; give that link to the person to confirm with their name and phone.

Input Schema

NameRequiredDescriptionDefault
fromNoFirst day, YYYY-MM-DD in the location's timezone. Defaults to today.
throughNoLast day, YYYY-MM-DD, at most 13 days after from. Defaults to a week.
businessYesThe business id returned by find_business.
staff_idNoOnly this professional. Leave out for anyone available.
service_idYesService id from list_services.
location_idNoLocation id. Defaults to the first location.
start_time_fromNoOptional earliest start time, inclusive, HH:MM (24-hour) in the location timezone on every searched day. For afternoon use 12:00.
start_time_beforeNoOptional latest start time, exclusive, HH:MM (24-hour) in the location timezone on every searched day. Must be later than start_time_from if both are given. Filters appointment starts, not end times.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / start_time_before
      Added value: +{
+  "description": "Optional latest start time, exclusive, HH:MM (24-hour) in the location timezone on every searched day. Must be later than start_time_from if both are given. Filters appointment starts, not end times.",
+  "type": "string"
+}
    • addedInput schema / properties / start_time_from
      Added value: +{
+  "description": "Optional earliest start time, inclusive, HH:MM (24-hour) in the location timezone on every searched day. For afternoon use 12:00.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds real behavioral value by disclosing the 14-day search ceiling and, critically, that each result carries a pre-filled booking_url — output semantics that matter because there is no output schema. It does not say what an empty result looks like or whether availability is live.

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?

Two dense sentences, front-loaded with what the tool returns and scoped by the day limit. Nothing redundant; every clause carries information an agent needs.

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?

With 8 fully documented parameters, read-only annotations, and no output schema, the remaining burden is describing return values and next steps — which the booking_url sentence does precisely. Nothing needed to invoke or use the result correctly is missing.

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 coverage is 100%, with each of the 8 parameters documented including timezone and HH:MM conventions, so the baseline applies. The description only restates the one-service scope and the date window, adding little beyond the schema.

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 ('Find open times for one service at a business') plus a hard scope limit ('up to 14 days'). That is clearly distinct from every sibling, which are all catalog/metadata listings (list_services, find_business, get_booking_policy).

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?

Explains the downstream workflow explicitly: hand the returned booking_url to the person so they confirm with name and phone. It does not name alternatives or state when NOT to call it (e.g. use list_services first to get service_id), leaving that to the schema's parameter descriptions.

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

All Belcome 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