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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond them: it doesn't say whether the add is idempotent, what happens if the venue is already favorited, or whether authentication is required.

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 efficient sentence with the action and key field front-loaded. Nothing is wasted, though there also isn't enough content to make it fully informative.

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 one-parameter mutation whose annotations cover the safety profile and which has no output schema, the description is minimally adequate. It omits failure behavior, idempotency, and any hint of the counterpart tools, leaving gaps an agent would face at the edges.

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?

There is one parameter with 0% schema description coverage, so the description must carry the load. It names venue_id but adds no semantics beyond the name itself—no format, source, or constraint detail—though the field is largely self-explanatory as an integer venue identifier.

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 (Add) and resource (venue to the user's favorites) and identifies the keying field. It doesn't explicitly contrast with siblings like resy_remove_favorite or resy_list_favorites, but the operation is unambiguous from the wording.

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 by the purpose, but there is no explicit when-to-use, prerequisites, or mention of the sibling alternatives (resy_remove_favorite, resy_list_favorites). An agent can infer intent but gets no routing guidance.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true. The description adds genuinely non-obvious behavior: the async email notification on a matching slot, the near-term-only eligibility window, and how time_start/time_end bound acceptance. It stops short of covering idempotency or rate limits, keeping it below a 5.

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 tight sentences, front-loaded with the action and followed by the two facts an agent actually needs (email behavior, time-window semantics, date-window limit). No filler or repetition of the name.

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 carries the burden and does cover the key consequence (email notification). It omits what is returned on success and whether the resulting registration needs an id for later removal via resy_remove_notify, which is a minor but real gap 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%, and the description adds real meaning on top of it: time_start/time_end are framed as the acceptable window (HH:MM, 24h), reinforcing the schema's pattern and defaults. It leaves venue_id and party_size to the schema, which is reasonable given they are self-evident.

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: 'Subscribe to Priority Notify for a venue/date/party size,' which an agent can immediately distinguish from the list/remove notify siblings. It is clear and specific, though it never names those siblings explicitly the way a 5 would.

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 ~30-day notify window is stated as a real constraint, which implicitly tells the agent when this tool is applicable. However, there is no explicit guidance contrasting it with resy_find_slots (immediate availability) or explaining when notify is preferable to simply booking — usage must be 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?

Annotations already flag destructiveHint=true and openWorldHint=true, but the description goes well beyond them: it enumerates exactly what the phase-1 preview returns (account, venue, date, slot time, slot_type, card last-4, cancellation/payment terms), states that a changed slot_type or terms causes a refusal/re-preview (DRAFT_CHANGED), and warns that confirmToken must never be invented or reused.

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

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

Front-loaded with the core action and the preview-first invariant before the mechanics. It is long and somewhat repetitive about the confirmation flow (described once narratively and again via confirmToken), but given 12 parameters and a multi-phase protocol, most sentences carry necessary 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?

With no output schema, the description carries the full burden and discharges it: it specifies what the preview response contains, when booking proceeds, when it is refused (slot gone, terms changed, duplicate reservation), and how each confirmation mode resolves. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is only 58%, but the description compensates richly: it defines desired_time as HH:MM 24-hour targeting, explains slot_type's role across seating types and its optionality when a confirmToken is present, and clarifies that payment_method_id must reference a saved card from resy_list_payment_methods, previewed by brand and last-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?

Opens with a specific verb+resource ('Book a reservation') and immediately clarifies it is a composite tool that internally runs find-slots → booking details → book. It distinguishes itself from sibling resy_find_slots by stressing that it 'books ONLY the exact slot a preview showed,' so an agent can tell booking apart from searching.

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 books vs when it only previews, names the alternative branch (omit desired_time, use allow_closest_time) for unavailable times, and spells out the two distinct confirmation paths (confirmToken fallback vs elicitation client). It also documents the duplicate-refusal rule and how to override it with allow_duplicate:true.

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

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

Annotations already flag this as destructive, open-world and non-read-only, and the description goes well beyond them: it discloses the confirmation preview contents (account, venue, date, time, party size, fee), the two-phase confirmToken protocol and MCP_CONFIRM_MODE, and the precise meaning of cancelled/outcome including the ambiguous 'unknown' case. This is unusually rich behavioral disclosure for a mutation 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?

Front-loaded with the verb and identifier, then the confirmation flow, then result semantics. It is dense and long, but essentially every clause carries non-redundant information; only the MCP_CONFIRM_MODE parenthetical could be trimmed slightly.

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, and the description compensates fully by naming the return fields (cancelled, outcome) and their possible values. Combined with the confirmation-flow detail, an agent has everything needed to call this correctly and interpret the result.

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

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

Schema coverage is 100% and the schema already documents confirmToken's purpose in depth, so the baseline is 3. The description adds value by stating where resy_token comes from (rr:// identifier returned from resy_book or resy_list_reservations), which the schema does not say.

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

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

States a specific verb+resource (cancel a Resy reservation) and immediately identifies the identifying argument, pointing to resy_book and resy_list_reservations as the token's origin. This clearly separates it from read-only siblings like resy_list_reservations and from resy_book.

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

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

Explains the confirmation requirement, the client-dependent branching (elicitation vs two-step confirmToken fallback), and explicitly warns never to pass confirmToken on the first call. It also routes the agent to resy_list_reservations on an 'unknown' outcome before retrying, which is exactly the alternative-selection guidance expected.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the return payload contains config_tokens and those tokens expire quickly, which is a time-sensitivity constraint an agent must act on. No mention of auth requirements, rate limits, or empty-result behavior keeps it below 5.

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 tight sentences, front-loaded with the core operation and ending with the operational warning about token expiry. No filler.

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

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

For a read-only, no-output-schema tool, the description covers the main workflow and the token lifecycle well. However, it omits the purpose of lat/lng, the date/timezone format expectations, and what the response looks like when no slots exist, leaving 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 coverage is only 20% (just the date format), so the description carries most of the burden. It names venue_id, date, and party_size at a semantic level, but lat and lng are completely unmentioned in both the description and the schema, leaving two of five parameters opaque.

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

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

States a specific verb ('List available reservation slots'), the resource, and the three scoping inputs (venue, date, party size) in one sentence. An agent can immediately tell this apart from resy_search_venues (which finds venues) and resy_book (which consumes the tokens this tool produces).

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 frames the fetch-then-book workflow ('Returns slot config_tokens suitable for booking... book soon after fetching'), which implicitly routes the agent to resy_book next. It never states exclusions or what to do when a venue has no availability, so it falls short of the explicit when/when-not bar.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description only needs to add context, which it does: it names the returned data set and explicitly scopes out payment method IDs, preventing an agent from attempting to read sensitive payment data. The phrase 'authenticated Resy user' also signals an auth requirement.

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 with zero filler; the core purpose and field list lead, and the scoping caveat follows. Every clause carries 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?

With no output schema, the description correctly enumerates the return fields, and annotations cover the safety profile. A brief note on the default view behavior would make it airtight, but nothing essential for a correct call 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?

There is a single optional 'view' parameter with 100% schema description coverage, and the schema already explains the compact/full tradeoff in depth. The description adds nothing about the parameter, so the schema does all the work — the baseline 3 for high coverage.

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

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

States a specific verb and resource (get the authenticated user's profile) and enumerates the exact fields returned (name, email, phone, booking count, member-since), so an agent knows precisely what it gets. The closing note that payment method IDs are not exposed implicitly routes the agent to resy_list_payment_methods, giving real sibling differentiation.

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

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

Usage is implied rather than stated: use it when you need the current user's own profile. The 'payment method IDs are not exposed' line hints at the alternative sibling for that data, but there is no explicit when-to-use/when-not framing or prerequisite statement.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, externally-scoped read. The description adds almost nothing beyond that, only implying completeness via 'full details'. No auth, rate-limit, or response-shape context, but the annotation bar lowers expectations.

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

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

A single front-loaded sentence with zero filler; every word (verb, resource, scope, key) 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 single-parameter read tool whose annotations already cover the safety profile, this is nearly sufficient. The one minor gap is that 'full details' is undefined, but with no output schema required, it is acceptable.

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 carry the parameter burden. 'by id' signals that the sole parameter identifies a venue, which maps to venue_id, but no format, valid-range, or example detail is added. Minimal compensation 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?

States a specific verb (Get) and resource (full details for a single Resy venue), scoped to a single entity rather than a list. The word 'single' implicitly distinguishes it from resy_search_venues, but it never names the sibling explicitly. Clear purpose without strong sibling differentiation.

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

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

The phrase 'by id' implies this tool is for a venue you already have an identifier for, contrasting with search. However, there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is only implied.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no auth requirement, no pagination or result-count behavior, and no indication whether results are ordered or capped. It restates the resource the annotations and name already imply.

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, front-loaded sentence with zero waste. The essential verb, resource, and domain alias are all packed into the first clause.

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 full annotation coverage and fully documented parameters, the description is adequate. However, with no output schema, it says nothing about the shape or size of the returned list (e.g., whether it is paginated or includes venue metadata), leaving a modest gap an agent would notice when consuming the result.

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

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

Schema description coverage is 100% and the single view parameter is documented in exhaustive detail (compact vs full, field stripping, no field projection). With the schema carrying this burden, the baseline of 3 applies; the description contributes no additional parameter 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?

States a specific verb and resource: "List the user's favorited Resy venues", with the "hit list" alias clarifying the domain term. It is naturally distinct from resy_add_favorite and resy_remove_favorite by verb, but the description never explicitly differentiates itself from siblings such as resy_get_profile or resy_search_venues, which could conceivably surface favorite data.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative. The agent must infer from the name alone that this is the right call for retrieving favorites rather than searching (resy_search_venues) or reading the profile (resy_get_profile).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful conceptual meaning of a "Priority Notify subscription," but says nothing beyond that about pagination, result counts, or whether the list can be empty or stale.

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

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

A single front-loaded sentence; the verb and resource come first and the clarifying gloss follows. Nothing is padded or repeated.

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

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

For a read-only, zero-required-parameter list tool with a fully documented schema, the definition is nearly sufficient. The only gap is that with no output schema, the description does not sketch the return shape (id, venue, party size, date), leaving the agent to guess what a subscription record contains.

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 single "view" enum is documented in exhaustive detail within the schema (compact vs full, field dropping). The description contributes nothing about the parameter, 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?

States a specific verb ("List") and resource ("Priority Notify subscriptions") and adds a domain gloss ("tables you are waiting for when reservations open up") that an agent unfamiliar with Resy's Notify feature needs. The List verb implicitly separates it from the sibling resy_add_notify/resy_remove_notify mutations.

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 usage (enumerate the caller's active notify subscriptions) but never says when to reach for it versus siblings like resy_list_reservations or resy_find_slots, nor states any prerequisites such as an authenticated profile. Usage must be inferred from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral value by disclosing the return shape (id, brand, last four digits, expiry, is_default) in the absence of an output schema. It does not mention auth requirements or pagination/result limits.

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

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

Two tight sentences, front-loaded with the purpose and followed by the return fields and the concrete consumer of the id. Every clause earns its place with no filler.

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

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

For a read-only list tool with no output schema, the description usefully enumerates the returned fields and links to resy_book, which is what an agent needs to act. It leaves minor gaps around pagination/result completeness and any auth prerequisites.

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 sole parameter (view) is fully documented in the schema with an enum and detailed compact/full semantics. The description adds nothing about the parameter, so the 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?

States a specific verb and resource ("List the user's saved payment methods on Resy") and even enumerates the returned fields, so an agent knows exactly what this produces. No sibling tool lists payment methods, so it is trivially distinguishable from the rest of the catalog.

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 draws the connection to the booking flow by noting the returned id can be passed as payment_method_id to resy_book, which tells the agent when this tool is useful. It stops short of an explicit when-to-use/when-not statement or any exclusion, but the workflow linkage is clear context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond that by disclosing what each result contains (resy_token, occasion, special_request, cancellability), which is important given there is no output schema. Pagination or result limits are still unstated, keeping it from a 5.

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 tight sentences, zero filler, with the default behavior front-loaded before the alternate scope values and the return-value note. 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?

With no output schema, the description carries the return-value burden and does so by naming the key fields, including the token needed for cancellation. Combined with the enum explanation and annotations, an agent has everything needed to call and use the result correctly.

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

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

Schema description coverage is 0% and the enum lists values without meaning. The description compensates fully: it explains the default (upcoming) and the effect of the other two enum values ("past" or "all" to broaden). This is exactly the meaning the schema lacks.

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

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

States a specific verb and resource ("List the user's Resy reservations") that immediately separates it from siblings like resy_list_favorites or resy_list_payment_methods. An agent can identify the operation without opening the schema.

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

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

Gives clear context for use: default behavior is upcoming reservations, and scope="past"/"all" broadens it. It also tells the agent the results carry the resy_token needed for resy_cancel, linking it to a downstream tool. It stops short of explicit when-not-to-use exclusions, so it lands at 4 rather than 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile (non-destructive mutation) is covered. The description adds no behavioral context of its own: nothing about idempotency, what happens if the venue is not currently a favorite, or auth requirements.

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, verb and resource front-loaded, with the identifying parameter stated at the end. Nothing extraneous and nothing that could be trimmed.

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, non-destructive favorites mutation with annotations covering the safety profile and no output schema, this is close to sufficient. It is missing the one piece an agent would want: behavior when the venue is not in the favorites list (error vs. no-op).

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% for the single parameter, so the description carries the burden: it names 'venue_id' but adds no format, source, or constraint detail beyond the property name. Naming the identifier mildly clarifies intent but does not compensate for the documentation 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?

States a specific verb+resource ('Remove a venue from the user's favorites') and a scope qualifier ('by venue_id'), which is enough to separate it from resy_add_favorite and resy_remove_notify. It does not explicitly name those siblings, so it stops short of a 5.

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 when-to-use guidance, no conditions, no alternatives named. The only hint is the implied inverse of resy_add_favorite, which the agent must infer from the name rather than the description.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: it discloses that the full subscription spec is resolved internally via resy_list_notify and that no other input is required, which changes how the agent invokes it. Auth requirements and invalid-id behavior remain undisclosed.

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 front-loaded sentences with no filler; the action and its identifying parameter lead. The trailing 'no other input needed' slightly restates the preceding clause about internal lookup, a minor 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 one-parameter mutation with no output schema, the description covers what the tool does and its input resolution, but says nothing about the outcome (confirmation, failure on an unknown notify_id), reversibility, or auth. Enough to call it, not enough to predict its result.

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

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

Schema description coverage is 0%, so the description must carry the load for the single parameter. It names notify_id and, usefully, implies its provenance (the id comes from resy_list_notify), but adds no format or constraint detail (the schema's positive-integer constraint is undocumented in prose). Adequate but thin for a 0%-coverage parameter.

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

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

States a specific verb and resource — 'Cancel a Priority Notify subscription by notify_id' — which is far more than a restatement of the name. It is distinguishable from resy_add_notify and resy_list_notify. It stops short of distinguishing itself from the generic resy_cancel sibling, so it is clear but not fully sibling-differentiated.

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 rather than stated: the agent can infer this is the tool for cancelling an existing notify subscription, and the note that the spec is fetched from resy_list_notify hints at workflow. There is no explicit when-to-use/when-not guidance and no clarification of how this differs from resy_cancel.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value by disclosing the return payload (venues + bookable slot tokens) and the geo default, but says nothing about pagination, result caps, rate limits, or auth needs, and there is no output schema to fill that gap.

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

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

Two tight sentences, front-loaded with the core purpose and followed by the return/geo behavior. 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 an 8-parameter search tool with no output schema and full schema param coverage, the description is close to complete: it names the tool's purpose, return content, and default geo. It could cross-reference resy_book/find_slots for using the returned slot tokens, which is the only notable omission.

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 echoes the lat/lng NYC default and implies date+party_size drive slot eligibility, but adds no syntax or format detail beyond what the schema already states.

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

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

States a specific verb+resource (search venues) and scope (restaurants with availability), and clarifies that results carry bookable slot tokens for the given date+party_size. This implicitly distinguishes it from resy_get_venue (single venue) and resy_find_slots, though it never names a sibling.

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 one useful usage detail (defaults to NYC geo when lat/lng omitted) but never states when to choose this over resy_find_slots or resy_get_venue, nor any preconditions or exclusions. Usage must be inferred from the mention of availability and slot tokens.

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