Skip to main content
Glama

List open appointment slots

biz_availability
Read-only

Open appointment slots at a business served through this connector, for one date (default today in its own timezone). Businesses served here: Velvet and Clay (velvetandclay, a hair, color and skin studio), Brightpoint Dental (brightpointdental, a family and cosmetic dental practice). Reachable here but not through this tool: Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives) and Kristin Dunn Bookbinding and Design (kdbooks) take no bookings. Each slot has a stable slotId that biz_book accepts; started slots are never returned. A closed day returns none with a reason. closedReason HOURS_UNSTATED is NOT a closed day: say the business has not published hours for that date, never that it is closed.

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD, defaults to today in the business timezone
businessNoWhich business, by name or id. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. An unclear name is REFUSED with the list, not answered about a different business.
businessIdNoAlias for `business`; ignored when `business` is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / business / description
      Previous value: -"Which business, BY NAME OR BY ID. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business."New value: +"Which business, by name or id. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. An unclear name is REFUSED with the list, not answered about a different business."
    • changedInput schema / properties / businessId / description
      Previous value: -"Alias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given."New value: +"Alias for `business`; ignored when `business` is given."
  2. Changed1 schema field changed
    • changedInput schema / properties / business / description
      Previous value: -"Which business, BY NAME OR BY ID. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business."New value: +"Which business, BY NAME OR BY ID. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business."
  3. Changed1 schema field changed
    • changedInput schema / properties / business / description
      Previous value: -"Which business, BY NAME OR BY ID. Optional, defaults to velvetandclay. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives), Kristin Dunn Bookbinding and Design (kdbooks). A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business."New value: +"Which business, BY NAME OR BY ID. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business."
  4. Changed1 schema field changed
    • changedInput schema / properties / business / description
      Previous value: -"Which business, BY NAME OR BY ID. Optional, defaults to velvetandclay. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives). A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business."New value: +"Which business, BY NAME OR BY ID. Optional, defaults to velvetandclay. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives), Kristin Dunn Bookbinding and Design (kdbooks). A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business."
  5. Changed1 schema field changed
    • changedInput schema / properties / business / description
      Previous value: -"Which business, BY NAME OR BY ID. Optional, defaults to velvetandclay. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Long Beach Brunch Bakehouse (longbeachbrunch). A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business."New value: +"Which business, BY NAME OR BY ID. Optional, defaults to velvetandclay. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives). A common short form works too (\"the bakehouse\", \"the dentist\"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business."
  6. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The read-only annotations establish the safety profile, and the description adds substantial behavior beyond them: started slots are never returned, closed days return none with a reason, and HOURS_UNSTATED must not be described as closed. These edge-case disclosures are exactly what an agent needs to interpret results correctly.

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 definition is dense but front-loaded, starting with the core purpose before enumerating supported businesses and result caveats. Every sentence carries operational value, including the business lists and the HOURS_UNSTATED warning.

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 no output schema, the description still explains return contents and edge cases: stable slotId values, absent started slots, closed-day reasons, and the HOURS_UNSTATED distinction. Combined with full schema coverage and read-only annotations, an agent has everything needed to call and interpret it.

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 the schema already documents date, business, and businessId with their defaults and refusal behavior. The description restates some of this but adds no material parameter semantics beyond the schema, making the baseline 3 appropriate.

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 gives a specific verb and resource ('Open appointment slots at a business') and clearly scopes it to one date. It distinguishes the tool from non-booking businesses and points to biz_book for the subsequent booking action, so an agent can identify it without opening 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?

It provides clear usage context: default date, supported businesses, and that slots carry a slotId accepted by biz_book. It does not explicitly contrast with other biz_* siblings such as biz_info or biz_menu, but the operational context is strong enough to guide selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources