Skip to main content
Glama

Odile Labs

by com.odilelabs
OverviewDiscussionsAdmin

Send a business a message or booking

send_to_business
Destructive

Send one request to a business found with find_business_agent, using a skill its card lists: take_message (leave a message), check_availability (read open times), book (book a slot check_availability returned), book_first_available (book the first open slot in up to 5 preferred windows) or cancel_booking (cancel a booking you made). Call find_business_agent first; for a business without a card, use call_business. Say an automated assistant is acting, and get the person's permission before booking. A delivered message cannot be recalled; a booking is undone only with cancel_booking. message_id is the retry key: reuse it unchanged on every retry so the request runs once. If you omit it, an identical request from you counts as a retry only within the same UTC day. Returns the A2A v1.0 {task}: read its state before telling anyone a message was delivered or a booking confirmed. A deposit booking returns INPUT_REQUIRED with a payment_url for the person; it is held 30 minutes and confirmed only after payment, which get_direct_payment checks. Failed, refused and unconfirmed tasks are not charged; costs are in get_m2m_network and your balance in get_direct_usage. Messages and confirmed bookings return thread_id and thread_token: use get_replies to read the business’s replies and reply_to_business to answer in the same conversation. Signed-in requesters may omit callback_number for take_message; anonymous requesters still need their own valid number. Example: biz='harbor-plumbing', skill='take_message', message_id='req-8f2', data={caller_name:'Ana Diaz', callback_number:'+15615550199', need:'Leaking water heater, today if possible'}.

Input Schema

NameRequiredDescriptionDefault
bizYesThe business id from its card: the <biz> in /b/<biz>/ or /c/<biz>/.
dataYesThe skill's fields; put skill beside data, never inside it. take_message: caller_name, callback_number (the person's own E.164 number, never the business's), need, optional on_behalf_of and urgency (low, normal, high or urgent). check_availability: optional service and date (YYYY-MM-DD in the business's time zone). book: slot exactly as check_availability returned it, caller_name, callback_number, need. book_first_available: options (1 to 5 windows in order, each {date, optional after and before as HH:MM, optional service}), fallback (none or take_message), caller_name, callback_number, need. cancel_booking: booking_id and cancel_token from the confirmed booking, optional reason (up to 300 characters); cancelling is not charged and does not refund a booking fee. For take_message only, a signed-in requester may omit callback_number and receive replies in the thread.
skillYesOne skill the business card lists.
targetNoline (default) for a business line (/b/ card); claim for a claimed listing (/c/ card), which takes messages only.
message_idNoYour id for this request; reuse it unchanged on every retry so the request runs once.
approval_idNoOnly when the business approves bookings itself: the action_id (da_...) from its approval_required reply, sent with the same message_id and data once the owner approves.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / data / description
      Previous value: -"The skill's fields; put skill beside data, never inside it. take_message: caller_name, callback_number (the person's own E.164 number, never the business's), need, optional on_behalf_of and urgency (low, normal, high or urgent). check_availability: optional service and date (YYYY-MM-DD in the business's time zone). book: slot exactly as check_availability returned it, caller_name, callback_number, need. book_first_available: options (1 to 5 windows in order, each {date, optional after and before as HH:MM, optional service}), fallback (none or take_message), caller_name, callback_number, need. cancel_booking: booking_id and cancel_token from the confirmed booking, optional reason (up to 300 characters); cancelling is free and does not refund a booking fee. For take_message only, a signed-in requester may omit callback_number and receive replies in the thread."New value: +"The skill's fields; put skill beside data, never inside it. take_message: caller_name, callback_number (the person's own E.164 number, never the business's), need, optional on_behalf_of and urgency (low, normal, high or urgent). check_availability: optional service and date (YYYY-MM-DD in the business's time zone). book: slot exactly as check_availability returned it, caller_name, callback_number, need. book_first_available: options (1 to 5 windows in order, each {date, optional after and before as HH:MM, optional service}), fallback (none or take_message), caller_name, callback_number, need. cancel_booking: booking_id and cancel_token from the confirmed booking, optional reason (up to 300 characters); cancelling is not charged and does not refund a booking fee. For take_message only, a signed-in requester may omit callback_number and receive replies in the thread."
  2. Changed1 schema field changed
    • changedInput schema / properties / data / description
      Previous value: -"The skill's fields; put skill beside data, never inside it. take_message: caller_name, callback_number (the person's own E.164 number, never the business's), need, optional on_behalf_of and urgency (low, normal, high or urgent). check_availability: optional service and date (YYYY-MM-DD in the business's time zone). book: slot exactly as check_availability returned it, caller_name, callback_number, need. book_first_available: options (1 to 5 windows in order, each {date, optional after and before as HH:MM, optional service}), fallback (none or take_message), caller_name, callback_number, need. cancel_booking: booking_id and cancel_token from the confirmed booking, optional reason (up to 300 characters); cancelling is free and does not refund a booking fee."New value: +"The skill's fields; put skill beside data, never inside it. take_message: caller_name, callback_number (the person's own E.164 number, never the business's), need, optional on_behalf_of and urgency (low, normal, high or urgent). check_availability: optional service and date (YYYY-MM-DD in the business's time zone). book: slot exactly as check_availability returned it, caller_name, callback_number, need. book_first_available: options (1 to 5 windows in order, each {date, optional after and before as HH:MM, optional service}), fallback (none or take_message), caller_name, callback_number, need. cancel_booking: booking_id and cancel_token from the confirmed booking, optional reason (up to 300 characters); cancelling is free and does not refund a booking fee. For take_message only, a signed-in requester may omit callback_number and receive replies in the thread."
  3. Changed6 schema fields changed
    • addedInput schema / properties / approval_id / description
      Added value: +"Only when the business approves bookings itself: the action_id (da_...) from its approval_required reply, sent with the same message_id and data once the owner approves."
    • addedInput schema / properties / biz / description
      Added value: +"The business id from its card: the <biz> in /b/<biz>/ or /c/<biz>/."
    • addedInput schema / properties / data / description
      Added value: +"The skill's fields; put skill beside data, never inside it. take_message: caller_name, callback_number (the person's own E.164 number, never the business's), need, optional on_behalf_of and urgency (low, normal, high or urgent). check_availability: optional service and date (YYYY-MM-DD in the business's time zone). book: slot exactly as check_availability returned it, caller_name, callback_number, need. book_first_available: options (1 to 5 windows in order, each {date, optional after and before as HH:MM, optional service}), fallback (none or take_message), caller_name, callback_number, need. cancel_booking: booking_id and cancel_token from the confirmed booking, optional reason (up to 300 characters); cancelling is free and does not refund a booking fee."
    • addedInput schema / properties / message_id / description
      Added value: +"Your id for this request; reuse it unchanged on every retry so the request runs once."
    • addedInput schema / properties / skill / description
      Added value: +"One skill the business card lists."
    • addedInput schema / properties / target / description
      Added value: +"line (default) for a business line (/b/ card); claim for a claimed listing (/c/ card), which takes messages only."
  4. Changed1 schema field changed
    • changedInput schema / properties / skill / enum
      Previous value: -[
-  "take_message",
-  "check_availability",
-  "book",
-  "book_first_available"
-]New value: +[
+  "take_message",
+  "check_availability",
+  "book",
+  "book_first_available",
+  "cancel_booking"
+]
  5. Changed1 schema field changed
    • addedInput schema / properties / approval_id
      Added value: +{
+  "pattern": "^da_[a-f0-9]{24}$",
+  "type": "string"
+}
  6. Changed1 schema field changed
    • changedInput schema / properties / skill / enum
      Previous value: -[
-  "take_message",
-  "check_availability",
-  "book"
-]New value: +[
+  "take_message",
+  "check_availability",
+  "book",
+  "book_first_available"
+]
  7. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false, openWorldHint=true): it discloses that a delivered message cannot be recalled, that a booking is only undone via cancel_booking, that message_id makes the request run once (and the same-UTC-day fallback when omitted), that deposit bookings are held 30 minutes pending payment, and which outcomes are not charged. It also explains the return contract as an A2A task whose state must be read before reporting success.

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?

Front-loaded with the action and the skill list, then prerequisites, then invariants, then return behavior, so an agent can stop reading early. It is a dense single paragraph for a genuinely complex tool, but some clauses (costs, balance lookups) could be pulled into a reference rather than the main description.

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 and six parameters including a free-form nested data object, the description still covers the async A2A task envelope, the INPUT_REQUIRED/payment_url deposit case, thread_id/thread_token reuse, and which failure states incur no charge. Nothing an agent needs to interpret the result or retry safely is missing.

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 schema already carries field-level meaning and the baseline would be 3; the description adds value by explaining message_id as the retry key across the whole request and by supplying a worked example that shows how biz, skill and the nested data fields compose. The approval_id flow and the anonymous-vs-signed-in callback_number distinction are reinforced rather than duplicated verbatim.

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 one request to a business') and immediately enumerates the five skills (take_message, check_availability, book, book_first_available, cancel_booking) that define what the request can be. This distinguishes it from call_business and reply_to_business, which it explicitly routes to for different situations.

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?

Gives explicit ordering ('Call find_business_agent first'), a named fallback ('for a business without a card, use call_business'), and a routing rule after success ('use get_replies ... and reply_to_business'). It also states a precondition ('get the person's permission before booking') and a required disclosure ('Say an automated assistant is acting').

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

All Odile Labs 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