Answer small-business customer questions from FAQs, list open appointment times, and book them.
Scored across 4 tools
Each tool has a clearly distinct purpose: read-only answering, listing availability, booking, and cancelling. The descriptions explicitly encode the workflow order (answer first, then list_open_times, then book/cancel), leaving no room for misselection.
All four names follow a consistent snake_case verb_noun pattern (answer_customer_question, book_appointment, cancel_appointment, list_open_times). No stylistic deviations, camelCase mixing, or vague verbs.
Four tools tightly cover the core booking conversation loop and each earns its place. The surface is on the lean side, but nothing is redundant or missing for the stated scope.
The booking lifecycle is covered end-to-end: answer, list availability, book, cancel, with rescheduling handled via cancel-then-book. Minor gaps exist: no explicit reschedule or order-lookup tool despite order records being referenced, and no way to list a business's existing bookings to recover a booking id.
Answer a customer's message for one small business using only that business's own FAQs and order records. Rule-based, not generated, so it never invents prices or opening hours; English and Chinese are detected automatically. Read-only: it never books or changes anything. Use it first for any customer message. If it returns intent 'appointment', call list_open_times next; if matched is false or intent is 'human_handoff', tell the customer a person will follow up. Authenticates with the connection's API key (Authorization: Bearer ccs_live_…); without a key it answers as a public demo business. Returns JSON { intent, lang, matched, reply, next? }.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The customer's message exactly as they wrote it (1-2,000 characters, English or Chinese). Don't rephrase or translate it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that answers are deterministic rule output (never invents prices or opening hours), that language detection is automatic, that authentication uses the connection API key, and that a missing key degrades to a public demo business. Those are non-obvious operational traits the annotations 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?
Front-loaded with the core purpose in the first sentence, then progressively adds constraints, auth, and return shape. Each sentence carries new information, though the single dense block packs many clauses and could be split for easier scanning.
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 returned JSON keys { intent, lang, matched, reply, next? }, which is exactly what the agent needs to interpret results. Together with auth, fallback, and routing behavior, nothing essential 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?
With a single parameter at 100% schema description coverage, the schema already documents the message field, its 1–2,000 char limit, and the 'don't rephrase or translate' rule. The description adds only the language-detection note (English/Chinese) plus the return shape, so the baseline 3 is appropriate.
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+resource ('Answer a customer's message') scoped to 'one small business using only that business's own FAQs and order records', which distinguishes it from the sibling booking/cancellation tools. The 'rule-based, not generated' clause further pinpoints what kind of answer is produced.
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 for any customer message' and gives concrete branching rules: intent 'appointment' → call list_open_times next; matched is false or intent 'human_handoff' → tell the customer a person will follow up. This routes the agent to alternatives and defines the fallback path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book one appointment for a customer. This creates a real booking: the business is notified, and if it has connected Cal.com the booking is created there too. With the demo key it's a dry run that books nothing. Not idempotent: booking the same time twice fails the second time. Only call it after the customer has confirmed the time and service; needs a 'start' from list_open_times and the customer's email or phone. Errors: 404 the time is no longer offered (call list_open_times again), 409 it was just taken, 400 missing start, service, or both email and phone, or the business's connected calendar needs a detail the customer didn't give (the message says which, e.g. an email). Returns JSON { booked, id, start, label }; keep 'id' if the customer may want to cancel.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The customer's name as they gave it; shown to the business. | |
| No | The customer's email. Give email or phone (at least one is required). | ||
| phone | No | The customer's phone in international format, e.g. +6591234567. Give email or phone (at least one is required). | |
| start | Yes | The exact 'start' value returned by list_open_times (ISO 8601 UTC), unchanged. | |
| remarks | No | Optional note for the business, up to 500 characters (e.g. 'first visit'). | |
| service | Yes | What the customer is booking; use one of the 'services' returned by list_open_times. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only flag non-read-only, non-idempotent, open-world): it explains the demo-key dry run, the not-idempotent duplicate-booking failure, the external notification/Cal.com side effects, and a full 404/409/400 error taxonomy with meanings. Rich behavioral context the agent could not infer.
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 core action and side effects, then prerequisites, then error semantics. Every sentence carries information, though the error catalogue and demo-key note make it longer than strictly minimal.
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?
Despite no output schema, the description names the return shape ({ booked, id, start, label }) and advises retaining 'id' for cancellation. Combined with prerequisites and error handling, nothing needed to invoke this mutation 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% and already documents each field, including the email-or-phone requirement and the provenance of 'start'. The description restates those rules rather than adding new syntax or format detail, so it sits at the baseline for a fully documented 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 ('Book one appointment for a customer') and immediately characterizes the side effects (real booking, business notified, Cal.com sync), which clearly separates it from cancel_appointment, list_open_times and answer_customer_question.
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 to call it only after the customer has confirmed the time and service, names the required prerequisite source ('start' from list_open_times), and routes recovery on 404 back to list_open_times. Alternatives and conditions are fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel one of the business's bookings by the 'id' that book_appointment returned. This changes data: the time becomes free again, and if the business has connected Cal.com the booking is cancelled there too (Cal.com emails the customer). Only call it after the customer has clearly asked to cancel that specific booking. To reschedule, cancel and then book a new time from list_open_times. With the demo key it's a dry run. Errors: 404 no such booking for this business, 409 already cancelled, 400 not a booking id. Returns JSON { cancelled, id, start }.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The booking 'id' returned by book_appointment (a UUID). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich context beyond annotations: the slot becomes free, Cal.com syncs and emails the customer, demo key is a dry run, and enumerated error codes (404/409/400). Notably reconciles the 'destructiveHint: true' with 'idempotentHint: true' by explaining re-cancel returns 409.
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 the action and id source, then layers call preconditions, side effects, errors, and return shape in tight, well-ordered sentences. 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?
Covers trigger conditions, side effects, external integration, dry-run behavior, error semantics, and return shape for a single-param mutation with no output schema. Nothing essential 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% and the 'id' description already documents it as the UUID from book_appointment, so the schema does the heavy lifting; the description merely reiterates provenance.
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 ('Cancel ... bookings') and anchors it to the 'id' from book_appointment, clearly distinguishing it from booking/list 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 explicit preconditions ('only call after the customer has clearly asked to cancel that specific booking') and routes rescheduling to cancel + list_open_times. No explicit when-not-to-call beyond that, but strong for a single-purpose tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the business's next open appointment times: up to 5, soonest first, within the next 7 days, labelled in the business's time zone, plus its services and locations. Read-only. Call it before book_appointment and whenever a customer asks when they can come in. Times come from the business's CallChatSyn hours or from its connected Cal.com calendar. Returns JSON { slots: [{ start, label }], services, locations }; pass a slot's 'start' to book_appointment unchanged. An empty slots list means nothing is open this week.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the human-readable labels: 'en' (default) or 'zh'. Times themselves are always ISO 8601 UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint/idempotent/openWorld, so the safety profile is free. The description adds real behavioral context: the data source (CallChatSyn hours or connected Cal.com calendar) and the meaning of an empty slots list. It does not discuss rate limits or staleness, which keeps it 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?
Front-loaded with scope, then usage, then data source and return contract. Every sentence carries a distinct piece of information (bounds, trigger, provenance, return shape, empty case) with no padding.
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 1-param read tool with no output schema, the description supplies the return shape ({ slots: [{start,label}], services, locations }), the contract for passing 'start' to book_appointment unchanged, and the empty-result semantics. 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?
Only one parameter and schema coverage is 100%, including the enum and its default, so the schema does the heavy lifting. The description says labels are localized but never mentions the lang parameter or its accepted values, so it adds nothing new here. Baseline 3 applies.
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 open appointment times) and immediately bounds it: up to 5, soonest first, next 7 days, in the business's time zone. This is clearly distinguishable from the sibling book/cancel/answer tools.
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 when to call it ('before book_appointment and whenever a customer asks when they can come in'), naming the sibling tool as the trigger context. Nothing about the selection decision is left to inference.
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.
answer_customer_questionbook_appointmentcancel_appointmentlist_open_timesAI phone receptionist for small businesses: read calls, leads and booked appointments.
Manage an EasyWeek business from AI: bookings, availability, customers, services, orders, messaging.
Verified local businesses, bookable by AI agents: services, prices, availability and appointments.
Scheduling, availability, clients, billing and CRM for appointment-based services.
Add one secure layer between your agents and this server.
