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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core mutation (add favorite) but does not mention authentication requirements, duplicate handling, what happens if venue_id is invalid, or whether the operation is reversible.

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 short sentence with no filler; the action, target, and parameter are all front-loaded. 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 one-parameter mutation with no annotations and no output schema, the description covers the essential call surface. It is less complete on behavioral edge cases (duplicates, errors, response shape), so an agent has the minimum but not full context.

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

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

Schema description coverage is 0%, but the description explicitly assigns meaning to the parameter: venue_id identifies the venue to add. It goes beyond the raw schema's integer constraint, though it doesn't say how to obtain a valid venue_id (e.g., via search_venues).

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 exact resource ('a venue to the user's favorites'), and identifies the key input ('by venue_id'). This clearly differentiates it from sibling tools like resy_list_favorites and resy_remove_favorite without needing to inspect schemas.

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 intended use is implied: call this when the user wants to favorite a venue. However, the description gives no explicit guidance on when not to use it (e.g., when the venue is already favorited, or when to prefer list_favorites/remove_favorite).

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?

No annotations are provided, so the description carries the transparency burden. It clearly discloses the subscription effect ('Resy emails you when a matching slot opens'), the time-window semantics, and the ~30-day date limitation. It does not address duplicate subscriptions or auth requirements, but the core side-effect is 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?

Four short sentences, no filler, and the main purpose is front-loaded. Each sentence earns its place: purpose, outcome, parameter semantics, and a date-window constraint. It is concise without being under-specified.

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

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

For a 6-parameter action with no output schema and no annotations, the description covers the essential decision points: what the tool does, what it triggers, how time bounds work, and the date-window limitation. The optional service_type_id is documented in the schema. Return value/error behavior is not described, but that is not a blocking gap for a subscription action.

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%, with venue_id and party_size lacking descriptions. The description adds meaning by explaining that time_start/time_end define the acceptable window and reiterating the HH:MM 24h format; it also contextualizes the date restriction. Since venue_id and party_size are self-explanatory names, the combined coverage is adequate.

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 first sentence names the specific action ('Subscribe to Priority Notify'), the resource ('venue/date/party size'), and the observable outcome ('Resy emails you when a matching slot opens'). This clearly sets it apart from sibling management tools like list_notify and remove_notify, as well as from booking/search 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?

The description implies the tool is for passive waiting rather than immediate booking, and it warns that only near-term dates are accepted. However, it never explicitly states when to prefer this over find_slots or book, and it does not mention how it relates to existing notify subscriptions.

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 signal mutation (destructiveHint=true), but the description adds critical non-obvious behavior: without confirm:true it is a dry-run and books nothing, and an unavailable desired_time never silently books a different time. These details go beyond what annotations or schema convey.

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

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

Every sentence adds operational value: purpose, internal pipeline, confirm gate, time targeting, fallback rule, and payment default follow in logical order. It is dense but not bloated or repetitive.

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 specifies the dry-run preview contents and the unavailable-time response. It does not explicitly state the confirmed-booking success payload or failure cases, but the essential call-control and safety behavior is well covered.

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 44%, so the description carries real weight. It clarifies confirm (preview vs actual), desired_time (target a specific slot), allow_closest_time (fallback semantics), and payment_method_id (defaults). Optional lat/lng remain undocumented, but the core booking parameters are 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?

States 'Book a reservation' – a specific verb and resource – and expands with a composite pipeline (find-slots → get booking details → book). This clearly distinguishes it from siblings like resy_find_slots 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?

Explains confirm-gated dry-run mode, how desired_time and allow_closest_time interact, and the default payment method behavior. It does not explicitly name sibling alternatives, but the composite workflow and fallback semantics make when-to-use clear.

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

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

Annotations already signal destructiveHint=true and readOnlyHint=false, but the description adds crucial behavior beyond that: it details the dry-run preview (venue, date, time, party size, cancellation fee) and explicitly states that nothing is cancelled without confirm:true. This is exactly the kind of safety-critical context that helps an agent avoid accidental destructive actions. The description dramatically enhances the annotation's meaning.

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, each purposeful. The first establishes the action and how to obtain the token; the second explains the confirm gate and preview details. The critical safety information is front-loaded, and there is zero redundancy or 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?

The description covers the essential aspects: how to identify the reservation, the destructive action, and the confirm gate that prevents accidental cancellation. It doesn't mention what happens on successful cancellation (e.g., return values), but since no output schema exists and the tool is destructive, the preview behavior is more important. Minor gaps like error handling are not critical, so a 4 is justified.

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%, so both parameters are documented. The description goes further by explaining the interplay between confirm and resy_token: that confirm gates the action and that resy_token identifies the reservation. This adds interaction context beyond individual parameter descriptions, though it doesn't add new parameter-specific details beyond the schema, so a 4 is fitting.

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 identifies the tool's action ('Cancel a Resy reservation'), the resource (resy_token), and even specifies the token format (rr://...) and its origin (from resy_book or resy_list_reservations). This immediately distinguishes it from siblings like resy_book or resy_list_reservations, leaving no ambiguity.

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 explains the confirm-gated behavior: without confirm:true it returns a dry-run preview, effectively telling the agent when to set confirm true vs. when to use it as a preview. It also connects to sibling tools by indicating where the resy_token comes from. However, it doesn't explicitly state when NOT to use this tool or mention alternative cancellation paths, so a 4 is appropriate.

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?

With no annotations provided, the description bears the full burden of behavioral disclosure. It indicates a mutation but does not state whether removal is idempotent, what happens if the venue_id is not in favorites, or whether any confirmation or error is returned. No output schema exists to clarify the response.

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, tightly worded sentence with no redundancy. It uses the critical identifying parameter (venue_id) and clearly conveys the operation.

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 definition is minimal. Given zero annotations, no output schema, and a mutation operation, important context is missing: idempotency, error behavior, and relationship to sibling tools. An agent could call it correctly in the basic case but would be unprepared for realistic failure scenarios.

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%, but the description explicitly names venue_id as the parameter, which adds meaning beyond the bare schema type. However, it does not explain the format or provenance of venue_id (e.g., how to obtain it), so the description only partially compensates for the coverage 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 clearly states the action ('Remove'), the target resource ('a venue from the user's favorites'), and the identifying parameter (venue_id). It is unambiguous and distinct from siblings like resy_add_favorite 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?

No guidance is given about when to use this tool versus alternatives such as resy_add_favorite or resy_list_favorites. There is no mention of prerequisites (e.g., the venue must already be in favorites) or edge cases.

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

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

No annotations are provided, so the description carries the full burden. It discloses one useful behavioral trait: the tool internally looks up the full spec from resy_list_notify, so only notify_id is required. However, it does not disclose whether cancellation is irreversible, whether it requires authentication, error behavior, or the response/outcome, which are significant for a mutating 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?

Two short sentences with no filler. The action and key input are front-loaded, and the internal lookup detail is a single clause that earns its place. Very efficient.

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

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

For a one-parameter tool, the description covers the operation, the parameter's role, and an internal behavior. However, with no output schema and no annotations, it does not state what a successful cancellation returns or how errors are signaled, and it omits authentication/authorization context. It is usable 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 schema has 0% description coverage and only defines type/range for notify_id. The description adds meaning by stating the parameter is the subscription identifier and that no other input is needed, and it references resy_list_notify as the source of the spec. It does not explain how to obtain the notify_id or validate it, so coverage is partial.

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 ('Cancel') and resource ('Priority Notify subscription') and identifies the key input (notify_id). This distinguishes it from sibling tools like resy_add_notify and 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?

The description implies usage by defining the action, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites such as first listing notifications. It does note that no other input is needed, which offers some guidance. Absence of explicit exclusions or alternative references limits the score.

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.