resy-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.3
Disambiguation5/5
Each tool targets a distinct resource and action: favorites, notify subscriptions, reservations, venues, payment methods, and profile. Even similar tools like `resy_search_venues` and `resy_find_slots` differ in purpose (venue discovery vs. slot listing for a specific venue), leaving no ambiguity.
Naming Consistency5/5
All tools follow a `resy_<verb>_<noun>` pattern in snake_case, with verbs like `add`, `list`, `remove`, `get`, `find`, `search`, `book`, and `cancel` consistently used. There are no mixed conventions or irregular names.
Tool Count5/5
With 14 tools, the set is well-scoped for a restaurant reservation service. It covers all major user actions without bloat, fitting comfortably within the ideal 3-15 range.
Completeness4/5
The tool surface covers core CRUD for favorites, notify subscriptions, and reservations (list, book, cancel), plus venue search and user profile. Missing operations like reservation modification or updating favorites are minor gaps that can be worked around.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 74 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotation's readOnlyHint. It does not disclose any traits such as whether the list is empty, pagination, or authorization requirements, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence without any unnecessary words. It is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, read-only), the description is adequate but could mention the return format (e.g., a list of venue objects) since there is no output schema. It does not fully compensate for the lack of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are no parameters and schema coverage is 100%, the description does not need to add parameter semantics. The baseline of 4 is appropriate as no additional meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'user's favorited Resy venues', including the colloquial term 'hit list' for clarity. It effectively distinguishes from sibling tools like resy_add_favorite and resy_remove_favorite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for viewing favorites but provides no explicit guidance on when to use versus alternatives like resy_search_venues or resy_get_venue. It lacks any 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by stating the tool returns 'venues including any bookable slot tokens', which implies read-only access to availability data. It does not contradict annotations and provides useful behavioral cues about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. The first sentence states the core purpose, the second adds return format and default behavior. Every word serves a purpose, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 7 parameters and no output schema, the description covers the main outcome (venues with slot tokens), required inputs (date, party_size), and default geo. It does not detail optional parameters like limit or radius_meters, but the schema handles those. Minor gap: no guidance on when to use this over resy_find_slots, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description adds value by explaining default geo behavior for lat/lng ('Defaults to NYC geo') and clarifying that date and party_size determine the slot tokens returned, enhancing parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and resource 'Resy for restaurants with availability', distinguishing it from sibling tools like resy_find_slots (which operates on a specific venue) and resy_get_venue (which retrieves details). The mention of returning 'bookable slot tokens' specifies a unique output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like resy_find_slots or resy_get_venue. While the purpose indirectly suggests it for initial venue search, the lack of explicit 'when/when-not' guidance limits its value for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds semantic context (what the subscriptions represent) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description fully explains what the tool does and the meaning of the listed items. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description need not add parameter details. It provides context about the returned data (subscriptions for tables waiting for reservations) that helps the agent understand the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('Priority Notify subscriptions'), and clarifies the purpose with an appositive phrase. It clearly distinguishes from sibling tools like resy_add_notify 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing waiting-list subscriptions but does not explicitly state when to use this tool over siblings like resy_list_favorites. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by specifying that payment method IDs are not exposed. This discloses a behavioral limitation not evident from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first describes the action and returned fields, the second adds a caveat. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description enumerates the key fields returned and notes an omission (payment IDs). This is sufficient for a simple profile retrieval, though mention of authentication requirements could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so the description need not add parameter info. It gains full marks for zero overhead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the authenticated user's profile and lists specific fields (name, email, phone, booking count, member-since). This distinguishes it from sibling tools that handle payments, venues, reservations, and favorites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Although no explicit when-to-use or alternatives are given, the purpose is self-evident from the tool name and description. The sibling context further clarifies its distinct role, but a usage note would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds specifics on return values (id, brand, etc.) and hints at integration with resy_book. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with purpose, then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no parameters and no output schema, the description fully covers what to expect and how to use the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema, so schema coverage is 100%. The description adds value by explaining return values, earning a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'user's saved payment methods', clearly distinguishing it from sibling tools like resy_book or resy_list_reservations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the return fields and notes that the id can be passed to resy_book, providing a clear use case. Lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![resy-mcp MCP server](https://glama.ai/mcp/servers/chrischall/resy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/resy-mcp)

Score Badge

Copy to your README.md:

[![resy-mcp MCP server](https://glama.ai/mcp/servers/chrischall/resy-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/resy-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/resy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server