A phone line for your app or business that answers calls, takes messages and bookings.
Scored across 9 tools
Each tool has a distinct role: reading the offer, setting up a new line, topping up an existing line, listing lines, retrieving calls/messages, creating SIP credentials, running a test line, and reading a benchmark. The descriptions explicitly cross-reference related tools and warn against misuse, so an agent can reliably choose the right one.
All names use consistent snake_case with a clear verb_noun pattern: get_*, buy_pack, set_up_answering_line, try_answering_line. There is no mixing of camelCase or vague standalone verbs.
Nine tools is well-scoped for the domain, covering offer, setup, billing, line reading, calls, messages, SIP, testing, and benchmarking without excessive sprawl.
Core workflows are covered: offer discovery, setup, top-up, line listing, call/message retrieval, SIP access, testing, and benchmarking. However, line lifecycle operations such as pause, edit, close, and transcript/audio access are explicitly console-only, leaving notable gaps an agent cannot perform directly.
Returns a one-time Stripe checkout link for a prepaid pack, to top up something that already exists; to start a new answering line use set_up_answering_line. The customer opens the link and pays on Stripe's own page, and this connection never sees the card. Only call it when the customer asked to buy, and tell them the price first. product picks what is bought: 'line_minutes' (phone minutes for an After Hours line; line_id required; min40: 40 minutes for $10; min200: 200 minutes for $50), 'line_outcomes' (resolved conversations for an outcome line; line_id required; out50: 50 resolved conversations for $24.50; out200: 200 resolved conversations for $98), 'direct' (Direct credits: direct100c, direct1000, direct10000), 'formats' (Odile Formats credits: small, medium, large), 'photos' (Plate API photo credits: starter: 1000 photos for $10; growth: 5000 photos for $45; scale: 20000 photos for $160), 'minutes' (meeting minutes, only where Meeting Notes is on) or 'calls' (legacy per-call lines only; line_id required). For line products the pack must match the line's billing_mode. What was paid is added within a minute of payment, whatever device paid it. Nothing renews. Needs a signed-in connection with the billing:checkout permission; rate limited per account. Returns { checkout_url, product, pack, price_cents, units, unit, then }.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes | The pack id: formats small | medium | large; minutes m200 | m600 | m2000; calls calls10 | calls50; phone minutes min40 | min200; outcomes out50 | out200; photos starter | growth | scale; direct direct100c | direct1000 | direct10000. | |
| line_id | No | For product 'calls', 'line_minutes' or 'line_outcomes': the line_id from get_answering_line. | |
| product | Yes | 'formats' credits, meeting 'minutes', phone 'line_minutes', resolved 'line_outcomes', Plate API 'photos', legacy answered 'calls' or 'direct' Direct credits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: the link is one-time, payment happens on Stripe's own page, the connection never sees the card, credits land within a minute regardless of device, nothing renews, and the call requires a signed-in connection with billing:checkout permission and is rate limited per account. This is exactly the context the readOnly/openWorld/idempotent hints cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical constraint and the sibling exclusion are front-loaded, and the return shape is stated last. It is a dense single block, though, and the product enumeration partially repeats the schema enum, which costs some readability against a tool an agent only calls occasionally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description supplies both the preconditions (permission, user consent, price disclosure) and an explicit return shape ({ checkout_url, product, pack, price_cents, units, unit, then }). Nothing material an agent needs before calling is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, but the description adds real meaning: it ties each product value to concrete pack ids, prices and units (min40 = 40 minutes for $10, out200 = 200 resolved conversations for $98), and states when line_id is required. That pricing and unit mapping is information the schema does not carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and artifact: 'Returns a one-time Stripe checkout link for a prepaid pack,' and immediately scopes it as topping up something that already exists. It distinguishes itself from set_up_answering_line by name, so an agent can route between the two without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit preconditions: 'Only call it when the customer asked to buy, and tell them the price first,' plus the alternative 'to start a new answering line use set_up_answering_line.' It also states the constraint that for line products the pack must match the line's billing_mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signed-in owner's own After Hours answering lines and any set-ups still awaiting payment (under pending). Use it first: it returns the line_id that get_line_calls, get_line_messages, get_sip_address and buy_pack need. For each line it returns status (live, queued, setting up or closed), number, billing_mode, balance (seconds, outcomes or legacy calls; minutes_remaining to one decimal for minute lines, outcomes_remaining for outcome lines), forwarding (per carrier, the code that starts forwarding and, where the carrier has one, the stop code that turns it off) and the latest 10 recent_calls, with callers shown by their last four digits only. The full call list is get_line_calls and the messages callers left are get_line_messages. There is no tool to pause, edit or close a line: stop forwarding with the stop code, and use the owner console (https://odilelabs.com/owner) for settings, billing, call audio and transcripts. Needs lines:manage; changes nothing; rate limited per account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description adds material context beyond them: lines:manage permission requirement, per-account rate limiting, confidentiality behavior (callers masked to last four digits), and what is absent (no pause/edit/close). This is exactly the added-value layer annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the 'use it first' directive, then return fields, then escape hatches — a sensible order. It is a dense single paragraph with a long parenthetical on balance units and forwarding codes, but almost every clause carries decision-relevant information given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must document returns and does: status enum values, billing_mode, balance semantics per line type, forwarding start/stop codes per carrier, and the 10-call recent_calls cap with masking. Permission scope, idempotence and the absence of mutation tools are all covered, leaving no gap an agent would hit when calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to disambiguate and the baseline applies. The description instead spends its words on return shape, which is the right trade-off; no parameter-level meaning is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — listing the signed-in owner's own After Hours answering lines plus unpaid pending set-ups — and scopes it to the owner only. An agent can distinguish it immediately from get_line_calls, get_line_messages, get_answering_line_offer and set_up_answering_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says "Use it first" and explains why: it yields the line_id that get_line_calls, get_line_messages, get_sip_address and buy_pack require. It also names the alternatives for the sub-resources and states outright that no pause/edit/close tool exists, routing that work to the owner console.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the offer for starting a new After Hours answering line: a phone assistant that picks up the calls an owner forwards from their own business number, takes messages and bookings and tells the owner. Use it before set_up_answering_line, to tell the owner exactly what they would buy. It covers the prepaid minute packs, the per-resolved-conversation packs, the billing rules and what happens when a balance reaches zero. It covers After Hours lines only: Direct credit costs are in get_m2m_network and an existing line's balance is in get_answering_line. Offered in: US. The values come from the same tables checkout charges from, so they cannot drift from what is billed. Takes no arguments, needs no sign-in, reads no account and changes nothing. Returns { product, packs[{id, minutes, cents}], per_minute_cents, min_billable_seconds, billing_rule, at_zero, outcome_packs[{id, outcomes, cents}], per_outcome_cents, outcome_billing_rule, outcomes_at_zero, countries[], owner_must[], terms_url, set_up_with, top_up_with }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotency, but the description adds real context: no sign-in, no account read, no side effects, US-only availability, and that values come from the same tables as checkout so they cannot drift from billing. The lack of any note on caching/staleness or rate limits keeps it just short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the 'use before set_up_answering_line' instruction are front-loaded, and each subsequent sentence covers a distinct concern (scope, geography, data provenance, side-effect profile, return shape). The long inline return-field list is dense and slightly repetitive with 'reads no account and changes nothing', but it earns most of its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the returned fields (packs, per_minute_cents, billing_rule, at_zero, outcome packs, countries, owner_must, terms_url, and follow-up tools). Combined with the usage instructions and effect profile, an agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4; the description confirms 'Takes no arguments', which is a small but useful reinforcement. There is nothing further to document on this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific verb and resource ('Read the offer for starting a new After Hours answering line') and immediately defines what the product is. It explicitly scopes itself to After Hours lines and names where other cost data lives (get_m2m_network, get_answering_line), so an agent can distinguish it from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Use it before set_up_answering_line, to tell the owner exactly what they would buy.' It also names the alternatives and their coverage boundaries ('Direct credit costs are in get_m2m_network and an existing line's balance is in get_answering_line'), leaving no ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the incoming calls answered by one of the signed-in owner's own lines, newest first, with the full caller number (E.164 or null) that get_answering_line shows only as its last four digits. Each item has id, at (ISO), caller, duration_seconds, summary when there is one, and urgent when known. Pass the line_id from get_answering_line; limit sets the page size, and to read further back pass the previous result's next_before as before (next_before is null when there is nothing older). It covers recent calls only, so older ones may not be returned. No audio links or transcripts: open the call in the owner console (https://odilelabs.com/owner). The messages callers left are in get_line_messages, and calls you placed with call_business are read with get_call_result. Needs lines:manage; changes nothing; rate limited per account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 25, max 100. | |
| before | No | ISO timestamp cursor: only calls before this. | |
| line_id | Yes | From get_answering_line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses the permission scope (lines:manage), that it 'changes nothing', per-account rate limiting, the recency ceiling, and the absence of audio links or transcripts with a URL to get them. It also describes pagination mechanics (next_before null signals no older page).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the differentiating detail, then pagination, then exclusions. It is dense and multi-clause with several semicolon-chained ideas in the final sentences, which costs a little readability, but essentially every sentence carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating every returned field (id, at, caller, duration_seconds, summary, urgent, next_before). Combined with paging, auth, and scope limits, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: line_id's provenance, that limit is a page size, and that before should be fed the previous result's next_before rather than an arbitrary timestamp. It stops short of restating the 1-100 range or the 40-char cursor limit, which the schema already carries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the incoming calls answered by one of the signed-in owner's own lines'), plus ordering ('newest first') and the key differentiator from get_answering_line (full E.164 caller number vs last four digits). An agent can distinguish it from get_line_messages and get_call_result by the explicit routing sentences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the prerequisite source for line_id (get_answering_line) and explicitly routes three sibling cases: voicemail content to get_line_messages, outbound calls to get_call_result, audio/transcripts to the owner console. It also states a when-not condition ('covers recent calls only, so older ones may not be returned').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the messages the answering line took from callers for one of the signed-in owner's own lines, newest first. Each item has id, at (ISO), name, phone, message and urgent, so it holds callers' names and phone numbers. Pass the line_id from get_answering_line; limit sets the page size, and to read further back pass the previous result's next_before as before (next_before is null when there is nothing older). It reaches back through at most the 500 most recent messages. The calls themselves, with duration and summary, are in get_line_calls. Replies from businesses you contacted through Direct are in get_replies. Needs lines:manage; changes nothing; rate limited per account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 25, max 100. | |
| before | No | ISO timestamp cursor: only messages before this. | |
| line_id | Yes | From get_answering_line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that results contain caller names and phone numbers (PII), that the tool reaches back only through the 500 most recent messages, that it requires lines:manage, and that it is rate limited per account. These are material behavioral facts not present in the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded and well organized: purpose and ordering first, result fields next, then pagination, alternatives, and operational constraints. Every sentence adds actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the returned item shape (id, at, name, phone, message, urgent), pagination termination behavior, retention limit, permission requirement, and related tools. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 pagination semantics beyond the schema: limit is page size, before should be the previous result's next_before, and next_before is null when no older messages exist. It does not add much about line_id or limit bounds beyond the schema, but the cursor-chaining explanation is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List the messages the answering line took from callers for one of the signed-in owner's own lines, newest first') and explicitly distinguishes the tool from get_line_calls and get_replies. An agent can identify exactly what this returns without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states where line_id comes from ('Pass the line_id from get_answering_line'), explains how to paginate via next_before and before, and names the sibling tools that cover calls and Direct replies. When to use this versus alternatives is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Odile Labs' published benchmark of AI phone answering products: real test calls placed to public lines, scored against stated measures. Use it when someone asks how AI phone answering handles real calls, or to compare named products. Vendor-run by Odile Labs (which sells After Hours and Dusklin), so not independent. It does not test the caller's own line (read_more.free_line_check does). Call it with no arguments first, then narrow with line_id and scenario_id; both come from that first response, and an unknown id returns an error listing the valid ones. include_evidence adds the quoted transcript behind each point (much longer output). Returns { source, date, calls, minutes, run_by, limitations, fairness_note, scenarios[{id,name,brief}], lines[{id, vendor, business, kind, answers_as, list_price, ranked, points, possible, by_scenario{<scenario_id>:{points, possible, answered, first_words_s, ai_disclosed_unprompted, reply_language, price_quoted, measures}}}], read_more }. Needs no sign-in; reads a published file and changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| line_id | No | Only this tested line, e.g. 'afterhours-plumbing', 'afterhours-vet', 'rosie', 'myaifrontdesk' or 'dialzara'. Omit for every line. | |
| scenario_id | No | Only this scenario: 'emergency' (leak after hours), 'booking' (book a slot), 'price' (price probe), 'disclosure' (are you real?) or 'spanish' (caller in Spanish). Omit for all. | |
| include_evidence | No | Default false: each scenario's measures come back as strings like 'yes: <measure>'. true: measures come back as [{measure, score (0 or 1), evidence (quoted transcript)}] (much longer output). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/no-destructive, but the description adds real context beyond them: vendor-run and self-interested ('not independent'), no sign-in required, no changes made, and unknown ids return an error listing valid values. The only gap is nothing about caching/freshness aside from the 'date' field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what it reads and the caveat, then the usage rule, then the parameter workflow. It is dense and slightly overlong, with the full return-shape enumeration taking a lot of space that could be summarized, but every sentence carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by naming the return fields, including scenario and per-line breakouts. Combined with the bias disclaimer, calling sequence, and error behavior, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning the schema lacks: both ids are derived from the first response, and an invalid id errors with the valid list. It also explains that include_evidence trades output size for quoted transcripts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read Odile Labs' published benchmark of AI phone answering products') with the scope of what is measured ('real test calls placed to public lines, scored against stated measures'). It explicitly distinguishes itself from the sibling read_more.free_line_check by saying it does not test the caller's own line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit triggers ('when someone asks how AI phone answering handles real calls, or to compare named products') and a named alternative with its selecting condition. It also prescribes a call sequence: no arguments first, then narrow with ids taken from that response.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create (first call) or read the SIP address and private trunk credentials for one of the signed-in owner's answering lines, so the owner's phone system can send calls to the line over SIP, with no phone number, instead of forwarding a number. For the line's number and forwarding codes use get_answering_line. Pass the line_id from get_answering_line; a line that is still being set up returns an error. Returns { alias, sip_uri, sip_uri_tls, username, password }; keep the username and password private. The address is created once and repeat calls return the same one. SIP calls use the line's normal balance with no separate SIP charge. Needs lines:manage; rate limited per account.
| Name | Required | Description | Default |
|---|---|---|---|
| line_id | Yes | From get_answering_line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses the credential fields returned, that credentials must be kept private, that creation happens once with repeat calls returning the same address, that SIP calls draw on the normal balance with no separate charge, the required scope lines:manage, and per-account rate limiting. readOnlyHint=false and idempotentHint=true are consistent with 'create on first call, repeat calls return the same one'. Only the exact error shape is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the create/read duality and the resource, followed by tight sentences covering return fields, idempotency, billing, permissions, and rate limits. The opening sentence is long and packs several ideas, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating the return object's fields. Preconditions, permissions, billing implications, idempotency, and rate limits are all covered, which is more than enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single parameter is already documented. The description still adds meaning by tying the value's origin to get_answering_line and by stating that a line still being set up causes an error.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs ('Create (first call) or read'), a precise resource ('SIP address and private trunk credentials'), and scope ('one of the signed-in owner's answering lines'), then explains the end goal (phone system sends calls over SIP with no number). It explicitly separates itself from get_answering_line, which handles the number and forwarding codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative (get_answering_line) and what it is for, tells the agent to pass the line_id obtained from it, and states the precondition failure ('a line that is still being set up returns an error'). When-to-use, prerequisite, and error condition are all given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 }.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | The town the business is in, e.g. "Wellington, FL". The receptionist says it when a caller asks where you are. | |
| pack | Yes | The first pack: min40: 40 minutes; min200: 200 minutes; out50: 50 resolved conversations; out200: 200 resolved conversations. Amounts and billing rules: get_answering_line_offer. | |
| extra | No | Anything else the receptionist should know. | |
| hours | No | Opening 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. | |
| country | No | Only US for now. | |
| services | No | Up to 12 services, e.g. ["drain cleaning", "water heaters"]. | |
| languages | No | Languages besides English the receptionist switches to when a caller does. | |
| description | No | What the business does, in one line; this is what it tells callers. | |
| owner_mobile | Yes | The owner's own mobile (US, with area code): their calls to the line are never charged. | |
| business_name | Yes | The business name callers should hear, e.g. "Alvarez Plumbing". | |
| business_phone | Yes | The 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_terms | Yes | true ONLY after you showed the owner https://odilelabs.com/terms and they said yes. Anything else is refused. |
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.
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.
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.
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.
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.
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.
Create a test call so you can hear an After Hours answering line before anything is set up: it returns a shared test phone number and a 4-digit code (valid 24 hours, up to 5 calls). Calling the number and keying the code reaches a phone assistant answering as the business you describe, and hear_url plays the same assistant in a browser. Nothing is booked, sent or charged on a test line, and it is not a real line: for one on the business's own number use set_up_answering_line. business_name and trade are required; trade sets what the assistant knows to ask, and area, hours, services and timezone shape what it says. Needs a signed-in account (any permissions); limited to 3 test lines a day per account, and rate limited. Returns { sandbox, test_number, test_number_e164, test_code, hear_url, expires_at, calls_allowed, how }.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Town or area, e.g. "Wellington, FL". | |
| hours | No | Opening hours in words, e.g. "Mon-Fri 8 AM to 5 PM, closed weekends". | |
| trade | Yes | The kind of business; it sets what the receptionist knows to ask. | |
| services | No | Services, e.g. ["drain cleaning", "water heaters"]. | |
| timezone | No | IANA timezone, default America/New_York. | |
| business_name | Yes | The name the receptionist answers as, e.g. "Alvarez Plumbing". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: discloses that nothing is booked, sent or charged, that the code is valid 24 hours for up to 5 calls, the daily creation cap, and account requirements. This is consistent with destructiveHint=false while readOnlyHint=false correctly reflects that a sandbox resource is created.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and the alternative follows immediately. The middle sentences run long ('Calling the number and keying the code reaches a phone assistant answering as the business you describe...') and the trailing return-key list is dense, but nearly every clause carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description enumerates the returned fields (sandbox, test_number, test_code, hear_url, expires_at, calls_allowed, how) and explains how the number and browser URL are used. Prerequisites, limits, and side-effect profile are all covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, yet the description adds semantic role that the schema does not: 'trade sets what the assistant knows to ask' and that area, hours, services and timezone 'shape what it says'. It also notes which fields are required, though per-parameter detail remains mostly in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a test call' to hear an After Hours answering line, and immediately clarifies 'it is not a real line'. It explicitly names the sibling set_up_answering_line as the tool for a production line, so an agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the use case (preview the assistant before anything is set up) and the exclusion (for a line on the business's own number use set_up_answering_line). It also states prerequisites (signed-in account, any permissions) and the quota boundary (3 test lines a day, rate limited).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
buy_packget_answering_lineget_answering_line_offerget_line_callsget_line_messagesget_receptionist_benchmarkget_sip_addressset_up_answering_linetry_answering_lineAI phone calls from your verified number, with answers, transcripts and recordings.
A phone number for your business or your AI agent. Kai answers it and calls businesses for you.
AI phone receptionist for small businesses: read calls, leads and booked appointments.
Give any AI agent a phone number. BotPhone answers your business line and reports every call back.
Add one secure layer between your agents and this server.
