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

Annotations already indicate a non-read-only, non-destructive write, and the description's 'Add' is consistent with that profile. However, it adds no further behavioral detail: idempotency, duplicate handling, error behavior, and response expectations are not disclosed.

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, front-loaded sentence with no filler. It states the action and the method of identifying the venue efficiently.

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 mutation with annotations covering the safety profile, the description gives enough information to know what the tool does and what input is required. A note about response or error behavior would round it out, but nothing essential to invoking the tool 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?

The phrase 'by venue_id' establishes that the venue is identified by the single parameter, but it largely restates the schema property name. With 0% schema description coverage, more detail would have been helpful, though the parameter is simple and self-descriptive.

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 uses a specific verb ('Add'), names the resource ('a venue'), and specifies the target ('user's favorites'), making the operation unambiguous. It also distinguishes itself from siblings like resy_remove_favorite and resy_list_favorites by the operation type.

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 wording implies the tool should be used when a user wants to favorite a venue, but it gives no explicit guidance on when to prefer this over alternatives such as resy_remove_favorite or resy_list_favorites. There are no stated exclusions, prerequisites, or contextual conditions beyond the obvious action.

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 minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses the core behavior (email notification on matching slot) and the date-window limitation, but does not mention side effects like idempotency, whether it replaces existing notifications, or response format. It adds some behavioral context beyond annotations but is not comprehensive.

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

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

Three sentences, no fluff, front-loaded with the main purpose. The first sentence states the action, the second explains the effect, and the third gives the time and date constraints. Every sentence earns its place.

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

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

For a 6-param tool with no output schema, the description covers the main purpose, the time window, and the date limit. It doesn't mention return value or idempotency, but those are not critical for a subscription tool. It omits the service_type_id default, but that is already in the schema. Overall, an agent can call this correctly without missing essential information.

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% (4 of 6 params described). The description adds meaning for time_start/time_end (window bounds, HH:MM format) and clarifies the date constraint, but does not elaborate on venue_id, party_size, or service_type_id. Since venue_id and party_size are self-explanatory from their names and the schema covers the rest, the description adds moderate value but does not fully compensate for the 33% missing schema descriptions.

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: 'Subscribe to Priority Notify for a venue/date/party size' – a specific verb, resource, and key parameters. It also explains the outcome ('Resy emails you when a matching slot opens'), making the purpose unambiguous and distinguishable from siblings like resy_remove_notify or resy_list_notify.

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 provides clear context on when to use (to get notified about a slot) and a key constraint (notify window ~30 days). It doesn't explicitly mention alternatives or when not to use it, but the purpose is so specific that an agent can infer it should be used when the goal is to be notified rather than to book directly.

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 (readOnlyHint false, destructiveHint true) are consistent with a mutation tool, and the description goes far beyond them: it discloses the preview-first contract, the confirmToken/terms_token binding, that a changed slot type or cancellation terms re-previews without booking, the DRAFT_CHANGED refusal, and the duplicate-reservation guard that protects against timed-out retries booking twice.

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 correctly with the verb and composite behavior, but the confirmation flow is restated twice ('To book: on a client without a confirmation prompt...' and 'Asks the user to confirm first: a confirmation prompt where the client supports one...'), which is redundant for an already dense wall of text.

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 high-stakes, multi-param mutation with no output schema and no annotations beyond safety hints, the description covers the preview payload contents, every branch (unavailable time, changed terms, duplicate reservation, confirm vs elicitation clients), and the token plumbing. An agent has enough to call it correctly.

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

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

With 58% schema coverage across 12 params, the description supplies the missing semantics for desired_time, slot_type, terms_token, confirmToken, allow_duplicate, allow_closest_time and payment_method_id, including the token/argument combinations required per confirmation mode. It never mentions lat/lng, which remain undocumented in both places.

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 ('Book a reservation') and immediately clarifies it is a composite (find-slots → get booking details → book) that books ONLY the exact slot a preview showed. This distinguishes it cleanly from the sibling resy_find_slots and from resy_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?

Explicitly states when it previews vs books, how to target a slot (desired_time, slot_type), what happens when the exact time is unavailable (no auto-book unless allow_closest_time:true), the duplicate-reservation refusal and its allow_duplicate escape hatch, and the two confirmation paths keyed to MCP_CONFIRM_MODE. Alternatives and exclusions are named rather than inferred.

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 destructiveHint annotation, the description discloses the confirmation flow, the two-phase behavior in fallback mode, and that the preview shows venue, date, time, party size, and cancellation fee. This gives the agent a realistic model of the tool's side effects and interaction pattern.

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 compact and front-loaded: the core action appears in the first phrase, followed only by essential operational details. Every sentence adds useful information, and the confirmation flow is explained without unnecessary padding.

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

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

For a destructive cancellation operation with two parameters and no output schema, this description is complete. It explains the token source, the preview contents, and the full confirmation/fallback mechanism, so an agent knows how to invoke it correctly in both supported and fallback modes.

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?

Although the schema already describes both parameters, the description adds critical meaning: resy_token provenance from resy_book or resy_list_reservations, and confirmToken semantics including when it must appear, that it must be passed back with the same arguments, and that it is ignored when elicitation is supported.

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: 'Cancel a Resy reservation by its resy_token', and clarifies the exact identifier format plus where it comes from ('returned from resy_book or resy_list_reservations'). This makes the tool's purpose unambiguous and distinct from the sibling tools.

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 states when to use the tool (to cancel a reservation) and provides required context: the resy_token must come from resy_book or resy_list_reservations. It also gives strong when-not guidance for confirmToken, saying it should 'never be on the first call, never invented, never reused'.

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 marks this as a safe read operation; the description adds valuable behavioral context beyond that by disclosing that the response contains config_tokens and that those tokens expire quickly. It does not cover rate limits or live-availability caveats, but it provides material, non-obvious behavior that an agent needs to avoid acting on stale data.

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 no filler or repetition. It front-loads the core purpose first, then adds the critical return-value and expiry warning. Every sentence earns its place.

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

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

With no output schema, the description appropriately discloses the key return value (config_tokens) and its short lifespan. However, the tool has five parameters with only 20% schema coverage, and the unexplained lat/lng fields create real ambiguity. The description also stops short of connecting the tokens to the specific booking sibling that consumes them, leaving room for an agent to misinterpret the overall flow.

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 20% (just the date format), so the description must compensate for the other parameters. It does clarify venue_id ('specific venue'), date, and party_size conceptually, but lat and lng are completely unexplained and no guidance is given about whether they are optional locators or alternatives to venue_id. This leaves significant parameter ambiguity.

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 uses a specific verb ('List') and resource ('available reservation slots at a specific venue'), and clearly identifies the two key query dimensions ('date + party size'). It also states that the output consists of booking-ready config_tokens, which distinguishes it from venue-search and booking tools. An agent can immediately tell what this tool does and how it differs from 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?

The description conveys the intended workflow: fetch slots, receive tokens, then book soon afterward because tokens expire quickly. While it does not explicitly name resy_book as the alternative or provide a when-not-to-use statement, the token-expiry warning gives clear operational context and makes the pre-booking usage pattern evident.

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 useful context by listing the returned fields and explicitly stating that payment method IDs are not exposed, but it does not discuss authentication requirements, errors, or response format. For a read-only profile getter this is adequate but not rich.

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 concise sentences, front-loaded with the primary action and returned data. The exclusion of payment method IDs is relevant and earns its place; there is no filler or redundancy.

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, no-required-parameter tool, the description provides the essential return fields and an important exclusion. The optional 'view' parameter is fully documented in the schema, so nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, and the 'view' parameter already has a detailed description explaining compact versus full response shapes. The tool description itself adds no parameter-level meaning, 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?

The description uses a specific verb ('Get') and resource ('authenticated Resy user's profile'), then enumerates the returned fields: name, email, phone, booking count, member-since date. The explicit note that payment method IDs are not exposed distinguishes this tool from resy_list_payment_methods.

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 it clear this is for profile retrieval and warns that payment method IDs are not exposed, implying it should not be used as a payment-method source. However, it does not explicitly name an alternative tool or provide when-to-use/when-not-to-use guidance beyond that single exclusion.

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 communicates the safe read-only nature. The description adds the expectation that 'full details' will be returned, but it does not disclose any further behavioral traits such as payload size, response format, required authentication, or rate limits. This is acceptable but minimal.

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 with no filler or irrelevant details. The verb, resource, and key parameter are front-loaded, making it easy for an agent to parse 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 read-only get-by-id tool, the description is minimally viable, but without an output schema it leaves 'full details' vague. It does not enumerate what venue attributes are included, nor does it mention how to obtain a valid venue_id from sibling tools. This is functional 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?

Schema description coverage is 0%, so the description must compensate by explaining venue_id. It only repeats 'by id' and does not clarify where the ID comes from, how it identifies the venue, or what values are expected beyond the schema's integer type. The parameter semantics are therefore only minimally conveyed.

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'), the resource ('Resy venue'), and the scope ('single ... by id'), making the operation unambiguous. It is clearly distinct from search/list siblings because it targets one venue by ID and promises 'full details'.

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 no guidance about when to choose this tool over resy_search_venues or other venue-related tools. It only implies that a venue_id is required, without stating that the ID likely comes from a prior search or that this tool should be used for fetching a single venue's complete details.

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 and idempotentHint annotations, the description discloses meaningful behavior: it performs exactly one authenticated request, reports the credential source, round-trip time, and distinguishes failure categories, and explicitly says it never returns the credential itself. This adds security-relevant context not present in 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 earns its place: behavior, output, safety, and usage are covered in a compact, front-loaded description. There is no filler or repetition of the title or annotations.

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 parameterless diagnostic tool without an output schema, the description is complete: it explains what happens, what gets reported, the safety guarantee, and the intended trigger condition. An agent has enough context to invoke it correctly.

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

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

The tool has zero parameters, so the schema fully covers the input contract. The description adds no parameter details, but none are needed; per the rubric, 0 parameters warrants a baseline of 4.

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 names a specific verb and resource: it resolves the credential, makes one authenticated request to api.resy.com, and reports the diagnostic results. It is distinctly a healthcheck/diagnostic tool, clearly differentiated from the domain-operation siblings like resy_book or resy_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 explicitly states when to use it: 'Call this when a real tool fails and you want to know which hop broke.' It does not enumerate alternatives or exclusions, but the usage context is clear and not likely to be confused with the sibling tools.

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 communicates that this is a safe read operation, and the description aligns with that by saying 'List'. The description adds minimal behavioral context beyond purpose, such as the user-scoped nature of the data, but does not disclose details like pagination, ordering, or auth requirements. With the annotation covering the safety profile, this is adequate but not rich.

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 with no filler. The parenthetical 'hit list' is a useful synonym rather than redundancy, and the core action and target are front-loaded.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description plus the detailed parameter schema provide enough context for correct invocation. It does not describe return structure or pagination, but the low complexity and readOnly annotation reduce the need for further elaboration.

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 only parameter 'view' is thoroughly documented in the input schema. The tool description itself adds no parameter-level meaning, so it neither helps nor hurts. Baseline 3 is appropriate because the schema already does the heavy lifting.

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

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

The description uses a specific verb ('List') and resource ('the user's favorited Resy venues'), and adds the helpful 'hit list' alias for clarity. It is clearly distinct from sibling tools like resy_list_reservations, resy_add_favorite, and resy_remove_favorite.

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 clearly implies this tool is for retrieving favorites, so an agent can infer when to use it. However, it does not explicitly state when not to use it or mention alternatives such as resy_list_reservations or resy_search_venues, leaving the routing entirely to inference.

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

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

The annotation readOnlyHint=true already declares safety, and the description's 'List' aligns with that. It adds useful scoping that the results are the current waiting lists, but it does not disclose response format, ordering, pagination, or error 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?

One sentence that begins with the action and object, with the explanatory clause adding useful domain context. There is no filler or redundancy.

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?

The operation is a simple read-only list with one optional, well-documented parameter and no required inputs. The description plus schema and annotations give enough to invoke it correctly; only minor details about the returned payload shape are left to the view parameter.

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

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

The only parameter, 'view', is fully documented in the schema with a detailed description of compact vs full response shapes and the rationale for not doing field projection. Since schema coverage is 100%, the description has no burden to add parameter semantics.

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 uses a specific verb ('List') with a precise resource ('Priority Notify subscriptions') and explains what those are ('tables you are waiting for when reservations open up'). This clearly distinguishes the tool from sibling notify operations like add/remove and from list_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 described use case—viewing tables you are waiting on—gives clear context for when to call it. It does not explicitly name alternatives or when not to use it, but there is no competing 'list notify' sibling, so the guidance is sufficient.

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 safety profile is covered. The description adds the return field set and downstream integration with resy_book, which is useful, but it does not disclose additional behavioral traits such as authentication requirements, rate limits, or what happens when no payment methods are saved. Given the read-only annotation, a middle score is appropriate.

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 short sentences with no filler. It front-loads the core purpose and immediately gives the most important return fields and reuse context, so 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 simple, read-only list operation with one well-documented optional parameter and no output schema, the description covers purpose, return fields, and the key integration use case. Nothing essential for an agent to call this tool correctly is missing.

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

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

Schema coverage is 100%, and the view parameter's description in the schema is already detailed and self-explanatory. The tool description does not add any parameter-level meaning, 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?

The description uses a specific verb ('List') and resource ('the user's saved payment methods on Resy'), and enumerates the exact returned fields (id, brand, last four digits, expiry, is_default). This clearly differentiates it from sibling list tools like resy_list_reservations and resy_list_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 provides clear context by explaining that the returned id can be passed as payment_method_id to resy_book, effectively stating when this tool is useful. It does not explicitly name alternatives or exclusions, but no direct alternative for listing payment methods exists among the siblings.

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

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

Annotations declare readOnlyHint=true, so the safe-read profile is already known. The description adds behavioral context beyond that: the default scope ('Defaults to upcoming'), the effect of passing scope values ('pass scope="past" or "all" to broaden'), and the response content (resy_token, occasion, special_request, cancellability). No contradiction with 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?

Two sentences carry all essential information with no filler. Purpose comes first, parameter guidance second, and output payload last. 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 simple, optional-parameter list tool with no output schema, the description provides enough: the action, scope defaults, and the notable output fields. It lacks pagination or authentication details, but those are less critical given the readOnly annotation and the single enum parameter. The cancellation-token hint also links it to the broader workflow.

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 description coverage at 0%, the description fully compensates by explaining the only parameter: it states the default ('upcoming'), the alternative enum values, and the effect of choosing them ('broaden'). This is meaningful guidance the schema alone does not provide.

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+resource: 'List the user's Resy reservations.' This clearly distinguishes it from sibling listing tools (e.g., resy_list_payment_methods, resy_list_favorites) by naming the exact resource. It also adds the key deliverable (resy_token) that ties it to the cancellation workflow.

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 provides clear context for when to use the tool: 'Each result includes the resy_token needed for cancellation' routes an agent toward this tool when preparing for resy_cancel. It does not explicitly name alternatives or exclusions, but the default-to-upcoming scope and the 'to broaden' phrasing give practical usage direction.

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 annotation already states readOnlyHint=false, indicating the tool mutates state. The description adds no further behavioral traits – no idempotency, side effects, consent requirements, or failure behavior. It simply restates the action, providing no transparency beyond what the annotation already offers.

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 short sentence that front-loads the action and critical information. Every word contributes; there is no filler or redundancy.

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?

The tool is simple (one required param, no output schema) and annotations cover the basic safety profile. The description fully identifies the action and parameter. Minor omissions like error conditions or prerequisite that the venue must already be a favorite are not critical given the low complexity.

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 explain the parameter. It names 'venue_id' and indicates it identifies the venue to remove, but does not clarify how to source it (e.g., from resy_search_venues) or any additional context. For a single integer parameter, this is minimally adequate but adds little beyond the parameter name itself.

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 ('Remove'), a specific resource ('a venue from the user's favorites'), and the required parameter ('by venue_id'). This clearly distinguishes it from sibling tools like resy_add_favorite and resy_list_favorites, and even from resy_remove_notify which targets a different resource.

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

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

Usage is implied: remove a favorite by providing venue_id. However, the description gives no explicit when-to-use guidance, no exclusions, and does not mention alternatives such as resy_remove_notify or when not to use this tool (e.g., if the venue is not a favorite). It relies on the agent to infer context from sibling names.

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 annotations already mark the tool as mutating but non-destructive, so the description is not required to restate that. It adds one useful behavioral detail: the tool internally looks up the full spec from resy_list_notify, which explains why only notify_id is needed. It does not discuss idempotency or error behavior, but the cancel action is clear and does not contradict 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?

Two short sentences, front-loaded with the active purpose, and no filler. The internal-lookup detail is the only extra information and it 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 one-parameter cancellation tool with no output schema, the description covers the action, the exact required input, and why that input is sufficient. The only minor gap is that it doesn't state failure behavior for a nonexistent notify_id, but that is not essential to selecting and invoking 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 provides no parameter descriptions, so the description must carry the meaning. It identifies notify_id as the subscription identifier and explicitly states that no other input is needed, which is the critical semantic missing from 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 opens with a specific verb ('Cancel'), a concrete resource ('Priority Notify subscription'), and the key identifier ('notify_id'). This makes the tool's function obvious and separates it from sibling list/add tools even without naming 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 the tool is for canceling an existing subscription rather than listing or adding one, and it notes that no other input is needed. However, it never explicitly says when to choose this over resy_add_notify or how to obtain a valid notify_id, so routing is left mostly to inference.

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

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

The readOnlyHint annotation already declares this is a read operation, and the description adds useful behavior beyond that: it returns venue objects with bookable slot tokens and defaults to NYC geo when lat/lng are omitted. It does not cover pagination or rate limits, but for a read-only search tool the annotations and description together are reasonably 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?

Three concise sentences with no filler. The core purpose is front-loaded, followed by the key return characteristic and the default geo behavior. Every sentence earns its place.

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

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

For an 8-parameter tool with no output schema, the description gives only an overview: venues and bookable slots, plus the geo default. It does not describe response shape details, pagination, or how the returned venue identifiers might relate to downstream tools like resy_get_venue or resy_find_slots. It is adequate but leaves meaningful gaps.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description mostly restates the date/party size relationship and the lat/lng defaults already present in the schema, adding little beyond what structured fields provide.

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 clear verb and resource: 'Search Resy for restaurants with availability.' It also specifies the returned data ('venues including any bookable slot tokens') and the date/party context requested. However, it does not explicitly distinguish itself from sibling tools like resy_find_slots or resy_get_venue.

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: use this when searching for restaurants with availability for a date and party size, with optional geo or keyword narrowing. It does not mention when to prefer sibling tools like resy_find_slots or resy_get_venue, and it offers no explicit exclusions.

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