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

No annotations are provided, so the description must disclose behavior. It only says 'Add' which implies mutation, but does not mention side effects, idempotency, authentication requirements, potential errors, or what happens if the restaurant is already saved. For a mutation tool with zero annotation coverage, this is a significant 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?

The description is a single, efficient sentence with zero waste. It front-loads the action and target, making it immediately scannable. 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 mutation tool with no annotations and no output schema, the description is incomplete. It omits how to source the restaurant_id, whether the operation is idempotent, what the response looks like, and any error conditions. An agent would need to guess at critical details, making it insufficient for safe and 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 0%, so the description must compensate. It mentions 'a restaurant' but does not explain the restaurant_id parameter, how to obtain it, or its format. The schema only provides an integer range, which is insufficient for an agent to correctly select the ID. The description adds minimal meaning beyond 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?

The description clearly states the verb 'Add' and the resource 'restaurant' with the target 'user's Saved Restaurants list', making its purpose unambiguous. It naturally distinguishes itself from siblings like opentable_remove_favorite and opentable_list_favorites by naming the specific 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?

The description implies usage: when you want to save a restaurant for later. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. It leaves the agent to infer the appropriate context, though the action is clear enough.

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 no annotations provided, the description carries the full burden — and it is thorough. It discloses that tokens expire within minutes, that the tool auto-fetches the user's profile, that it returns confirmation_number + security_token needed for cancellation, that CC-required slots refuse without booking_token, and that confirm:true is required to commit while omitting it produces a dry-run with no booking.

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 every sentence contributes a distinct operational fact, but it is a long single paragraph that mixes workflow, parameter nuances, return values, and edge cases. It is efficient rather than padded, though minor restructuring or bullets would improve scannability.

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 mutating, 12-parameter tool with no annotations and no output schema, the description is nearly complete: it covers required upstream calls, token expiration, the dry-run/commit workflow, auto-resolved fields, the CC-required preview path, return values and their downstream use, the Listing-type alternative, and the database-region shard limitation.

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 high at 83%, but the description adds substantial meaning beyond the schema: slot_hash/reservation_token freshness, dining_area_id auto-resolution versus explicit pinning, booking_token's role for CC-required slots, experience_id tamper-check behavior, database_region shard routing, and the confirm dry-run contract. This is exactly the inter-parameter knowledge an agent needs.

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 concrete verb and resource: 'Book an OpenTable reservation.' It then defines the tool's scope precisely — locking a slot, dry-run vs commit, and required upstream tokens — and distinguishes it from adjacent tools like opentable_find_slots, opentable_book_preview, and opentable_cancel.

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 explicit sequencing: obtain a fresh slot_hash + reservation_token from opentable_find_slots immediately before booking; use opentable_book_preview for CC-required slots; and for Listing-type restaurants, check opentable_get_restaurant.bookable and surface phone/URL instead. This clearly states when to use this tool versus alternatives and when not to.

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, but the description adds valuable behavioral context beyond that: the slot is held for 60-90 seconds, the preview-to-book window is about a minute, and the tool surfaces a short-lived token. It also explains a subtle side effect (skipping a redundant re-lock) and a known failure mode for Listing-type restaurants. No contradiction with the readOnly annotation.

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 but front-loaded with the core purpose, and every subsequent sentence adds a distinct caveat or usage detail. It is longer than minimal, but the complexity (10 parameters, multiple slot types, time sensitivity) justifies the length. Slight room for improvement via structuring or bullets, but 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?

With no output schema, the description sufficiently explains what will be returned: cancellation policy, saved payment card, and the booking_token. It also covers required timing, prerequisites, fallback behavior for unsupported restaurants, and handling of Experience-mandatory slots. Nothing critical is missing for an agent to decide whether and how to call the tool.

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 some cross-tool meaning, such as passing experience_id from slot.experience_ids to route through the Experience slot-lock, and clarifies the role of reservation_token from find_slots. However, most parameter semantics are already carried by the schema, so the description does not need to carry much more weight here.

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-resource pair: 'Preview an OpenTable booking BEFORE committing.' It clearly distinguishes the tool from opentable_book by explaining it fetches the booking-details page and produces a booking_token rather than committing. This is more than a generic 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 explicitly says when the tool is REQUIRED (CC-required slots), when it is safe (standard slots), and when it cannot be used at all (Listing-type restaurants), including the fallback of checking opentable_get_restaurant.bookable and surfacing phone/URL. It also gives specific routing guidance for Experience-mandatory slots. This is strong when-to-use, when-not-to-use 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?

With no annotations, the description carries the full safety burden, and it does well by disclosing that confirm:true is required and that the default run is a non-destructive dry-run. It also warns that without confirmation no cancellation action is taken. It doesn't describe post-cancellation effects or return values, but the destructive-action guard is the critical behavior.

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 no filler: the purpose, required inputs, their source, and the critical confirmation behavior are all packed in, front-loading the action before the dry-run caveat. 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?

For a destructive cancellation tool with no output schema and no annotations, this is largely complete: it covers inputs, prerequisites, and the dry-run/confirm mechanism. The database_region parameter is well documented in the schema itself, so the only real gap is the lack of any description of the response or post-cancellation state, which is secondary to safe 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 only 40%, so the description compensates by explaining that restaurant_id, confirmation_number, and security_token all originate from opentable_list_reservations or opentable_book, and by clarifying the confirm flag's gating role. This adds real meaning beyond the raw schema types, though param-specific format details are still left to the schema or source tools.

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?

Starts with 'Cancel an OpenTable reservation,' a specific verb and resource that clearly identifies the tool's function. The name 'opentable_cancel' matches, and no sibling tool performs cancellation, so an agent can distinguish it at a glance.

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 clear conditions for use: the required params must come from opentable_list_reservations or opentable_book, and the two-step confirm:true flow is explicitly described. It doesn't explicitly contrast with alternatives like opentable_modify, but the cancellation use case is unambiguous.

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?

It discloses the read-only, no-auth behavior and goes beyond the annotations by describing the bridge role, port, version, extension link state, elapsed time, and the plain-English failure categorization. This gives the agent a concrete picture of what happens during the call, including how it disambiguates failure modes.

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 but every clause earns its place: it states the action, the exact URL, the full result payload, and the trigger condition. The most important decision information is front-loaded, and the diagnostic field list is highly relevant.

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

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

Despite having no output schema, the description enumerates every returned diagnostic component and the meaning of the hint. It also covers auth requirements and usage context, so an agent has all the information needed to invoke and interpret 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?

The input schema has zero parameters and the description explicitly states the fixed URL used, so there is no param ambiguity to compensate for. With no parameters, the description fully removes any need for the agent to infer inputs.

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 action — round-tripping a public www.opentable.com URL through the fetchproxy bridge — and precisely enumerates the diagnostic output it returns. It clearly distinguishes this tool from the OpenTable domain siblings, none of which perform connectivity/bridge diagnostics.

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 to call it: 'when a real tool fails and you want to know which hop broke.' This gives the agent a decision rule that separates the health check from the operational OpenTable tools, which are the things being diagnosed.

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?

With no annotations provided, the description carries the full burden, and it delivers: it discloses the exact endpoint, isModify flag, that confirmation_number is preserved while reservation_id/security_token may be regenerated, that dining_area mismatch is refused, that the tool returns was_modified: true, and that confirm:true is required for actual mutation. This is unusually transparent.

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: prerequisites, endpoint behavior, optional-parameter nuance, return shape, an edge case, and the confirmation flow are all covered without repetition. The most important purpose and precondition appear first.

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, no output schema, and a complex mutation/dry-run flow, the description is remarkably complete. It tells the agent what is required, why preview is mandatory, how confirm changes behavior, what output to expect, and when to check a restaurant's bookability first.

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 67%, so the description adds needed meaning for critical parameters: it groups restaurant_id + confirmation_number + security_token as the reservation identity, explains modify_token's mandatory origin, clarifies dining_area_id's optional restatement semantics, and connects reservation_token/slot_hash to the new slot. A few parameters like party_size remain obvious from context, but the description compensates well for the schema gap.

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 ('Modify an existing OpenTable reservation in place') and clearly distinguishes this from creation, preview, and cancellation flows. It names related sibling tools and explains that a preview token is mandatory, so an agent can unambiguously select this tool for modifications.

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 explicitly requires opentable_modify_preview first, explains why preview is mandatory, warns about Listing-type restaurants needing opentable_get_restaurant.bookable, and spells out the confirm:true dry-run vs. submission behavior. This gives clear when-to-use and when-not-to-use 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?

Beyond the readOnlyHint annotation, the description discloses the SSR URL mechanism (isModify=true), the auto-resolution behavior of dining_area_id, the hard dependency on this step before opentable_modify, and the Listing-type failure mode. It stops short of clarifying whether the 'CC re-hold details' reflect a hold actually placed by this call or a simulated preview — a lingering side-effect ambiguity for a read-only-annotated tool.

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 dense paragraph of roughly 110 words where every sentence earns its place: purpose, identity inputs, new-slot inputs, outputs, the book_preview mirror, the optional-parameter behavior, the prerequisite, and the edge case. It is front-loaded with the purpose and heavily compacted, but the density demands careful reading.

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 12-parameter, 8-required tool with no output schema, the description covers input provenance, return values (cancellation_policy, CC re-hold details, modify_token), the prerequisite step, and the Listing-type exclusion. Minor gaps remain: no statement about idempotency/repeated calls and the unresolved question of whether the CC re-hold is actually executed.

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 67% schema coverage, the description compensates for the undocumented identity parameters by naming restaurant_id + confirmation_number + security_token as the existing reservation's identity and giving their source, and by grouping date/time/party_size/reservation_token/slot_hash as NEW slot args from a fresh find_slots call. The schema already documents date, time, slot_hash, reservation_token, dining_area_id, experience fields, and database_region well, so the description need not repeat them.

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 ('Preview a MODIFICATION to an existing OpenTable reservation') and immediately differentiates itself from the sibling opentable_book_preview ('Mirrors opentable_book_preview, but the /booking/details URL includes confirmationNumber + securityToken + isModify=true') and from opentable_modify, whose token it produces. An agent can tell exactly what this tool does and how it differs from its closest relatives.

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 the tool chain: the existing reservation's identity comes from opentable_list_reservations or the original opentable_book result, the NEW slot args come from a fresh opentable_find_slots call, and this tool is 'REQUIRED before opentable_modify — no shortcut path.' It also tells when NOT to use it ('For Listing-type restaurants the modify can't proceed... check opentable_get_restaurant.bookable first').

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 not provided, so the description must handle behavioral disclosure. It describes the mutation (removing) but does not state whether the action is reversible (e.g., can add back later), whether it requires authentication, or what the response contains. For a mutation tool with no annotation safety profile, this is a gap; an agent might not know if the action has side effects beyond the list change.

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, clear sentence that is appropriately concise. It front-loads the action and object, avoiding unnecessary elaboration. While it could add more detail on parameters or behavior, it does not include fluff, so it scores high on conciseness relative to its length.

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 parameter, no output schema) and the absence of annotations, the description is minimal but incomplete for an agent to use it correctly. It lacks usage context, what constitutes a valid restaurant_id, and any behavioral expectations. However, the simplicity means less is needed than for a complex tool, so it is not a 1, but it still falls short of adequate.

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 0% and the description does not explain the restaurant_id parameter beyond its name. The schema only defines it as an integer, but the description does not clarify what a restaurant_id is (e.g., a unique identifier from a search result) or how to obtain it. With a single required parameter and no schema descriptions, the description should provide more practical guidance.

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 a restaurant') and the target resource ('Saved Restaurants list'). It effectively matches the tool name and distinguishes it from its sibling opentable_add_favorite (which would add rather than remove), though it does not explicitly name the sibling. The verb 'remove' is specific and unambiguous.

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 a use case for removing a saved restaurant but does not state when to use this tool versus alternatives. It does not mention that opentable_add_favorite is the opposite action or that opentable_list_favorites could be used to view the current list. No explicit conditions or exclusions are given, but the purpose is clear enough for an agent to infer the appropriate context.

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.