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

Annotations already establish that this is a mutation (readOnlyHint=false), non-destructive (destructiveHint=false), and safe to repeat (idempotentHint=true). The description adds nothing beyond that—it doesn't disclose what happens when the restaurant is already in the list, whether the restaurant must exist, or what the response looks like. The description does not contradict the annotations, but it contributes no behavioral context beyond them.

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 clean sentence with zero filler; the action verb is front-loaded and every word is load-bearing. It is appropriately sized for a tool with a single parameter and simple semantics.

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 tool with annotations declaring safety, the description is minimally sufficient to make the call. However, with no output schema and no error/edge-case behavior described, an agent cannot predict outcomes for invalid IDs or duplicate favorites—a notable gap for an operation with no other structured signals.

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 0%, so the description carries the full burden for restaurant_id. It loosely maps the parameter to 'a restaurant' but doesn't explain where the ID comes from (e.g., search results), how to obtain it, or any validation expectations. The self-descriptive parameter name partially mitigates the gap, but the description barely compensates for the undocumented 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?

The description pairs a specific verb ('Add') with a concrete resource ('a restaurant' → 'the user's Saved Restaurants list'), making the operation unambiguous. The sibling set naturally includes remove_favorite and list_favorites, and the add/remove semantic contrast is implicit—but the description never names or references an alternative, so it stops short of explicit sibling differentiation.

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?

No guidance is given on when to call this tool versus opentable_remove_favorite or opentable_list_favorites. There are no conditions, exclusions, prerequisites, or alternatives mentioned anywhere in 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?

Without relying on sparse annotations, the description discloses token expiration, auto-fetching of the user profile, the two-step confirmation fallback, and the returned security_token that must be saved for cancellation. It also states refusal conditions for CC-required slots, exceeding what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense and purpose-built; almost every sentence introduces an operational rule or warning that affects whether the call succeeds. Key facts are front-loaded before edge cases and confirmation instructions.

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 prerequisites, sequencing, authentication/profile handling, refund/cancellation consequences, optional parameters, regional sharding, and the return value. With no output schema and a 12-parameter surface, this description gives an agent everything needed to call the tool safely.

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?

Adds critical meaning beyond the schema: slot_hash and reservation_token must be fresh, dining_area_id is optional and auto-resolved, booking_token is required for CC-required slots, and database_region is needed for non-NA restaurants. This materially improves correct invocation of all 12 parameters.

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 action ('Book an OpenTable reservation') with prerequisites, and the sibling context (find_slots, book_preview, get_restaurant) makes the boundaries clear. It immediately distinguishes booking from previewing and slot-finding.

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?

Provides explicit when-to-use and sequencing rules: call find_slots immediately before booking, use opentable_book_preview for CC-required slots, and avoid booking Listing-type restaurants when opentable_get_restaurant.bookable is false. It also explains confirmation-mode behavior, leaving no ambiguity about the required call order.

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 only say readOnly=false, idempotent=false, destructive=false, so the description carries the full burden and delivers: it discloses the slot-lock side effect, the ~60-90s hold, the token's effect of skipping re-lock in opentable_book, and refusal behavior for deposit/prepaid slots. Nothing is hidden or contradictory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place: purpose, required-use, side-effect timing, unsupported categories, special routing, and refusal behavior. It is front-loaded with the core purpose and then delivers decision-relevant details in a logical order with zero 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 10-parameter tool with no output schema, the description covers the essential preconditions, side effects, special cases, and alternatives. It explains the booking flow, token lifetime, Listing-type limitation, Experience-mandatory handling, and deposit/prepaid refusal, leaving an agent with enough context 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 80%, so the baseline is 3. The description adds value beyond the schema by explaining how experience_id routes through the Experience slot-lock, how reservation_token relates to the returned booking_token, and why dining_area_id can be auto-resolved. It does not need to repeat every schema field, and the coverage is already high.

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 states a specific verb ('Preview') and resource ('OpenTable booking') with a clear outcome: surfaces cancellation policy, saved payment card, and a short-lived booking_token consumed by opentable_book. It distinguishes itself from opentable_book by framing itself as the pre-commit step that produces the token required for CC-required slots.

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 explicitly says when the tool is REQUIRED (CC-required slots), when it is safe but optional (standard slots), when it cannot work (Listing-type restaurants, directing callers to check opentable_get_restaurant.bookable), and how to handle Experience-mandatory slots via experience_id. It also names the alternative path of booking on opentable.com for refused cases.

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?

Beyond the annotations, the description discloses the two-step confirmation fallback, the confirmToken lifecycle, the preview details, and the refusal case for mismatched confirmation numbers. This adds substantial operational context beyond the destructiveHint/idempotentHint already present, 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?

The description is structured with purpose first, then required inputs, then confirmation flow, then refusal. It is fairly dense, but each sentence carries necessary operational detail; only the reference to MCP_CONFIRM_MODE adds minor overhead.

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 cancellation tool with no output schema, the description covers the full confirmation mechanism, parameter provenance, and a failure condition. It does not describe the success response format, but that is partly mitigated by the confirmation flow details and annotations. Sufficiently complete for correct invocation.

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 only 40% schema description coverage, the description compensates by clarifying that restaurant_id, confirmation_number, and security_token are outputs of other tools, and by explaining confirmToken's role. database_region is not covered in the description, but the schema already provides a thorough explanation for it, so the overall parameter guidance is solid.

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 states a specific verb and resource: 'Cancel an OpenTable reservation.' It also names the required inputs and their origin, which distinguishes it from sibling operations like opentable_book or opentable_modify. The purpose is unambiguous and not a restatement of the tool name.

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 gives clear context: the three required values come from opentable_list_reservations or opentable_book, and it explains the confirmation flow and refusal condition. However, it does not explicitly contrast cancellation with modification (opentable_modify) or state when not to use this tool, so it stops short of full alternative 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 provide readOnlyHint=true reporters, and the description adds substantial behavior: tokens expire quickly, slot_hash can bypass a get_restaurant call, the dining-area id is resolved at book time, and the exact 'operation ... not yet observed on this tab' error workaround. This is rich behavioral disclosure well beyond 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?

Every sentence in the description carries distinct operational information: core purpose, token expiration, slot attributes/types, booking shortcut, and error recovery. It is front-loaded with the main purpose, and the length is justified by the complexity of the integration.

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?

Given there is no output schema, the description does a good job explaining the key return value (reservation_token), slot_attributes, type, and slot_hash as an input to opentable_book. It also covers a known failure mode glitch. Minor gaps remain: it doesn't describe the full output shape or explicitly mention the required 'time' parameter in the prose, so it is very good but not fully complete.

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 input schema already documents date, time, view, and database_region in detail. The description reinforces 'date + party size' and restaurant specificity, but it doesn't add significant meaning for restaurant_id, party_size, or time beyond what the schema already says. With 67% schema coverage, this is adequate but not exemplary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and resource: 'List available reservation slots at a specific OpenTable restaurant for a date + party size.' It clearly differentiates from siblings like opentable_list_reservations by focusing on availability rather than existing reservations, and it names the downstream integration with opentable_book.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage context: returned reservation_token and slot_hash should be passed directly to opentable_book, and opentable_get_restaurant is unnecessary for that flow. It also provides a concrete retry condition. It doesn't explicitly contrast with opentable_list_reservations or state when not to use this tool, 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.

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

Annotations already declare readOnlyHint=true, and the description adds valuable context by explicitly stating that payment and credit-card details are never exposed. This goes beyond the annotation and gives agents a clear guarantee about the response content, though it does not cover authentication or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the resource and fields, and ends with a crucial exclusion. Every sentence earns its place; there is zero fluff or repetition.

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?

Given the tool's simplicity (one optional parameter, no output schema), the description lists all major return fields and the key exclusion. It does not specify exact structures (e.g., phone object layout), but for a read-only profile tool this is adequate; the schema covers the view parameter fully.

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 input schema's description for the 'view' parameter is thorough, covering response shape, defaults, and rationale for not offering field projection. Since schema coverage is 100%, the tool description does not need to add parameter detail; it provides no extra semantics, matching 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?

The description states a clear verb and resource: 'get the authenticated OpenTable user's profile', and enumerates the specific fields returned. It is unambiguous and distinguishes itself from sibling tools, which all concern reservations, bookings, restaurants, or favorites.

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 makes the tool's purpose obvious—profile retrieval—so an agent can infer when to use it. It does not explicitly name alternatives or exclusion conditions, but given the unique scope and clear resource, the context is sufficient; no misleading guidance exists.

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?

The description goes well beyond the readOnlyHint annotation by explaining the compact/full view behavior, the fact that compact strips image/avatar URLs, and the reasoning that no field projection is invented to avoid dropping caller-needed fields. It also discloses resolution details for numeric IDs, slugs, paths, and full URLs, including legacy venue handling. This is rich behavioral context that annotations alone would not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and returned fields, and the second sentence efficiently explains identifier flexibility and legacy URL resolution. Every clause earns its place; there is no repetition, filler, or optional background.

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 single-resource retrieval tool with no output schema, the description is complete: it enumerates all returned categories, explains both view modes, details accepted identifier forms, and notes availability_token's role in booking. An agent has enough information to select the tool and call it correctly without needing to inspect the schema.

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 tool description largely restates what the input schema already documents for restaurant_id and view. The description does not add meaning beyond the schema's parameter descriptions: both explain accepted ID forms and the compact/full distinction. Since the schema carries the full burden, a baseline of 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?

The description states a specific verb ('Get full details') and resource ('a single OpenTable restaurant'), then enumerates the exact fields returned: cuisine, price band, description, address, hours, phone, payment options, features, rating/review count, and availability_token. This clearly distinguishes it from sibling tools like opentable_search_restaurants, which lists/search results, and opentable_list_reservations, which handles user reservations.

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 gives clear context on when to use the tool: to retrieve full details for a single known restaurant, often as a follow-on to opentable_search_restaurants. It even instructs that passing the search result's 'url' verbatim always resolves, including legacy /{slug} venues. It does not explicitly state when not to use it or name alternatives for other cases, but the usage context is sufficiently clear.

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 readOnly, idempotent, and openWorld, and the description confirms read-only/no-auth. Beyond that it discloses what the round-trip actually probes and enumerates the failure classes the hint distinguishes (bridge never came up vs extension not connected vs capability unavailable vs site-side problem), which is real behavioral value the annotations don't carry.

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 mechanism, then the returned fields, then the call condition. The middle sentence is dense with enumerations, but every item is a distinct diagnostic the agent needs, so little is wasted. Slightly heavy for a single read-only probe.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the return contract, and it does — it names each diagnostic field and the categories of hint returned. Combined with annotations covering safety, an agent has everything needed to call this correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the schema imposes no burden and the baseline is 4. The description correctly adds no parameter commentary because there is nothing to parameterize — the URL and target are fixed internally.

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 action (round-trips /robots.txt through the ContextMint Bridge) and the exact output (bridge role, port, version, link state, elapsed time, hint). This is unmistakably a connectivity diagnostic, cleanly separable from the booking/reservation siblings that share the opentable_ prefix.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger: 'Call this when a real tool fails and you want to know which hop broke.' That is clear when-to-use guidance. It doesn't spell out when NOT to use it (e.g., for routine preflight checks), but no sibling competes for this role.

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?

With readOnlyHint=true, the annotation already covers the non-mutating behavior. The description adds a useful account of what the response contains (id, name, cuisine, neighborhood, price band, rating, URL), but it does not disclose potential traits such as authentication requirements, empty-list behavior, or pagination.

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 states the action and resource immediately, and the appended field list is informative without bloat. Every part 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 simple read-only list with one optional parameter and no output schema, the description covers the operation, the return payload, and the relevant domain. The schema fully documents the only parameter, so nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the view parameter's enum and description are already explicit about compact/full behavior and defaults. The tool description itself adds no parameter-level detail, so the baseline of 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?

Description states a specific verb ('List'), resource ('user's saved restaurants from OpenTable'), and explicitly names it as the Saved Restaurants list. It also enumerates the returned fields, distinguishing it from siblings like opentable_list_reservations and opentable_search_restaurants.

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 phrase 'user's saved restaurants from OpenTable (Saved Restaurants list)' provides clear context that this tool is for reading the current user's favorites rather than reservations or search results. It does not explicitly name alternative tools or exclusions, 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.

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

The readOnlyHint annotation already declares safety, so the bar is lower; the description adds meaningful behavior beyond that: it operates on the authenticated user's reservations, defaults to upcoming, and each entry includes the security_token needed for downstream cancel/modify operations. It does not cover pagination or error behavior, but it goes well beyond what annotations alone provide.

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, purposeful sentences. The first states the core action, the second gives the key invocation option, and the third explains the security_token relevance. No filler or repetition.

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 list operation with two optional enum parameters and a readOnly annotation, the description plus schema covers what an agent needs to invoke it correctly. The absence of an output schema is partially addressed by noting that entries include security_token and by the view parameter's response-shape explanation, though pagination, ordering, and full return-structure details are not described.

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 the view parameter is documented in the schema (50% coverage), but the description compensates by explaining scope: its default and the 'past'/'all' broadening options. The view parameter carries a thorough schema description, so together the two parameters are effectively well explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List the authenticated user's OpenTable reservations.' This clearly distinguishes the tool from siblings like opentable_search_restaurants, opentable_list_favorites, and opentable_book by focusing on the user's own reservation records.

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 gives clear context for when to call it: to see the authenticated user's reservations, with an explicit default of upcoming and instructions to pass scope="past" or scope="all" to broaden. It does not explicitly name when-not-to-use alternatives, but the purpose is specific enough that no sibling tool is a realistic substitute.

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 flag mutation (destructiveHint=true, readOnlyHint=false), so the description's job is to add context beyond that, which it does: it discloses that confirmation_number is preserved while reservation_id/security_token may be regenerated, that dining_area_id mismatch is refused, and that without client elicitation a first call returns preview+confirmToken and only a repeat call commits. These are non-obvious behaviors the agent cannot infer from annotations, and nothing contradicts the annotated hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense (~5 sentences) and front-loaded with purpose and prerequisites, with every sentence carrying operational facts not in the schema. There is mild redundancy — the identity trio appears twice and dining_area_id's optionality appears in both schema and description — but 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?

Given 12 parameters, 8 required, and no output schema, the description covers the full call protocol: mandatory preview, user-confirmation flow with confirmToken fallback, the return shape (opentable_book shape plus was_modified), and the Listing-type exclusion. The only indirection is pointing to opentable_book's shape rather than spelling it out, which is acceptable given sibling context.

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 schema coverage at 67%, the description compensates by grouping restaurant_id + confirmation_number + security_token as the 'existing reservation's identity', explaining why modify_token is mandatory with no no-token path, and clarifying that dining_area_id is optional because the token already carries the resolved area, with mismatch refused. party_size, restaurant_id, and security_token still lack explicit schema descriptions, but the identity-grouping covers the latter two.

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?

Opens with a specific verb+resource — 'Modify an existing OpenTable reservation in place' — and immediately anchors the flow by naming opentable_modify_preview as a mandatory prerequisite, separating this submission step from the preview sibling. The isModify:true/confirmation_number details further distinguish it from opentable_book and opentable_cancel in the sibling 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?

States when to use (modifying an existing reservation) and explicitly when not: 'For Listing-type restaurants there's no slot to lock — agents should check opentable_get_restaurant.bookable first.' It mandates the precondition (fresh modify_token from opentable_modify_preview) and the human-confirmation requirement before the call, leaving little ambiguity about the correct call sequence.

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 are all false, so the description carries the full burden. It does disclose return values (cancellation_policy, CC re-hold details, modify_token) and an optional auto-resolution behavior for dining_area_id, plus the Listing-type restriction. However, it does not clarify side effects (e.g., whether it holds the new slot or affects the existing reservation), idempotency, or authentication needs. This leaves meaningful behavioral ambiguity for a non-read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the core purpose, then adds necessary operational details (input sources, optional param behavior, preconditions). It is not padded, but the length is justified given the 12-parameter surface and the need to differentiate from a sibling. Every sentence adds value.

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 tool with 12 params, 8 required, no output schema, and no annotations, the description covers the full workflow: where to get inputs, how optional params behave, the database_region caveat, and a critical precondition. It also states the return items. It lacks explicit error-handling or side-effect detail, but given the complexity and the sibling references (find_slots, book_preview, modify), it is substantially complete.

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%, and the description adds significant context beyond the schema: it groups parameters by source (existing reservation identity vs. new slot args), explains dining_area_id auto-resolution, and clarifies database_region's role and default. It compensates for the undocumented parameters (restaurant_id, confirmation_number, security_token, party_size) by describing their provenance. Some parameter-specific details are still left to inference, but the added semantics are strong.

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 the specific action ('Preview a MODIFICATION'), the resource (existing OpenTable reservation), and explicitly differentiates from opentable_book_preview by pointing out the isModify=true URL difference. Also clearly declares its role as a mandatory prerequisite for opentable_modify, so an agent can immediately understand its purpose.

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 states when it is required ('REQUIRED before opentable_modify — no shortcut path'), how to obtain its inputs (reservation identity from list_reservations/book result, new slot args from find_slots), and a key exclusion ('For Listing-type restaurants the modify can't proceed; check bookable first'). This gives clear guidance on when and how to use it versus alternatives.

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 indicate idempotentHint=true and destructiveHint=true, so the description doesn't contradict them. The description adds value by clarifying that the action targets the user's saved list and affects only that restaurant. It doesn't need to repeat the annotations, but it could have mentioned side effects (e.g., irreversible removal), which is a minor gap given the mutation nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and to the point. It avoids unnecessary detail while covering the core purpose, making it easy for an agent to process quickly.

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 single-parameter tool with annotations and no output schema, the description is nearly complete. It clearly states what the tool does, and the only missing piece is explicit guidance on how to determine the restaurant_id, which could be inferred from the sibling tools. Overall, it provides sufficient context for an agent to understand and invoke 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 0%, so the description must compensate for the parameter. The description doesn't explicitly explain restaurant_id, but the tool name and description imply that restaurant_id identifies the restaurant to remove. However, it doesn't provide details like how to obtain the ID (e.g., from list_favorites), which would be more helpful. With only one parameter, the context is fairly clear, but the description could be more explicit.

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 clearly states the action (remove) and the target (a restaurant from the Saved Restaurants list). It distinguishes this from sibling tools like opentable_add_favorite and opentable_list_favorites, though it doesn't explicitly name 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 description implies usage context by mentioning the Saved Restaurants list, which hints that this tool is appropriate when a restaurant is already a favorite and needs to be removed. However, it doesn't explicitly state when to use or avoid this tool relative to siblings, nor does it mention any prerequisites (e.g., the restaurant must already be saved).

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, so the read-only nature is covered. The description adds valuable behavioral context by stating exactly what fields are returned and, crucially, that slot tokens are not included—information an agent needs to avoid assuming availability is present. This goes beyond the annotation without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero filler. The first sentence delivers the core purpose and output, and the second sentence provides a critical exclusion plus a pointer to the sibling. It is front-loaded, efficient, and every word 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 search tool with no required parameters and no output schema, the description covers the essential behavioral contract: what it returns, what it omits, and when to use a different tool. It does not explain parameter interactions (like date affecting ranking), but those are already in the schema. Minor gaps like pagination or result limits are not critical for correct invocation.

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 78%, so most parameters already have their own explanations in the schema. The tool description adds no new parameter-level meaning; it only restates the return fields. Per the rubric, high schema coverage sets a baseline of 3, and the description does not exceed that 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 description opens with a clear verb and resource: 'Search OpenTable for restaurants' and lists specific returned fields (cuisine, neighborhood, price band, rating, description, URL). It explicitly differentiates itself from opentable_find_slots by stating it does NOT include bookable slot tokens, making its scope unambiguous among 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?

It gives an explicit when-not and names the alternative: 'Does NOT include bookable slot tokens — use opentable_find_slots for a specific venue to check availability.' This directly routes the agent away from the most likely confusion and toward the correct sibling, which is exactly what good usage guidance looks like.

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