Skip to main content
Glama

Odile answering lines

by com.odilelabs
OverviewDiscussionsAdmin

Set up an After Hours answering line (prepaid minutes or resolved conversations)

set_up_answering_line

Start setting up an After Hours answering line for the signed-in owner's business: a phone assistant that answers calls forwarded from the business's own number and takes messages and bookings for the owner. Nothing is built or bought until the owner pays: this returns a Stripe checkout link for the first pack, and once it is paid the line is set up automatically and its number and forwarding codes are emailed to the account's address. Only call it after showing the owner https://odilelabs.com/terms and getting a yes (owner_confirmed_terms true). The packs and billing rules are in get_answering_line_offer; a line that already exists is read with get_answering_line and topped up with buy_pack (product 'line_minutes' or 'line_outcomes', matching its billing_mode), not set up twice. United States only: business_phone and owner_mobile take any common US format with the area code and are stored as E.164, and Canadian area codes are refused. hours keys are day names (Monday, monday or mon); a day left out is closed, and omitting hours means Monday to Friday, 9 to 5. Messages reach the owner by email and the owner console; texts stay off until the owner switches them on there. Needs a signed-in connection with the lines:manage permission; limited to 3 set-ups a day per account, and rate limited. Returns { setup_id, status: 'awaiting payment', business_name, business_phone, pack, billing_mode, minutes or outcomes, price_cents, checkout_url, then }.

Input Schema

NameRequiredDescriptionDefault
cityNoThe town the business is in, e.g. "Wellington, FL". The receptionist says it when a caller asks where you are.
packYesThe first pack: min40: 40 minutes; min200: 200 minutes; out50: 50 resolved conversations; out200: 200 resolved conversations. Amounts and billing rules: get_answering_line_offer.
extraNoAnything else the receptionist should know.
hoursNoOpening hours by day name, e.g. {"Monday": {"open": "8:00 AM", "close": "5:00 PM"}, "Sunday": "closed"}. A day left out is closed. Omit entirely for Monday to Friday, 9 to 5.
countryNoOnly US for now.
servicesNoUp to 12 services, e.g. ["drain cleaning", "water heaters"].
languagesNoLanguages besides English the receptionist switches to when a caller does.
descriptionNoWhat the business does, in one line; this is what it tells callers.
owner_mobileYesThe owner's own mobile (US, with area code): their calls to the line are never charged.
business_nameYesThe business name callers should hear, e.g. "Alvarez Plumbing".
business_phoneYesThe business number callers dial today (US, with area code, any common format such as (561) 555-0123). The owner forwards it to the new line.
owner_confirmed_termsYestrue ONLY after you showed the owner https://odilelabs.com/terms and they said yes. Anything else is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Despite annotations covering the basic safety profile, the description adds substantial behavioral context: nothing is built or bought until payment, a Stripe checkout URL is returned, setup happens automatically after payment, forwarding codes are emailed, texts stay off by default, and messages reach the owner by email and console. It also discloses auth requirements (lines:manage), a 3-per-day account limit, rate limiting, US-only restrictions, and the exact return shape.

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 description is dense but front-loaded: it starts with what is being set up, then immediately explains the payment gate and return value. Despite its length, every sentence carries operational information — alternatives, prerequisites, failure/refusal conditions, limits, and defaults — with no filler.

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 complex 12-parameter setup tool with payment, authentication, rate limits, and a nested hours object, the description is complete. It covers prerequisites, side effects, alternatives, geographic limits, defaults, return shape, and post-payment behavior even though no output schema exists.

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 documents every parameter well, setting the baseline at 3. The description still adds useful semantics beyond the schema: US phone formats are stored as E.164 and Canadian area codes are refused, hours keys accept day-name variants, omitted hours default to Monday–Friday 9–5, and owner_mobile calls are never charged.

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 uses a specific verb and resource ('Start setting up an After Hours answering line') and explains what the resulting line does: answers forwarded calls, takes messages and bookings. It clearly distinguishes this setup operation from siblings like get_answering_line, buy_pack, and get_answering_line_offer.

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 gives explicit when-to-use guidance: only after showing the terms and getting owner_confirmed_terms=true, and only for new lines — existing lines are read with get_answering_line and topped up with buy_pack. It also names the offer tool for pack/billing rules and warns against setting up twice.

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

All Odile answering lines 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