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

No annotations are provided, and the description only states the basic action. It does not disclose side effects (e.g., duplicate handling), authentication needs, or any other behavioral traits.

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 concise with no wasted words, but it could be improved by adding brief parameter context without detracting from conciseness.

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 lacks detail on return values, error handling, and behavioral context. For a simple tool with no output schema and no annotations, this is insufficient.

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%. The description adds no meaning for the single parameter 'venue_id'—no hint on how to obtain it or what it represents.

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' and resource 'venue' with clear context 'to the user's favorites'. It distinguishes from sibling tools like 'resy_remove_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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a venue_id from a prior search, nor does it refer to 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?

No annotations present, so description fully discloses behavior: Resy emails when a matching slot opens, and notes the 30-day notify window. No contradictions.

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 purpose and key constraints, no wasted words.

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

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

Covers main action and constraints; however, it omits behavior if notification already exists or details on removal (sibling resy_remove_notify exists). Slightly incomplete for a mutation tool.

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

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

Schema coverage is 67%; description adds context for time_start and time_end formats (HH:MM, 24h) and confirms the 30-day date constraint, enhancing understanding beyond parameter names and type info.

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

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

Description clearly states 'Subscribe to Priority Notify for a venue/date/party size' with a specific verb and resource, and it is distinguished from siblings like resy_book (booking) and resy_list_notify (listing).

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?

Description explains when to use (to get an email when a slot opens) and constrains usage with time window and 30-day date limit, but does not explicitly state when not to use or mention alternatives like resy_book for immediate booking.

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

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

Adds significant behavioral context beyond annotations: composite nature, dry-run preview, confirmation requirement, desired_time handling, and default payment method usage. Annotations mark destructiveHint=true and readOnlyHint=false, and the description aligns with those, adding no contradictions.

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 front-loaded with the main purpose and logically flows through behaviors. While slightly verbose, every sentence adds value. Could be tightened, but remains clear and well-structured.

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

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

Given the tool's complexity (9 params, composite, no output schema), the description covers essential behaviors: confirm, desired_time, allow_closest_time, payment method. Lacks detail on lat/lng usage and return format, but the preview description compensates. Sufficient for correct selection and invocation.

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

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

Schema coverage is 44%, but the description adds meaning for key parameters: confirm (gating), desired_time (24h format and behavior), allow_closest_time (opt-in for auto-booking), and payment_method_id (overrides default). Missing lat/lng explanation, but overall compensates well.

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 'Book a reservation' and explains it's a composite tool with explicit steps (find-slots → get details → book). It distinguishes from sibling tools by detailing the confirm-gated and dry-run behavior, making the purpose unambiguous.

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

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

Provides explicit when-to-use guidance: explains require confirmation, how to target a specific time via desired_time, behavior when time unavailable, and the allow_closest_time flag. It also contrasts with other tools like resy_find_slots by noting it does not auto-book different times without explicit opt-in.

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

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

The description reveals the dry-run preview behavior and cancellation fee disclosure, which goes beyond the annotations (destructiveHint: true) by detailing what happens in preview mode and what information is returned.

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

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

Two sentences: the first states the core function and identifier source, the second explains the critical confirm gating. No unnecessary words, effectively 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?

No output schema exists, but the description adequately covers return info (preview details for dry-run, and implies success for actual cancellation). Could briefly mention successful cancellation confirmation, but completeness is high given the tool's simplicity.

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?

Despite 100% schema coverage, the description adds meaning: it specifies the resy_token format ('rr://...') and clarifies the confirm parameter's role as a gating mechanism, enhancing the 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 ('Cancel') and the resource ('Resy reservation') using the resy_token identifier. It differentiates from sibling tools like resy_book and resy_list_reservations by focusing solely on cancellation.

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 explains the confirm-gated behavior: without confirm:true it returns a preview; with confirm:true it executes cancellation. This tells the agent exactly when and how to use the tool, including the dry-run preview content.

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?

All annotations (readOnlyHint) are consistent with the description. The description adds important behavioral information about token expiration, which is beyond what annotations provide. No contradictions.

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, no wasted words, immediately states purpose. Efficiently structured.

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?

Explains purpose, return value (tokens), and expiration warning. Lacks details on optional parameters and return structure, but for a simple list tool it is fairly 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 has 5 parameters with only 20% description coverage (date only). The description reinforces required parameters (venue_id, date, party_size) but does not explain optional lat/lng parameters. Given low coverage, more detail would help.

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

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

The description clearly states the verb 'List' and the resource 'available reservation slots' with scope 'specific venue, date, party size'. It distinguishes this tool from siblings like resy_book (booking) and resy_search_venues (searching venues).

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 guidance on when to use (right before booking) by noting 'Tokens expire quickly; book soon after fetching,' and explains the purpose of tokens. However, it does not explicitly state when not to use or list alternatives.

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

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

The readOnlyHint annotation already covers the read-only safety profile, so the description's job is lighter. It adds behavioral value by specifying the exact fields returned and explicitly stating that payment method IDs are not exposed, which helps an agent understand response boundaries.

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

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

One sentence front-loads the verb and resource, lists the relevant return fields, and adds the key exclusion about payment method IDs. 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 profile endpoint with one optional parameter fully documented in the schema, the description is complete enough: it states the resource scope, return fields, and a critical boundary. The absence of an output schema is mitigated by the field list.

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 single parameter 'view' has a detailed schema description explaining compact/full behavior. The tool description itself adds no additional parameter guidance, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') with a precise resource ('authenticated Resy user's profile') and enumerates the returned fields. The explicit note that payment-method IDs are not exposed distinguishes it from the sibling resy_list_payment_methods, so an agent can select it unambiguously.

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 by naming the authenticated user's profile and listing its contents, but there is no explicit guidance about when to prefer this over alternatives or when not to use it. The sibling list makes the distinction mostly self-evident, yet no usage conditions or exclusions are stated.

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 description's 'Get full details' aligns. However, it adds no additional behavioral context beyond what annotations provide, earning a baseline score.

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 wasted words. While concise, it could include a brief hint about usage or output to improve usefulness.

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?

No output schema, but the tool is simple (1 param). The description states 'full details' without specifying fields, which is adequate for a basic query. However, it lacks mention of potential errors or data constraints, leaving some ambiguity.

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 should compensate. It mentions 'by id' but does not clarify the venue_id's origin or format (e.g., from search). The schema specifies type/constraints, but the description adds minimal meaning.

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 ('Get full details') and resource ('a single Resy venue by id'), with a specific method. It distinguishes from siblings like resy_search_venues and resy_get_profile.

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 on when to use vs. alternatives (e.g., resy_search_venues) or when not to use. The description merely states what it does without contextual cues.

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

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

The description goes well beyond the annotations. It discloses that the tool makes exactly one authenticated request (bounding the side-effect footprint), never returns the credential itself (privacy guarantee), and reports three distinct failure classes plus round-trip time. The read-only property is redundant with the annotation, but everything else adds genuinely new operational context.

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 sentences, each earning its place: purpose, report shape, safety property, trigger condition — with the core action front-loaded. The only blemish is a minor grammar slip ('a api.resy.com-side problem').

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 zero-parameter tool with no output schema, the description fully covers inputs (none needed), behavior (credential resolution, one call, no credential leakage), outputs (source, acceptance, RTT, plain-English hint), and the trigger/timing for use. An agent can invoke this tool correctly with nothing further from the schema or annotations.

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 carries no burden and the baseline is 4. The description compensates by explaining exactly what the tool does upon invocation — credential resolution, one upstream request, and a human-readable report — so an agent knows what the 'argument' to expect.

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 verifiable action — resolve the credential the way real tools do, then make one authenticated request to api.resy.com — and immediately differentiates it from the operational sibling tools, all of which perform actual booking/search/favorite actions. Reporting the credential source, acceptance status, RTT, and a three-way failure hint gives the tool a crisp, unambiguous diagnostic mission.

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 final sentence makes the trigger precise: 'Call this when a real tool fails and you want to know which hop broke.' This gives the agent a clear use-after-failure condition. It never names exclusions or alternative tools explicitly, but for a standalone healthcheck the context is sufficiently clear to route the agent correctly.

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 safety profile is known. The description adds no extra behavioral context such as pagination, ordering, authentication needs, or response envelope details; it merely restates the resource. With annotations covering the main safety hint, this is adequate but not enriched.

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 that captures the tool's purpose without any filler. It is appropriately sized for a tool with one optional parameter.

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?

This is a simple read-only list with one optional enum parameter fully documented in the schema. Combined with the readOnlyHint annotation and the description of the returned resource, an agent has everything needed to call the tool correctly; no output schema or additional return-value explanation is necessary.

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 has a thorough description in the schema itself, so the tool description does not need to repeat it. The description adds no additional parameter meaning beyond the schema.

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

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

The description uses an explicit verb ('List') and a specific resource ('the user's favorited Resy venues'), making the operation unmistakable. The parenthetical 'hit list' clarifies Resy terminology, and the phrasing clearly separates it from mutation siblings like add_favorite/remove_favorite and from other read tools like 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 description states what the tool does but does not explicitly say when to prefer it over alternatives or when not to use it. Sibling names imply the distinction (list vs add/remove favorites), but the description itself offers no routing guidance to an agent.

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=true annotation already establishes the read-only safety profile, and the description adds useful domain context about what a Priority Notify subscription is. However, it discloses no further behavioral traits (pagination, ordering, response size), and with annotations present the bar for additional credit is higher.

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 with the action front-loaded and the em-dash clause adding genuinely useful clarification rather than filler. 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 zero-required-parameter, read-only tool with 100% schema coverage, the description covers what it lists and why that matters. The only gap is the absence of any hint about response shape, and with no output schema defined the agent gets no structured guidance there.

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 schema's own explanation of the single 'view' parameter is exceptionally detailed (default behavior, what compact strips, the no-field-projection rationale). The tool description adds no parameter-level information, so the baseline 3 applies.

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

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

The description uses a specific verb ('List') with a specific resource ('Priority Notify subscriptions') and explains the domain concept ('tables you are waiting for when reservations open up'). This clearly differentiates it from resy_list_reservations (different resource) and resy_add_notify/resy_remove_notify (different operation).

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 by the verb-resource pairing and sibling names (add/remove_notify), but the description itself offers no explicit when-to-use guidance and names no alternatives or exclusions. An agent must infer that this is the read counterpart to the notify mutation 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?

Annotations already mark this as readOnlyHint=true, and the description adds the returned field list and the integration contract with resy_book. It doesn't discuss auth or edge cases, but for a simple read-only list operation supported by annotations, this is sufficient added context.

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

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

Two tight sentences: the first states the operation and return fields, the second conveys the key downstream usage. No filler or redundancy, and the most important purpose information is front-loaded.

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

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

For a one-optional-parameter, read-only list tool with a richly documented schema and no output schema, the description provides the essential return contract and the connection to resy_book. An agent has enough information to invoke it correctly without additional 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 100%, and the input schema thoroughly documents the single 'view' parameter, including compact/full behavior and its tradeoffs. The tool description adds no parameter-level detail, so the schema carries the full burden and a baseline 3 is appropriate.

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

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

Description states a specific verb ('List') and resource ('the user's saved payment methods on Resy'), and enumerates return fields. It clearly differs from sibling list tools (reservations, favorites, notify) by naming the payment-method domain and specifying the fields returned.

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 sentence 'The id can be passed as payment_method_id to resy_book' gives a concrete, actionable use case for when this tool's result is needed. It does not explicitly enumerate exclusions or alternatives, but the downstream booking context is clear enough for an agent.

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 mark the tool as readOnlyHint=true. The description adds value by disclosing that results include resy_token, occasion, special_request, and cancellability, enhancing the agent's understanding of the output without contradicting annotations.

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

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

The description is two concise sentences. The first sentence states the core purpose, and the second adds parameter guidance and output details. No redundant information, front-loaded and 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?

Given the tool's simplicity (one optional parameter, no output schema, existing annotations), the description is nearly complete. It explains the action, parameter use, and key output fields. Minor gap: it doesn't explicitly state that it returns the user's own reservations, but that is implied by 'the user's Resy reservations'.

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 bears full responsibility. It explains the 'scope' parameter, its allowed values (upcoming, past, all), and the default behavior, providing semantic meaning beyond the schema's enum list.

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 'List the user's Resy reservations' with a specific verb and resource. It distinguishes from sibling tools like resy_book or resy_cancel, and mentions key output fields (resy_token, occasion, special_request, cancellability) that add specificity.

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 guidance on the 'scope' parameter: defaults to upcoming, with options to pass 'past' or 'all'. While it doesn't explicitly mention when not to use this tool or suggest alternatives, the context is sufficient for a list operation.

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 bears full responsibility for disclosing behavior. It only states the removal action, but does not mention side effects (e.g., irreversible), required user authentication, or behavior when the venue is not already a favorite. This lacks critical context for an AI agent.

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

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

A single sentence with 10 words, no redundancy. Every word is informative and directly describes the tool's purpose.

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 removal tool with one required parameter, the description is minimally sufficient. However, it omits details like whether removal is permanent, whether the venue must exist in favorites, or what the return behavior is (e.g., success indication). Given no output schema, these are 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?

The input schema has 0% description coverage, meaning the description must compensate. However, the description only mentions 'by venue_id' and adds no deeper semantics (e.g., format, origin, or constraints) beyond what the schema already provides. The parameter name is not sufficiently explained.

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

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

The description uses specific verb 'Remove' and resource 'venue from the user's favorites', with the parameter 'by venue_id'. This clearly differentiates from the sibling 'resy_add_favorite' and leaves no ambiguity about what the tool does.

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 implicitly suggests when to use the tool (when removing a favorite), but it does not explicitly state when not to use it or mention alternatives like 'resy_add_favorite'. For a simple opposite operation, the context is adequate but not explicit.

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

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

With no annotations, the description bears full burden. It discloses that the tool internally looks up the full spec from resy_list_notify, which is helpful. However, it does not mention side effects, idempotency, or error handling, leaving gaps.

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

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

The description is two sentences, front-loading the action and purpose. Every sentence adds necessary context, with no redundant information.

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

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

For a single-parameter tool with no output schema, the description is largely sufficient. It explains the core action and a key internal detail. Missing some behavioral context, but overall complete given the tool's simplicity.

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%, and the description only repeats the parameter name 'notify_id' without adding meaning (e.g., format, source, or constraints). The schema itself defines it as an integer with a range, but the description adds no extra semantic value.

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

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

The description clearly states the action ('Cancel a Priority Notify subscription') and the resource ('by notify_id'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like resy_add_notify, though the opposite action is implied.

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 that the notify_id should come from resy_list_notify, but does not explicitly state when to use this tool over alternatives or provide conditions for use.

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 covers safety, and the description adds useful behavioral context: returns slot tokens, depends on date and party size, and defaults to NYC geo when lat/lng are omitted. This goes beyond the annotation, though it does not discuss limits or potential empty-result behavior.

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

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

Two sentences carry the core purpose, return value, and default behavior with no filler. The most important facts are front-loaded, and 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?

Given the absence of an output schema, the description does a good job of telling the agent what to expect (venues with bookable slot tokens). It could be more explicit about when to choose this over resy_find_slots, but the schema covers the parameters and the description covers purpose and defaults well enough for a competent call.

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 baseline is 3. The description reinforces the importance of date and party_size and notes lat/lng defaults, but it does not add meaning beyond what the schema already documents for parameters like radius_meters, query, view, or limit.

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 ('Search'), a specific resource ('Resy restaurants'), and the key differentiator: it returns venues with availability and bookable slot tokens for a date and party size. This clearly distinguishes it from siblings like resy_get_venue and resy_find_slots.

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

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

The description implies the tool is for discovering restaurants with availability, and the mention of bookable slot tokens gives a clear search-oriented context. It does not explicitly name alternatives or state when not to use it, but the intended use case is reasonably clear from the sibling set.

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