Book with ES Luxury Auto Detailing: services, prices and open times. No key needed.
Scored across 5 tools
Each tool maps to a distinct action/resource: discover the business (get_business), search availability (find_times), create (book), inspect status (get_booking), and cancel (cancel_booking). The only near-pair, get_booking vs get_business, is clearly separated by entity (a booking vs the business card).
Four tools follow a clean snake_case verb_noun pattern (cancel_booking, find_times, get_booking, get_business). The creation tool breaks the pattern by being the bare verb 'book' rather than something like create_booking, a minor but noticeable deviation.
Five tools is well-scoped for a booking flow: one info tool, one availability search, one create, one status check, one cancel. Nothing looks redundant or missing at the count level.
The core lifecycle (discover, find times, book, check, cancel) is covered, and approved-booking changes are routed back to the business by design. However, there is no reschedule/update-in-place tool and no way to list a customer's bookings, so some follow-up flows rely on external handling.
Book one of the open times for the customer. The business then either confirms it at once or receives it as a request it approves; the answer says which, what happens next, and a manage.token to check or cancel the booking later. The customer is emailed. Confirm the service, the time and the customer's details with the customer before calling it. idempotency_key is required: choose a new random one for each booking (a UUID without hyphens) and send the same one to retry after a timeout, so a retry cannot make a second booking.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Who is booking, so the business sees that an agent made the booking and which one. | |
| items | No | What is being booked. May be left out only when the business offers exactly one service (a consulting business's one kind of call). | |
| start | Yes | A start time from `times`, ISO 8601 with an offset, on a whole minute: seconds, when written, are 00 ("2026-10-12T10:00:00-07:00" or "2026-10-12T17:00Z"). It is checked again, and refused with `time_not_open` if it is no longer open. | |
| answers | No | Answers to the questions the card lists under booking.answers, by their `id`. Each question there says its exact format and shows an example that passes: a select takes exactly one of its option strings, copied character for character; a multiselect takes a list of its option strings (at most its `maxSelections`, each once); a text, a long text, an email, a phone number and a web address each have a stated length limit; a select with `allowOther` takes "Other" with the customer's own words under `<id>_other`; and a question with a `none` phrase takes exactly that phrase when there is no answer. A mobile detailer asks for `address`. Leave out when the card lists none. | |
| customer | Yes | The person the booking is for. They receive the confirmation email. | |
| idempotency_key | Yes | Required. A key you choose, new for each booking: 32 to 255 letters, digits, dashes or underscores, and RANDOM, never a counter, a word or a pattern (a UUID without hyphens is right; a key with fewer than 8 distinct characters is refused). Calling book again with the same key and customer email answers the first booking again, with the same manage token, instead of making a second one: use it to retry safely after a timeout. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare idempotentHint=true and openWorldHint=true, but the description adds substantial context beyond them: the dual confirmation/request outcome, the fact that the customer is emailed, that the response carries a `manage.token`, and the retry contract (same key returns the first booking with the same token rather than creating a second). That is genuinely useful operational detail, and nothing contradicts the 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?
Four sentences, all load-bearing: outcome first, then the response contract, then the confirm-before-calling rule, then the idempotency mechanics. Nothing is padding, and the most decision-relevant facts are front-loaded.
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?
There is no output schema, and the description fills that gap by describing what the answer reports (confirmation vs. request, next steps, manage token). For a six-parameter, nested-object tool with full annotation coverage, 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 description coverage is 100%, including a very detailed `idempotency_key` description, so the schema already carries the parameter burden and 3 is the baseline. The description's key advice ("choose a new random one for each booking (a UUID without hyphens) and send the same one to retry after a timeout") largely restates the schema rather than adding new syntax or constraints.
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 opening sentence names a specific verb ("Book") and resource ("one of the open times for the customer") and immediately states the outcome: it is either confirmed at once or arrives as a request for approval. This is plainly distinguishable from the read-only siblings (find_times, get_booking, get_business) and from cancel_booking.
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 a clear precondition ("Confirm the service, the time and the customer's details with the customer before calling it") and points at the `manage.token` for later checking or cancelling, implicitly routing to get_booking/cancel_booking. It does not explicitly say the start time must come from find_times or when not to call it, so the guidance is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a booking made through this door: withdraws a request still waiting, or cancels a booking the business confirmed at once. A booking the business has approved must be changed with the business directly (the answer says how). Ask the customer first.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The booking's `manage.token`, from book. | |
| reference | Yes | The booking's `reference`, from book. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond them by disclosing state-dependent behavior and the fact that approved bookings are out of scope here and the response explains the alternative path. It does not detail auth requirements or what the returned payload looks like.
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?
Three tight sentences with the core action front-loaded, followed by the exclusion and a short caution. Every sentence carries weight, though the standalone 'Ask the customer first' is slightly abrupt and the state enumeration could be marginally more compact.
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 destructive, open-world two-parameter mutation tool with no output schema, the description covers the essentials: what it cancels, the state conditions, the exclusion, and that the response tells the caller how to proceed for approved bookings. It is close to complete, missing only richer detail on the response payload or auth expectations.
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 description coverage is 100%, so the schema already documents both `token` and `reference` as coming from book. The description adds no syntax or format detail beyond that, so the baseline 3 applies; the 'made through this door' phrasing is contextual rather than parameter-specific.
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 (cancel) and resource (booking) and goes further by splitting the action into two distinct states: withdrawing a still-waiting request versus cancelling a business-confirmed booking. An agent immediately understands what is being cancelled and under which conditions, with no overlap among the read-oriented siblings (book, find_times, get_booking, get_business).
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 when-to-use conditions (pending request, or a booking the business confirmed at once) and an explicit when-not-to-use exclusion: a business-approved booking must be changed with the business directly. It also adds a procedural prerequisite, 'Ask the customer first', leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the start times that are open for what is being booked, between two dates (at most 14 days). Pass windows (the customer's free time from their calendar) to get only the starts that fit both calendars. Returns ISO 8601 times with offsets. Only open times are ever shown.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Last day, YYYY-MM-DD. At most 14 days from `from`, counting both, and at most 60 days from today. | |
| from | Yes | First day, YYYY-MM-DD, in the business's time zone (the card names it). Not in the past. | |
| items | No | What is being booked. May be left out only when the business offers exactly one service (a consulting business's one kind of call). | |
| windows | No | The customer's free time, as intervals with offsets. When given, only starts whose whole job or meeting fits inside one window come back. Leave out to see every open start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: only open times are returned, results are ISO 8601 with offsets, the range cap, and the both-calendars intersection rule when windows are supplied.
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?
Three sentences, tightly front-loaded with the scoping constraint (14 days) and the optional-parameter effect, and it closes with the return-format note. 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 bounded search tool with no output schema, the description covers what it returns (ISO 8601 times with offsets), which times appear (only open, optionally intersected), and the range limits. Nothing needed for a correct call 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 description coverage is 100%, so the schema already documents from, to, items and windows in detail. The description restates the windows semantics (customer free time, fits both calendars) but adds no syntax or format meaning beyond the schema, matching the baseline 3.
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 ("Find the start times that are open") plus the relevant scope constraints (between two dates, at most 14 days). It never names a sibling, but the read-only availability lookup is naturally distinct from book/cancel_booking in the tool set.
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 a clear conditional for the optional parameter: pass `windows` to intersect with the customer's calendar, omit it to see every open start. No explicit when-not guidance or reference to the booking flow's alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a booking made through this door: whether it is requested, confirmed, declined or cancelled, and whether it can still be cancelled here.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The booking's `manage.token`, from book. | |
| reference | Yes | The booking's `reference`, from book. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing the status values returned and that it evaluates remaining cancellability, which is genuinely useful behavioral context.
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?
A single front-loaded sentence with no filler. The phrase 'made through this door' is slightly idiosyncratic and could read as jargon, which keeps it from a 5.
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?
There is no output schema, so the description carries the return-value burden and does so by naming the possible booking states and the cancellability result. For a two-parameter read tool with full annotation coverage, 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 both parameters are described in the schema as coming from book (`manage.token` and `reference`). The description adds no format, syntax, or lookup detail, so the baseline of 3 for full schema coverage 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 (check) and resource (a booking), and enumerates the states it reports (requested, confirmed, declined, cancelled) plus whether cancellation is still possible here. This sets it apart from the write-oriented cancel_booking, though no sibling is named explicitly.
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?
Usage is implied rather than stated: the phrase 'whether it can still be cancelled here' hints this is the read step preceding cancel_booking, but there is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the business card: what it is, where the work happens, its hours and time zone, its services with prices and lengths, what a booking needs (the customer's details and the questions to answer), whether a booking is confirmed at once or sent as a request, the limits and the cancel rule. Call it first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the ordering requirement ('call it first') but discloses nothing about authorization, rate limits, or data freshness, which is what would push this above baseline.
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?
A single sentence, with the purpose front-loaded and the actionable directive ('Call it first') at the end. The mid-sentence enumeration is dense but each item maps to real returned data, so nothing is 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?
There is no output schema, so the description carries the burden of telling the agent what comes back, and it does: identity, location, hours, time zone, services/prices/durations, required booking inputs, confirmation semantics, limits, and cancellation policy. That inventory is exactly what an agent needs before calling book or find_times.
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 and the schema has additionalProperties=false, so there is nothing to disambiguate and no parameter syntax the agent could get wrong. Baseline 4 for a parameterless tool.
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 concrete verb ('Read') and resource ('the business card') and then enumerates the exact scope: identity, location, hours, time zone, services with prices and lengths, booking requirements, confirmation mode, limits and cancel rule. An agent can tell this apart from siblings like book or find_times purely from the description.
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?
'Call it first' gives explicit sequencing guidance and marks this as the entry point relative to book/get_booking. It does not name an alternative or state when *not* to call it, so it stops short of a full when/when-not/alternatives treatment.
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.
bookcancel_bookingfind_timesget_bookingget_businessBook with Enhanced Intelligence LLC: services, prices and open times. No key needed.
Book parking, car washes, EV charging, gas and auto repair across the US with live pricing.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
No key needed. Search real products and live dealer inventory, price-check, keep standing wants.
Add one secure layer between your agents and this server.
