Skip to main content
Glama

import_booking_url

Idempotent

Turn a public booking URL into a callable smb_id for send_message and capture_lead. But schedule_appointment only completes on Cal.com bound to our one connected account — the other 11 always fail schedule_appointment honestly, uncharged. Detects 12 platforms (Cal.com, Calendly, Doctolib, Booksy, Fresha, OpenTable, Setmore, Square, Acuity, Schedulista, Squarespace, BookMyCity). Idempotent — calling twice returns the same smb_id. [free, requires key]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
verticalNoIf omitted, inferred from the booking platform.
booking_urlYesFull URL the user supplied. Must point at one of the 12 supported booking…
capabilitiesNoFree-form capability tags (e.g., ['haircut','color','blowdry']).
country_codeNoISO 3166-1 alpha-2 (e.g. 'US', 'FR'); routes compliance on later sends.
business_nameNoIf omitted, auto-extracted from the page's <title> or og:title.
contact_emailNo
contact_phoneNoIf omitted, the platform integration handles outreach.
idempotency_keyNoRetry key: a 24h replay returns the original receipt, not re-run or charged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / business_name / description
      Previous value: -"Optional override. If omitted, the business name is auto-extracted from the…"New value: +"If omitted, auto-extracted from the page's <title> or og:title."
    • removedInput schema / properties / contact_email / description
      Removed value: -"Optional."
    • changedInput schema / properties / contact_phone / description
      Previous value: -"Optional. If omitted, the platform integration handles outreach."New value: +"If omitted, the platform integration handles outreach."
    • changedInput schema / properties / country_code / description
      Previous value: -"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'). Used for compliance routing on later…"New value: +"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'); routes compliance on later sends."
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional client-supplied key for safe retries. Replaying the same key within 24h returns the original receipt - the operation is NOT re-executed and NOT re-charged."New value: +"Retry key: a 24h replay returns the original receipt, not re-run or charged."
    • changedInput schema / properties / vertical / description
      Previous value: -"Best-guess vertical. If omitted, inferred from the platform (e.g., Doctolib ->…"New value: +"If omitted, inferred from the booking platform."
  2. Changed4 schema fields changed
    • changedInput schema / properties / booking_url / description
      Previous value: -"Full URL the user supplied. Must point at one of the 12 supported booking platforms; auto-detected from the host."New value: +"Full URL the user supplied. Must point at one of the 12 supported booking…"
    • changedInput schema / properties / business_name / description
      Previous value: -"Optional override. If omitted, the business name is auto-extracted from the page's <title> or og:title."New value: +"Optional override. If omitted, the business name is auto-extracted from the…"
    • changedInput schema / properties / country_code / description
      Previous value: -"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'). Used for compliance routing on later send_message calls."New value: +"ISO 3166-1 alpha-2 (e.g. 'US', 'FR'). Used for compliance routing on later…"
    • changedInput schema / properties / vertical / description
      Previous value: -"Best-guess vertical. If omitted, inferred from the platform (e.g., Doctolib -> healthcare, OpenTable -> restaurants)."New value: +"Best-guess vertical. If omitted, inferred from the platform (e.g., Doctolib ->…"
  3. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "description": "Optional client-supplied key for safe retries. Replaying the same key within 24h returns the original receipt - the operation is NOT re-executed and NOT re-charged.",
      +  "maxLength": 128,
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true, and the description reinforces it with 'calling twice returns the same smb_id.' It adds valuable context beyond annotations: the free/requires-key note, the 12-platform detection list, and the honest failure behavior of schedule_appointment on non-Cal.com platforms. It doesn't fully detail side effects or auth requirements, but the idempotency and failure transparency are strong additions.

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 but efficient, packing purpose, limitations, platform list, idempotency, and cost into three sentences. The first sentence front-loads the core purpose. Slight redundancy with the idempotentHint annotation and the platform list could be trimmed, but it earns its place by giving concrete routing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters, no output schema, and a complex platform-detection behavior, the description covers the key operational facts: what it returns (smb_id), idempotency, platform support, and the critical schedule_appointment limitation. It doesn't describe the output shape or error cases, but the core call-and-routing context is complete enough for an agent to select and invoke it correctly.

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 88%, so the schema already documents most parameters well. The description adds context for booking_url (must point at one of the 12 supported platforms) and mentions vertical inference, but it doesn't add much beyond the schema. Baseline 3 is appropriate because the schema carries the heavy lifting.

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 states a specific verb ('Turn a public booking URL into a callable smb_id') and names the downstream tools it feeds (send_message, capture_lead). It also distinguishes itself from schedule_appointment by explicitly noting the Cal.com limitation, which separates it from a sibling tool. This is a clear, resource-specific purpose statement.

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?

The description explicitly says when to use this tool (to convert a booking URL into an smb_id) and when not to rely on it (schedule_appointment only completes on Cal.com bound to one connected account; the other 11 platforms always fail). It also names the alternative schedule_appointment and the failure mode, giving an agent actionable routing guidance.

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.