Book It

Send a booking request

request_booking

Send a Book It business a booking request on a person's behalf. Collects only the person's name, phone, ZIP, what they need and a preferred time. The business receives it by email and in its inbox and confirms a time with the person directly; the request is never a confirmed appointment. Requires consent_confirmed true, which means the person read and agreed to the business's booking_consent_text (from get_services or check_availability). US and Canadian phone numbers only. A repeat request from the same phone to the same business within 24 hours returns the first request instead of sending another.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "business_id": "<business_id>",
      "customer_name": "<customer_name>",
      "customer_phone": "<customer_phone>",
      "customer_zip": "<customer_zip>",
      "need": "<need>",
      "consent_confirmed": "<consent_confirmed>"
    },
    "name": "request_booking"
  }
}

Input Schema

Name	Required	Description
`need`	Yes	What the person needs, in their words, such as "Furnace runs but blows cold air."
`service_id`	No	Optional service_id from get_services.
`business_id`	Yes	The business_id exactly as find_provider returned it, such as "juniper-ridge-roofing".
`customer_zip`	Yes	The 5-digit ZIP where the work is. It must be in the business's service area.
`customer_name`	Yes	The person's name, at least a first name.
`customer_phone`	Yes	A US or Canadian phone number the business can call or text, such as (406) 555-0123.
`consent_confirmed`	Yes	True only after the person read the business's booking_consent_text and agreed to it.
`preferred_time_note`	No	A short preferred time in words, such as "any weekday morning", when no window fits.
`preferred_window_id`	No	A window_id from check_availability, such as "2026-10-15@08:00-12:00".

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well beyond the annotations: describes delivery (email + inbox), that the business confirms directly, that it's never a confirmed appointment, consent semantics, region limits, and a 24-hour same-phone/same-business dedup. One nuance: the 24-hour dedup statement reads as idempotent within that narrow scope while idempotentHint is false, but the dedup is scoped to phone+business and time-bounded, so it does not outright contradict the annotation.

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?

Four sentences, each carrying distinct information (action, inputs/delivery, consent gate, dedup/region limits), with the core behavior front-loaded and no filler. The length is justified by the number of behaviors disclosed.

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 9-parameter write tool with no output schema, the description covers everything an agent needs: prerequisite consent, what data is collected, delivery mechanism, confirmation expectations, region restriction, and repeat-request behavior. Annotations already carry the safety profile (non-readonly, non-destructive, open-world), so this is complete.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that consent_confirmed means the person read booking_consent_text from get_services/check_availability, and it adds the US/Canada phone constraint that the schema only hints at. It also names the fields collected, reinforcing the parameter set.

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 ('Send a ... booking request on a person's behalf') and immediately clarifies what the tool is not ('the request is never a confirmed appointment'). That framing, plus the emphasis on business/need/time, distinguishes it cleanly from find_provider, check_availability, and quote_range without needing their schemas.

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?

Clear operational context: it names the prerequisite (consent_confirmed true, sourced from get_services or check_availability) and the constraint (US/Canadian numbers only), which effectively routes the agent through the flow. It stops short of explicit when-not-to-use or a direct contrast against quote_range, so it's a strong 4 rather than a 5.

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

All Book It 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?