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

With no annotations provided, the description carries the full burden. It explicitly states 'Read-only,' a key behavioral trait, and discloses data source behavior (Google Places vs Yelp) and attribute richness (goodForChildren, outdoorSeating, servesCocktails). It does not mention rate limits or output details, but the read-only nature is well covered.

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, front-loaded with the core purpose, includes a relevant example and backend context. Zero wasted words, ideal length and structure.

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 primary use case and notes the data sources, but with 7 parameters and no output schema, it lacks details on return format, pagination, or behavior when no API keys are configured. It is functional but has notable gaps for a tool of this complexity.

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

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

Schema description coverage is 57% (4 of 7 params described). The description adds meaning by mentioning the query example and Google Places attributes that map to boolean filters (e.g., 'outdoor seating' relates to outdoorSeating parameter), but it does not clarify openNow, latitude, or longitude beyond the schema. It partially compensates but leaves gaps.

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 tool 'finds restaurants by free-text criteria' with a concrete example, using a specific verb and resource. It distinguishes itself from sibling tools (resy_search, resy_booking, etc.) which are reservation/booking focused, making this the discovery tool.

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 for free-text restaurant discovery and notes it uses Google Places/Yelp depending on API keys, giving context. It does not explicitly name alternatives or exclusions, but the sibling tools are clearly different, so the usage context is clear enough.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose that each slot includes a bookToken, which is useful output context, but it omits whether the tool is read-only, requires authentication, or has rate limits or pagination. For a listing tool, this is acceptable but incomplete.

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, concise sentence that front-loads the action and includes a critical detail about the output (bookToken). Every word contributes to understanding 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?

Given the tool has 5 parameters, no output schema, and no annotations, the description is only somewhat complete. It explains the core purpose and the bookToken output, but does not describe the full return structure (e.g., time, venue info) or the optional latitude/longitude parameters. This makes it partially insufficient for a complex tool.

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

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

Schema description coverage is only 40% (venueId and date have descriptions), and the description does not compensate for the undocumented latitude, longitude, or partySize parameters. It only mentions 'date' and 'party size' generically without adding syntax or formatting details beyond what the schema already provides.

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 it lists available reservation slots for a Resy venue on a specific date for a party size. It also mentions the bookToken included in each slot, which is used by resy_booking_preview, effectively distinguishing it from sibling tools like resy_search and 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?

The description implies a usage flow: after finding a venue via resy_search, use this tool to get slots, then pass the bookToken to resy_booking_preview. It does not explicitly state exclusions or alternatives, but the workflow is clear enough from the mention of resy_booking_preview.

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?

There are no annotations, so the description carries the behavioral transparency burden. It explicitly warns 'IRREVERSIBLE' and mentions potential cancellation/no-show fees, disclosing destructive consequences. However, it does not describe the response format or any post-booking effects, which would be useful for full transparency.

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, information-dense sentence with a front-loaded warning ('IRREVERSIBLE'). Every clause adds value: the step indicator, the booking action, the token source, the confirm requirement, and the fee warning. No unnecessary 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?

Given the multi-step booking flow and lack of annotations, the description provides sufficient context for a booking step: it clarifies prerequisites (book_token from preview), required confirmation, and a key consequence (fees). It stops short of detailing the success response or error conditions, but the sibling tools fill some 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 schema already describes all parameters with 100% coverage, including the confirm must-true rule and the book_token source. The description repeats the confirm requirement but adds no new parameter-level semantics, so it meets the baseline for good schema 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?

The description clearly states the tool's function: it books a reservation using a book_token from resy_booking_preview. The phrase 'STEP 2 of booking — IRREVERSIBLE' provides a specific verb, resource, and key characteristic, distinguishing it from preview or search 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 explicitly identifies its position in the booking workflow ('STEP 2') and specifies that the book_token must come from resy_booking_preview. It also states the confirm requirement, giving clear usage context. While it doesn't enumerate alternatives, the sequencing makes the intended use unambiguous.

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

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

With no annotations, the description carries the full burden. It discloses the non-destructive nature ('Does NOT book') and what it surfaces (time, seating, fees, token). However, it omits details like authentication requirements or error behaviors, which would make it fully 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?

Two tightly packed sentences. The description is front-loaded with 'STEP 1 of booking' and every sentence adds value—purpose, non-destructive warning, and next-step guidance. No waste.

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 or annotations, but the description summarizes the expected return values (time, seating type, fees, token) and clarifies the workflow position. It lacks edge cases or prerequisites, but given the tool's simple preview nature, this is reasonably 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 coverage is only 67% (partySize lacks description), and the description does not compensate. It merely restates bookToken's schema description and does not explain partySize or add any semantic value beyond the schema. This leaves a gap in parameter understanding.

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 tool's purpose: it is STEP 1 of booking, resolves a slot bookToken, surfaces time/seating/fees, explicitly does NOT book, and returns a book_token for resy_book. This verb+resource combination distinguishes it from siblings like 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?

The description explicitly frames usage as 'STEP 1 of booking' and states 'Does NOT book. Returns a real book_token to pass to resy_book.' This provides clear sequential guidance and disambiguates from the resy_book sibling, satisfying when-to-use and 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?

With no annotations to rely on, the description fully discloses critical behavior: the token is stored locally (~/.config/reservations-mcp) and the password is used once and never saved. These security-relevant details go beyond what a schema could provide and are essential for trust.

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 long, front-loaded with the core action and result, and every sentence provides value (function, storage, password handling, and an alternative preference). 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?

For a simple login tool with no output schema and no annotations, the description covers key aspects: what it does, where the token is stored, and password safety. It does not explicitly state whether the token is returned as a response or how it is used by sibling tools, but given the simplicity, this is a minor gap.

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

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

Schema description coverage is 0%, so the description must compensate. It does mention 'email + password', which maps directly to the two parameters, but it does not provide any additional detail about format, constraints, or usage. This matches the baseline level of just naming the parameters.

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 (Exchange), the resource (Resy email + password), and the outcome (an auth token). It is easily distinguishable from sibling tools like resy_search or resy_book, which operate on other resources.

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 advises preferring an alternative (setting RESY_AUTH_TOKEN directly) over using this tool, providing a clear 'when not to use' signal. It does not explicitly state to use it before other Resy tools, but the context and sibling names imply this flow.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It clearly implies a read-only listing operation and personal scope ('your'), but it does not mention authentication requirements, potential empty results, or return format. For a simple list tool, this is minimally 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, front-loaded sentence that states exactly what the tool does without any fluff. 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?

Given the tool's simplicity (no parameters, no output schema) and the presence of sibling tools, the description is sufficient for an agent to understand its core function. It could optionally mention return format or prerequisites, but this is not critical for a straightforward list operation.

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 are zero parameters and schema coverage is 100%, so the description need not explain any parameter semantics. The description adds value by clarifying the scope ('upcoming'), which the empty schema cannot convey.

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 ('your upcoming Resy reservations'), clearly distinguishing this from sibling tools like resy_search or resy_book. The scope is explicit ('upcoming'), 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or any context for choosing this tool over resy_search or resy_availability. The usage is merely implied by the name and verb.

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

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

With no annotations, the description carries the full burden. It uses 'List' which implies a read-only operation and mentions account specificity, but it does not disclose authentication requirements, potential errors, or that it makes no modifications. For a simple list operation, 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, front-loaded sentence that conveys all necessary information without waste. Every part is meaningful: action, resource, scope, and use case.

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 parameterless list tool, the description covers what it does and why it's used. It doesn't detail return format or require explicit login, but those are minor gaps given the low complexity. It feels complete enough for an agent to decide when to invoke it.

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 provides no fields to describe. The description adds context by explaining the output's purpose (needed for bookings), which is extra value beyond the schema. Baseline 4 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 clarifies the exact resource ('payment method ids') and scope ('saved on your Resy account'), immediately distinguishing it from sibling tools that handle search, availability, or bookings. It also states the practical need ('for bookings that require a card'), reinforcing its purpose.

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 tells when to use the tool: when you need payment method IDs for bookings. It doesn't explicitly mention when not to use it or name alternatives, but given the sibling list, no direct alternative exists, so the context is clear enough.

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

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

With no annotations, the description carries the full burden. It does disclose an important behavioral trait: the search is limited to 'Resy's own venue index' and returns only venue IDs (not full restaurant details). However, it omits details like whether results are paginated, how latitude/longitude affect behavior, or the response structure. It is adequate for a simple search tool 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, tight sentence with no wasted words. It front-loads the core action and follows with the key output and purpose. It earns a perfect score for efficiency.

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

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

The tool is relatively simple: one required string and two optional numbers, no output schema, no annotations. The description explains the main purpose and output but leaves the optional parameters undefined and does not describe the return format beyond 'Resy venue ids.' Given the low schema coverage and lack of an output schema, a bit more detail would improve completeness, but it is minimally viable.

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 describes only the query parameter (33% coverage), and the description does not compensate for the missing latitude/longitude semantics. The description says 'by name/keyword,' reinforcing the query parameter, but latitude and longitude are left as bare numbers with no explanation of their role (e.g., disambiguation or location-based ranking). This is a notable gap given low schema 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?

The description uses a specific verb+resource combination: 'Search Resy's own venue index by name/keyword.' It clearly distinguishes this from sibling tools like tock_search (a different platform's index) and discover_restaurants (discovery rather than direct venue lookup). The explicit mention that it returns venue IDs needed for downstream actions completes the purpose.

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

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

The description implies a clear usage context: it is a precursor to availability and booking, saying 'Returns Resy venue ids needed for availability and booking.' This helps the agent select it before resy_availability or resy_book. It does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.

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

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

With no annotations, the description carries the burden of disclosing behavior. It explicitly states that it checks presence of API keys/tokens, which implies a read-only operation, but it does not disclose whether it verifies key validity, how errors are handled, or the exact output format. This is basic transparency but lacks depth.

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, grammatically complete sentence with no wasted words. It front-loads the verb and directly states the purpose. It is appropriately sized for a zero-parameter status-check tool.

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, no-output-schema tool, the description is sufficiently complete: it explains what is shown (configured providers) and qualifies what 'configured' means (presence of keys/tokens). It does not specify return format, but for a simple status tool this is not a critical gap, especially given the output schema absence.

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, and 100% schema coverage (trivially). Per the rubric, a zero-parameter tool receives a baseline score of 4, and the description needs no additional parameter semantics. It correctly focuses on the tool's behavior.

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 ('Show') and identifies the exact resource ('which providers are configured'), clearly distinguishing it from sibling tools that handle restaurant search, booking, payments, and account actions. It leaves no ambiguity about the tool's function.

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 relative to alternatives, such as 'use this to check configuration before making API calls' or 'use this if you need to verify provider keys are present.' There is no context about prerequisites or typical invocation scenarios.

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?

Without annotations, the description carries the full burden. It clearly discloses that the tool is a best-effort stub returning guidance and a link rather than live data, which is critical behavioral context beyond the basic search action.

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 one sentence plus a brief note, with no wasted words. The core purpose is front-loaded, and the note earns its place by conveying a key limitation.

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 stub tool, the description adequately covers purpose, output type, and limitation. However, it lacks any detail on acceptable input formats or what the direct link points to, leaving minor 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 0% and the description does not elaborate on what the 'query' parameter should contain. While the param name is self-explanatory, the description adds no meaning beyond the schema field name.

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 'Search Tock venues' with a specific verb and resource, and the 'Tock' scope clearly distinguishes it from Resy-focused sibling tools. The note about being a stub does not detract from purpose clarity.

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 Tock is the target and notes the stub limitation, but it does not explicitly state when to use this tool versus discover_restaurants or resy_search. No exclusions or alternative recommendations are provided, so guidance is only implied.

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