Book with Enhanced Intelligence LLC: services, prices and open times. No key needed.
Scored across 5 tools
Each tool targets a distinct action on a distinct resource: book creates, cancel_booking cancels, find_times searches availability, get_booking reads a booking, get_business reads business metadata. There is no overlap in purpose and the descriptions reinforce clear boundaries.
All names are snake_case verb-first, giving a predictable pattern (find_times, get_booking, get_business, cancel_booking). The lone deviation is 'book', which uses a bare verb without an accompanying noun, a minor inconsistency.
Five tools is well-scoped for a booking service, with exactly the operations needed to discover, search, create, inspect, and cancel. No redundant or filler tools.
The lifecycle is well covered: discover business, find times, book, check status, cancel. The notable gap is rescheduling/modifying a booking, though the surface explicitly routes that to the business, leaving a minor workaround.
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?
Beyond the annotations (which only declare a non-read-only, idempotent, open-world write), the description discloses real behavioral traits: the booking may be auto-confirmed or held as an approval request, the answer states which and what happens next, the customer is emailed, and a `manage.token` is issued. It also explains the timeout-retry idempotency semantics and the `time_not_open` refusal, which 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 action, then the outcome, the pre-call check, and the idempotency rule in a logical order. It is a fairly dense multi-sentence block, but each sentence carries distinct operational content 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 6-parameter, nested-object mutation tool with no output schema, the description covers what an agent needs: the returned signal (confirmation vs. approval request), the manage token, the customer email side effect, the pre-call confirmation step, and the idempotency contract. Nothing essential to calling 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 description coverage is 100%, so the schema already documents all six parameters including the idempotency_key format and randomness rule. The description restates the same constraint (fresh random UUID-style key per booking, reused on retry) rather than adding new meaning, so it lands at the baseline.
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 gives a precise verb and resource ("Book one of the open times for the customer") and the following sentences describe the outcome the caller should expect. It does not name any sibling (find_times, get_booking, cancel_booking) even though `manage.token` alludes to the follow-up tools, so sibling differentiation is implicit rather than explicit.
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 pre-call condition ("Confirm the service, the time and the customer's details with the customer before calling it") and tells the agent exactly how to use idempotency_key when retrying after a timeout. What is missing is the alternative-tool routing: nothing says to obtain `start` from find_times first or to use get_booking/cancel_booking with the returned token.
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 real behavioral context beyond that: the 14-day span limit, the fact that results are ISO 8601 with offsets, and the guarantee that only open (never busy) times are returned. With no output schema, the return-format note is valuable, though it stays brief.
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 core purpose, then covers the `windows` option and return format in short sentences. Slightly redundant — 'Only open times are ever shown' overlaps with the opening sentence and with the schema's own wording — but nothing is bloated.
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 4-parameter availability-lookup tool with a 100%-covered schema, the description supplies the key framing (open starts, optional calendar intersection) and a brief return-format note. Since no output schema exists, the terse return description leaves a little unexplored, but it is sufficient to call the tool 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%, so the schema already documents `from`, `to`, `items`, and `windows` in detail. The description's mention of `windows` largely restates the schema's own explanation, adding little new syntax or constraint detail. Baseline 3 when the schema does the heavy lifting.
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') scoped to 'what is being booked' between two dates. This is clearly distinguishable from the sibling book/get_booking tools, which act on existing bookings rather than surfacing availability.
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?
Explains the central usage decision: pass `windows` to intersect with the customer's calendar, or omit it to see every open start. It does not explicitly name siblings (e.g., 'use this before book'), but the when-to-supply-windows guidance is clear and actionable.
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 ES Luxury Auto Detailing: services, prices and open times. No key needed.
Free scheduling your agent can book through: live availability, booking, verification, cancel.
Book appointments with service providers on booboooking.com — no token required.
Verified local businesses, bookable by AI agents: services, prices, availability and appointments.
Add one secure layer between your agents and this server.
