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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral detail by disclosing that results are grouped counts by status (finished, cancelled, noShow, upcoming) and by booking page, which tells the agent what the response will contain. It stops short of describing pagination or whether both groupings are always returned.

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?

Two tight sentences, front-loaded with what is counted and grouped before the example query. No filler and every clause adds 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?

For a read-only aggregation tool with no output schema, the description conveys the essential return shape (counts by status and booking page) and the period requirement. It could say more about the exact response structure and the role of bookingPageIds, but nothing critical to invoking 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 67%: from/to are well documented in the schema, but bookingPageIds has no schema description. The phrase 'by booking page' hints that this parameter scopes or groups by page, adding marginal meaning, but it does not explain the array semantics or filtering behavior. 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 (counts) plus the resource (bookings) and the exact grouping dimensions (status and booking page). An agent can immediately separate this aggregate-report tool from the sibling listing tools like search_bookings or list_upcoming_bookings.

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?

The example question ('how many no-shows did we have last month?') clearly signals the intended usage context for a counting/aggregation query. However, it never names an alternative tool or states when not to use it, so the routing guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false, so the write/side-effect profile is partly covered. The description adds genuine value beyond that: it discloses that the call creates a real booking plus a calendar event and sends notifications, which is the kind of irreversible-external-effect detail an agent needs before calling.

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?

One sentence, front-loaded with the action and its input source, then the side effects, then the safety caveat. No filler and no repetition of the title.

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 non-idempotent mutation tool with no output schema, the description covers the source of inputs, the side effects, and the confirmation requirement, which is close to complete. Minor gap: it does not say what the response contains or how to recover from a failed/duplicate booking, though annotations handle the idempotency signal.

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 63% and the description adds no field-level meaning beyond noting that intentId comes from find_available_times, which the schema already states. With most parameters self-documented in the schema, this sits at the baseline of 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 and resource ('Book a slot') and anchors it to the sibling that produces the input ('found by find_available_times'), which cleanly separates it from search/get/cancel/reschedule 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 a clear workflow precondition (use only with a slot returned by find_available_times) and an explicit caution to confirm details with the user first. It does not name an alternative for the related operations, but the sourcing dependency is stated plainly.

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

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

Annotations already carry destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description still adds real value beyond them: the calendar event is removed, cancellation notifications are sent according to the page's settings, and confirmation is required first — side effects an agent cannot infer from the hints alone.

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?

Two sentences, front-loaded with the action and actor, followed by the consequences and the confirmation requirement. Every clause earns its place 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 one-parameter destructive tool with no output schema, the description covers actor scope, side effects (event removal, notifications), and a confirmation safeguard. It leaves only minor gaps, such as behavior when the booking is already cancelled (implied by idempotentHint=true but not stated).

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 bookingId fully, including its provenance (search_bookings or list_upcoming_bookings). The description adds no parameter-level meaning, so 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 ('Cancel a booking') plus the acting scope ('as the calendar owner'), so the core action is unambiguous. However, it never distinguishes itself from the sibling 'delete_booking', which an agent must disambiguate before choosing between them.

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?

The instruction 'Confirm with the user first' gives one actionable usage rule and 'as the calendar owner' implies a permission precondition. But there is no explicit when-to-use-this-vs-alternatives guidance, notably against delete_booking or reschedule_booking.

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

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

Annotations declare destructive/idempotent/openWorld, but the description adds consequences the annotations cannot: no further notifications are sent and the calendar event is left intact. That is exactly the side-effect detail an agent needs before destroying a record.

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 short sentences, zero filler, with the destructive nature front-loaded and the alternative-tool guidance immediately after. Every sentence earns its place.

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 single-parameter destructive tool with full annotation coverage and no output schema, the description supplies everything missing: permanence, notification behavior, calendar-event persistence, and the safer alternative.

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% and the single bookingId parameter already documents its format (UUID) and its source tools. The description adds no parameter-level meaning, so the 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 ('Permanently delete a booking record') with the product scope (YouCanBookMe) and explicitly distinguishes the operation from cancel_booking, a real sibling in the tool list.

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 routing rule: 'Prefer cancel_booking unless the user explicitly wants the record gone.' This names the alternative tool and the condition that selects this one, leaving nothing to inference.

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

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

Discloses a genuinely non-obvious side effect beyond the annotations: despite the 'find' name, it starts a booking intent and returns an intentId. This is exactly the kind of hidden state creation an agent needs, and it aligns with (rather than repeats) readOnlyHint=false.

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?

Two sentences with zero filler; the purpose and return grouping come first, then the handoff to book_time. Every clause earns its place.

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 covers the key return value (intentId) and result grouping, and all parameters are schema-documented. Minor gaps remain: no mention of behavior when no slots are available, intent expiry, or pagination limits.

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 seven parameters, including examples for from/until and the IANA timeZone. The description adds only the downstream intentId/startsAt pairing, so 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 and resource ('Find open times on a booking page') plus the return shape ('grouped by day with readable local times'). This clearly distinguishes it from sibling reads like get_booking_page and from the downstream book_time action.

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 frames the tool as the first step of a booking flow and routes the agent to book_time with the intentId and an exact startsAt. It gives a clear use context but does not state when NOT to use it or how it relates to reschedule/cancel flows.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about the payload contents (times, status, booking page, form answers), but says nothing about permissions, error behavior for a missing/invalid ID, or the fields override's effect.

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 that names the resource first and then the returned content. Every clause carries information; there is 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 simple read-only lookup with no output schema, the description's enumeration of returned data adequately compensates for the missing output schema. Only minor gaps remain: no note on behavior when the booking is not found and no guidance on the optional fields override.

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 both bookingId and the fields override are documented in the schema itself; baseline 3 applies. The description adds no meaning beyond the schema - it doesn't explain what the 'fields' override does or why one would use it.

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 ('Get') and resource ('one booking') and enumerates what comes back: times, status, booking page, and the booker's form answers. It is clearly distinguishable from the list-oriented siblings (search_bookings, list_upcoming_bookings), though it never names them 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?

There is no explicit when-to-use/when-not statement in the description. Usage is only implied: fetching a single booking by ID versus the list/search siblings. The schema's bookingId note ('from search_bookings or list_upcoming_bookings') supplies the workflow hint, but that is structured data, not the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered without the description. The description adds only the single-page scoping ('one booking page's settings') and says nothing about auth, error behavior for unknown IDs, or response shape. Minimum-viable given annotations carry the safety signal.

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?

Two short sentences, zero filler, with the core purpose front-loaded and the parameter hint following. Nothing wastes the agent's attention.

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 simple two-parameter read tool with full schema coverage and no output schema, the description covers what the tool returns conceptually ('settings') and how to shape the request. It stops short of describing error/not-found behavior or id-source alternatives, but nothing essential for invocation 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 both parameters (fields, profileId) are already documented, making 3 the baseline. The description adds the dot-notation hint for nested settings beyond the schema's flat comma-separated example, but that hint is thin and arguably inconsistent with the schema example (id,title,subdomain,timeZone) and the absence of nested objects.

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 ('Get one booking page's settings'), and the word 'one' signals a single-record fetch, distinguishing it in spirit from list_booking_pages. However it never names or contrasts the sibling retrieval tools (get_booking, list_booking_pages) explicitly, so differentiation is inferred rather than stated.

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?

The only guidance offered is about the `fields` parameter ('use fields to ask for specific nested settings'), not about when to choose this tool over list_booking_pages or get_booking. No prerequisites, no when-not-to-use, no alternative routing is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the concrete return shape (id, title, subdomain) but says nothing about pagination, result limits, or ordering for what could be a multi-page account, which is the main behavioral gap.

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 short sentences, all earning their place: identity of the resource, the vocabulary caveat, the return contents, and the downstream use. The most useful routing hint (subdomain for find_available_times) is placed last as a natural call-to-action.

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 carries the burden of describing return values and does so explicitly, and it flags the profiles/booking-pages naming alias that would otherwise confuse an agent. It is only slightly incomplete regarding pagination behavior and the overridable 'fields' parameter.

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% and the single optional 'fields' parameter is fully documented there, so the baseline of 3 applies. The description does not mention the fields parameter at all, and its field list ('id, title and subdomain') is narrower than the schema's stated default set including description, adding no real semantic value.

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 account's booking pages') and disambiguates the API's own vocabulary by noting the API calls them profiles. It also enumerates the returned fields, so it is clearly distinguishable from the singular sibling get_booking_page.

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 supplies a concrete downstream reason to call it: 'The subdomain is what find_available_times needs,' which effectively routes the agent from this tool into the scheduling flow. It does not explicitly state when to prefer get_booking_page or search_bookings over this list call, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real context beyond them: cancelled bookings are excluded, results are ordered soonest-first, and each row carries the booker name and email. It still says nothing about pagination or result-size limits on a potentially open-ended window.

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 no filler, front-loading the operation and layering scope, ordering, and returned fields in a natural reading order.

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 usefully names the key returned fields (booker name and email), and annotations cover the read-only profile. The gap is the undocumented bookingPageIds parameter and the absence of any note on result volume for larger day windows.

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 50%: 'days' is fully documented by the schema (default 7, range 1-90) and echoed by the description's 'next N days', but bookingPageIds has no description anywhere. The description also fails to clarify whether supplying bookingPageIds narrows the list to those pages or is a scope requirement, so it does not compensate for the coverage gap. 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?

The description gives a specific verb and resource (list upcoming bookings) plus meaningful scope: not cancelled, next N days, soonest first. That functionally separates it from search_bookings and get_booking, though it never names a sibling 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 by the 'upcoming, not cancelled, next N days' framing, which tells the agent this is a time-window roll-up rather than a query tool. There is no explicit when-to-use/when-not guidance and no routing to search_bookings or booking_report for other needs.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value the annotations cannot: the side effect that the booker is notified, plus a confirmation requirement. It does not describe what happens to the vacated slot or failure behavior, keeping it below 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?

Three short sentences, each earning its place: operation, prerequisite tool, and side-effect caution. The core action is 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?

For a two-parameter mutation with no output schema and full annotation coverage, the description supplies the key missing pieces: the prerequisite lookup and the notification side effect. It stops short of covering edge cases such as timezone handling or what happens if the new slot is taken.

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% with only two parameters, both documented in the schema (bookingId source, ISO 8601 format for newStartsAt). The description adds no parameter-level detail, so the 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 ('Move a booking to a new start time'), which cleanly separates it from siblings like book_time, cancel_booking, and delete_booking. An agent can identify the operation without opening 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?

Explicitly names the prerequisite alternative ('Use find_available_times first to pick a free slot') and adds a human-in-the-loop condition ('confirm with the user first' because the booker is notified). This is when-to-use plus a named sibling, not inference.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it discloses the return shape (counts by status and page plus a compact list with booker name and email) and the effect of raw=true, which is valuable given there is no output schema.

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?

Two tight sentences, no filler. The scope (time range) and filters come first, followed by return shape and the raw toggle, so the highest-value information is 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?

For a 10-parameter read tool with no output schema, the description covers the essential call semantics and return shape. Pagination controls (direction, fromBookingId, pageSize) are left to the schema, which is acceptable since they are documented there, but the description could note continuation behavior.

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 80%, so most parameters are documented. The description goes beyond by explaining what searchText actually matches against (booker name/email, title, booking ref) and what raw=true does, which compensates for the undocumented raw flag 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 (search) plus resource (bookings) and enumerates the filter dimensions: time range, status, booking page, and text. An agent can distinguish it from get_booking or list_upcoming_bookings by the presence of multi-filter search, 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?

The description implies usage through 'optionally by status, booking page, or text' and the required time range, but it never states when to prefer this over list_upcoming_bookings or get_booking, nor any exclusions or prerequisites. Usage is inferable rather than prescribed.

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