Skip to main content
Glama

Get Booking Destination

get_booking_destination
Read-onlyIdempotent

Returns the public booking or inquiry route for a business. Use this before helping a user book an appointment: it distinguishes an external provider page, an active configured calendar using Advocate, an eligible quote-request form when neither booking route is available, and businesses with no supported destination. For native mode, booking_backend names the calendar Advocate books into and capabilities states whether availability, booking, cancellation and rescheduling are supported through Advocate. Cancellation is per booking: cancel_booking needs the cancel_token confirm_booking returned, or the one in a paid booking's payment receipt, so an agent cannot cancel a booking made on the page or one whose token it never received. External pages are links only; Advocate does not sync their availability or make bookings there. Request mode opens an editable form; sending requires explicit customer consent and confirms no time, price, payment, or booking.

Input Schema

NameRequiredDescriptionDefault
slugYesBusiness slug identifier

Output Schema

NameRequiredDescriptionDefault
urlYes
kindYes
modeYes
slugYes
providerYes
eligibilityYes
capabilitiesNoNative mode only: what an agent can complete through Advocate for this backend. Unsupported actions have no tool; do not claim them.
booking_backendNoNative mode only: which calendar Advocate books into for this business.
guidance_for_agentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / mode / enum
      Previous value: -[
      -  "external",
      -  "native",
      -  "unavailable"
      -]New value: +[
      +  "external",
      +  "native",
      +  "request",
      +  "unavailable"
      +]
  2. Changed2 schema fields changed
    • addedOutput schema / properties / booking_backend
      Added value: +{
      +  "description": "Native mode only: which calendar Advocate books into for this business.",
      +  "enum": [
      +    "advocate",
      +    "google",
      +    "microsoft",
      +    "calendly"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / capabilities
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Native mode only: what an agent can complete through Advocate for this backend. Unsupported actions have no tool; do not claim them.",
      +  "properties": {
      +    "availability": {
      +      "enum": [
      +        "supported",
      +        "unsupported"
      +      ],
      +      "type": "string"
      +    },
      +    "booking": {
      +      "enum": [
      +        "supported",
      +        "unsupported"
      +      ],
      +      "type": "string"
      +    },
      +    "cancellation": {
      +      "enum": [
      +        "supported",
      +        "unsupported"
      +      ],
      +      "type": "string"
      +    },
      +    "rescheduling": {
      +      "enum": [
      +        "supported",
      +        "unsupported"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "availability",
      +    "booking",
      +    "cancellation",
      +    "rescheduling"
      +  ],
      +  "type": "object"
      +}
  3. Changed4 schema fields changed
    • removedOutput schema / properties / eligibility / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / eligibility / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / url / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / url / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  4. Added

TDQS

A4.4/5.0
Behavior4/5

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

The description goes beyond the 'readOnlyHint' by detailing specific behavioral traits like the naming convention for the Advocate calendar ('booking_backend') and the specific capabilities it reports. It also clarifies operational constraints, such as the non-sync nature of external pages.

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?

The description is dense and lengthy, but it avoids fluff entirely. Every sentence contributes to either defining the scope, explaining limitations, or providing operational context, making it highly efficient despite its size.

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?

Given the high complexity of differentiating various booking states and the integration points (Advocate, external links, quote forms), the description is extremely complete. It preemptively addresses common agent pitfalls regarding cancellation and external page interactions.

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?

The input schema coverage is 100%, meaning the schema fully defines the parameter 'slug'. The description adds no semantic meaning to the parameter itself, but rather discusses the context derived from the tool's execution.

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 clearly defines the tool's purpose as returning the 'public booking or inquiry route for a business.' It is highly specific, distinguishing between four possible outcomes: Advocate calendar, external links, quote forms, or no destination.

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 provides an explicit workflow ('Use this before helping a user book an appointment'), and outlines conditional logic based on the outcome (e.g., if 'eligible quote-request form' is returned). It provides critical warnings about limitations, such as how cancellation functions depend on receiving tokens.

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