Rezdy Agent MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions in the Rezdy booking system. The tools are well-organized around core workflows like booking management (create, get, update, cancel, quote), customer operations (create, get, search), and marketplace exploration (products, categories, suppliers, locations), with no overlapping functionality that would cause confusion.
Naming Consistency5/5
All tools follow a perfectly consistent naming pattern: 'rezdy_agent_' prefix followed by a verb_noun structure (e.g., create_booking, get_customer, search_products). This uniformity makes the tool set predictable and easy for an agent to navigate, with no deviations in style or convention.
Tool Count5/5
With 16 tools, the server is well-scoped for its purpose of managing bookings, customers, and marketplace data in Rezdy. Each tool earns its place by covering essential operations without redundancy, such as CRUD for bookings and customers, plus search and retrieval functions for products and related resources, making the count appropriate for the domain.
Completeness5/5
The tool set provides complete coverage for the Rezdy booking domain, including full CRUD lifecycle for bookings (create, get, update, cancel, quote) and customers (create, get, search), plus comprehensive marketplace exploration (products, categories, suppliers, locations, availability). There are no obvious gaps, ensuring agents can handle end-to-end workflows without dead ends.
Average 2.9/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It does not specify whether searches are case-insensitive, support wildcards, perform partial matching, or how pagination behaves with the limit/offset parameters. Mutation risks and rate limits are also absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a 4-word fragment ('Search agent customer database') that is technically concise but suffers from underspecification. It lacks sentences entirely and front-loads nothing of value regarding behavioral constraints or sibling differentiation.
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?
For a search tool with 6 optional parameters and no output schema, the description is inadequate. It omits critical search semantics (field matching logic, result ordering, maximum result sets) that the AI needs to formulate effective queries. Reliance on 100% schema coverage for basic parameter names is insufficient for a search operation.
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 description coverage is 100%, with all 6 parameters (limit, offset, email, firstName, lastName, phone) fully documented in the input schema. The description adds no additional parameter semantics (e.g., regex patterns, phone formats), so it earns the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb (search) and resource (customer database) but is vague regarding scope—'agent' is ambiguous (refers to the Rezdy Agent context, not the search target). Critically, it fails to distinguish from sibling 'rezdy_agent_get_customer', leaving the AI uncertain when to search versus retrieve by ID.
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 provided on when to use this tool versus alternatives like 'rezdy_agent_get_customer'. No prerequisites, search logic (AND vs OR), or filtering recommendations are mentioned. The description offers zero selection criteria.
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 carries full burden. It mentions 'confirmed' status but fails to disclose critical behavioral traits: payment processing implications (despite the paymentType enum), whether the operation is idempotent, error handling for unavailable inventory, or if notifications are sent. For an 11-parameter mutation operation, this is insufficient.
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 extremely concise (3 words) and front-loaded with the operative verb. While no words are wasted, the brevity is inappropriate for the tool's complexity (11 parameters with nested objects), resulting in under-specification rather than efficient communication.
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?
Given the tool's complexity (nested customer/participant objects, payment processing, 11 parameters), the absence of an output schema, and lack of annotations, the description provides inadequate context. It omits return value expectations, error scenarios, and business logic critical for a booking creation mutation.
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 description coverage is 100%, establishing a baseline of 3. The description adds no supplementary context about parameter semantics, validation rules, or relationships between nested objects (e.g., how quantities relate to productId), but meets the minimum given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic verb and resource ('Create a confirmed booking'), but is nearly tautological with the tool name 'rezdy_agent_create_booking'. It adds minimal value with the word 'confirmed' but fails to distinguish from siblings like 'rezdy_agent_quote_booking' (which likely creates provisional quotes vs confirmed bookings) or clarify the scope of 'confirmed'.
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 explicit guidance on when to use versus alternatives (e.g., when to use quote_booking instead), prerequisites, or preconditions. The word 'confirmed' provides only implicit contrast to the sibling quote tool but offers no actionable decision criteria.
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 carries the full burden of behavioral disclosure. It does not clarify that this is a safe, non-destructive read operation (unlike create/cancel siblings), whether quotes expire, or what the response structure contains (e.g., total price, breakdown, validity period).
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?
Extremely concise single sentence with no redundancy. However, for a tool with 8 parameters including nested objects (quantities array, customer object), this brevity is insufficient—the description is front-loaded but too short to support the complexity.
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?
Inadequate for the tool's complexity. With 8 parameters, nested structures, no output schema, and no annotations, the description should explain the quote workflow, parameter interdependencies (e.g., sessionId vs startTime), and the expected response. It currently provides only a label.
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?
With 100% schema description coverage, the structured data already documents all parameters. The description mentions 'pricing details' which loosely maps to the quantities/customer data needed for calculation, but adds no specific syntax guidance, example formats, or relationships between parameters (e.g., sessionId vs startTime). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action ('Get a quote') and resource ('booking'), and mentions 'pricing details' as the output focus. However, it fails to distinguish this from the sibling 'rezdy_agent_create_booking' tool—critical context since both likely accept similar parameters but have fundamentally different effects (pricing check vs. actual reservation).
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?
Provides no guidance on when to use this tool versus alternatives. Given the sibling 'create_booking' tool, the description should explicitly state this is for preliminary pricing only and does not reserve inventory, or direct users to use this before creating a booking.
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?
With no annotations, the description carries full burden but discloses nothing beyond the mutation type. It doesn't specify if updates are partial (PATCH-like) or full replacement, idempotency, side effects (notifications), or error handling for non-existent bookings.
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?
Extremely concise at four words with zero redundancy. Every word earns its place, though the brevity borders on under-specification given the tool's complexity with nested objects and six parameters.
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?
Inadequate for a tool with nested objects, multiple optional update fields, and no output schema or annotations. The description omits critical context like update semantics (partial vs full), return values, and which booking aspects are mutable.
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?
The schema has 100% description coverage, so the baseline is 3. The description adds no parameter-specific context (e.g., that bookingId likely comes from get_booking, or that only provided fields are updated), but the schema adequately documents individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action ('Update') and resource ('existing booking'), distinguishing it from create_booking. However, it fails to differentiate from cancel_booking or clarify what specific aspects can be modified, leaving the scope ambiguous.
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 provided on when to use this versus cancel_booking for cancellations, or prerequisites like obtaining the bookingId. The description 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Get' implies read-only, but description lacks details on pagination, rate limits, caching, or whether 'all' suggests heavy payload size. No disclosure of return structure.
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?
Extremely brief (4 words) as a single sentence. No wasted words, though brevity contributes to information gaps rather than efficiency.
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?
With no output schema and no annotations, the description provides insufficient context to distinguish this from similar location-adjacent tools (get_product_pickups, search_products). For a parameter-less tool, invocation is possible but selection guidance is inadequate.
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?
Zero parameters present, which per guidelines establishes a baseline of 4. No parameter explanation needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States basic verb and resource ('Get all marketplace locations') but fails to define what 'locations' refers to (cities, regions, venues?) or distinguish from sibling 'rezdy_agent_get_product_pickups', which could be confused as location-related.
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?
Provides no guidance on when to use this tool versus alternatives like 'get_product_pickups' or other search/get tools. No prerequisites or constraints mentioned.
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 carries the full burden. While 'Cancel' implies a destructive/mutating operation, the description fails to disclose whether cancellation is permanent, if it triggers automatic refunds, notifies customers, or requires specific permissions. For a destructive tool, this is a significant gap.
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 three words with zero redundancy. It is front-loaded and efficient. However, it may be overly terse given the tool's destructive nature and lack of supporting annotations, preventing a perfect score.
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?
For a destructive operation with no output schema and no annotations, the description is inadequate. It omits critical context about the consequences of cancellation, success/failure indicators, and side effects that an agent needs to safely invoke this tool.
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 description coverage is 100% (bookingId and reason are both documented). The description adds no additional parameter context (e.g., format expectations for bookingId, whether reason is mandatory for audit trails), which warrants the baseline score of 3 when the schema is comprehensive.
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 uses a specific verb ('Cancel') and resource ('booking') that clearly distinguishes this from siblings like create_booking, update_booking, and get_booking. However, it doesn't specify the domain (Rezdy) or scope details that would make it a 5.
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 provided on when to use cancellation versus modification (update_booking), prerequisites (e.g., checking booking status first), or business rules (e.g., cancellation windows). The agent receives no signal about appropriate usage contexts.
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, yet the description fails to disclose behavioral traits: it does not state whether this validates the API key, persists credentials for subsequent calls, is idempotent, or what error conditions to expect. The phrase 'Configure... connection' implies statefulness without explaining the state management contract.
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?
Single sentence of nine words with no redundancy. While appropriately sized, it is information-poor; the conciseness reflects under-specification rather than efficient delivery of necessary context.
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?
Lacking both output schema and annotations, the description omits critical context for a configuration tool: return value structure, success/failure indicators, and side effects on subsequent tool invocations. It does not fulfill the descriptive burden for an initialization operation with no output schema.
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?
Input schema has 100% description coverage ('Rezdy Agent API key', 'API environment'). The description merely echoes these concepts ('with API key and environment') without adding semantic context—such as where to obtain the key, that environment defaults to production, or that staging is for testing. Baseline 3 is appropriate when schema carries the full load.
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?
States a specific verb ('Configure') and resource ('Rezdy Agent API connection'), clearly distinguishing from operational siblings like 'create_booking' or 'get_product'. However, 'connection' is slightly abstract—it could specify whether this establishes authentication credentials or initializes a client session.
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?
Provides no guidance on when to invoke this tool versus alternatives, nor does it state that this is likely a prerequisite that must be called before other rezdy_agent_* operations. For a configuration/initialization tool, explicit sequencing guidance is critical but absent.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a write operation via 'Create' but fails to disclose idempotency, uniqueness constraints (e.g., email duplicates), return values, or error handling behavior.
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 extremely concise at four words with zero redundancy. It is front-loaded with the essential verb and resource, though its brevity arguably under-serves the tool's complexity (8 parameters, nested objects).
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?
Given the presence of 8 parameters (including a nested address object), 3 required fields, and no output schema or annotations, the description is insufficiently complete. It omits return value structure, side effects, and the significance of required versus optional fields.
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?
The input schema has 100% description coverage, documenting all 8 parameters including nested address fields. The description adds no parameter-specific context, meeting the baseline score for high-coverage schemas where the structured data already suffices.
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 core action ('Create') and resource ('customer profile'), providing a grammatical sentence that expands slightly on the tool name. While it lacks the field-level detail of the 'update_drive' example, it unambiguously identifies 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.
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 siblings like 'rezdy_agent_search_customers' or 'rezdy_agent_get_customer'. It does not mention prerequisites (e.g., checking for existing customers) or exclusion criteria.
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 must carry the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not specify error handling (e.g., booking not found), rate limits, caching behavior, or data sensitivity concerns.
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 single sentence is efficient and front-loaded with no wasted words. However, given the absence of annotations and output schema, the extreme brevity leaves critical gaps in behavioral and return-value documentation.
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 single-parameter retrieval tool, the description provides the minimum viable context. However, without an output schema, it should ideally characterize what 'details' are returned (e.g., customer info, status, product details) to be fully 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?
With 100% schema description coverage, the schema already fully documents the bookingId parameter. The description adds no additional parameter semantics (e.g., ID format, where to obtain it), warranting the baseline score of 3.
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 uses a clear verb ('Get') and resource ('booking'), and the word 'specific' implies a single-record lookup distinguishing it from search operations. However, it does not explicitly differentiate from sibling tools like update_booking or create_booking.
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 (e.g., when to use get_booking vs search_availability) and does not mention prerequisites like needing a valid booking ID from prior operations.
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 provided, so description carries full burden. Fails to disclose whether this is read-only, what specific details are returned, error conditions, or rate limits.
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?
Extremely concise at four words, with no redundant information. However, brevity limits informational value given missing annotations and output schema.
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?
Lacks output schema and annotations, yet description provides no hint about return structure or data scope. For a retrieval tool, 'details' is vague and unhelpful.
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 coverage is 100% (customerId is documented). Description adds no additional parameter guidance, meeting baseline for high-coverage schemas.
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?
Clear verb 'Get' and resource 'customer'. Mention of 'specific customer' implicitly distinguishes from sibling 'search_customers' for finding customers by criteria rather than retrieving by ID.
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 explicit when-to-use guidance, no mention of when to use this versus 'search_customers', and no prerequisites stated despite requiring a customer ID.
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 provided, so description carries full burden. While 'Get' implies read-only, the description fails to disclose what 'detailed information' includes, error handling for invalid IDs, rate limits, or authentication requirements.
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?
Single sentence, front-loaded with verb, no redundancy. However, given zero annotations and no output schema, the extreme brevity leaves critical behavioral context undocumented.
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 single-parameter getter with complete schema coverage, the description meets minimum viability. However, lacking annotations and output schema, it should explicitly state this is a safe read operation and clarify the relationship to search tools.
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 coverage is 100% with 'productId' fully documented. The description adds domain context ('marketplace product') aligning with the parameter, but does not add syntax details, ID format requirements, or examples beyond what the schema provides.
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 uses specific verb 'Get' and resource 'marketplace product'. The word 'specific' effectively distinguishes this from sibling 'search_products', clarifying this retrieves one item by ID rather than filtering many.
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 provided on when to use this versus the sibling 'search_products' tool. Missing explicit instruction that this requires an exact product ID while search_products is for discovery/filtering.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to state whether this is a read-only operation, what data structure is returned, or error behaviors (e.g., what happens if the product has no pickup locations). The word 'Get' implies retrieval but lacks explicit safety guarantees or behavioral context.
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 7-word sentence with no filler. It is front-loaded with the action verb. However, it borders on under-specification—while efficient, it lacks the structural richness (scoping details, format hints) that would make it maximally useful without being verbose.
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 tool with one simple parameter and no output schema, the description is minimally adequate. However, given the existence of sibling `get_locations`, it lacks contextual completeness by not clarifying the relationship between pickup locations and general locations, and omits return value description since no output schema exists to compensate.
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?
The input schema has 100% description coverage for its single parameter ('Product ID'), establishing a baseline of 3. The description mentions 'for a specific product' which loosely maps to the productId parameter, but adds no additional semantic context like 'the numeric ID obtained from search_products' or format details beyond the schema.
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 uses a clear verb ('Get') and specific resource ('pickup locations'), and scopes it to 'a specific product' which distinguishes it from sibling tool `get_locations`. However, it uses the generic verb 'Get' rather than 'Retrieve' or 'List', and doesn't explicitly contrast with `get_product`.
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 like `get_locations` or `get_product`, nor does it mention prerequisites (e.g., needing a valid product ID from `search_products` first). It implies usage by mentioning 'specific product' but offers no explicit when/when-not guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides almost none. It does not confirm this is a read-only operation, describe the return format (list of products), explain pagination behavior (despite limit/offset parameters), or mention any rate limiting or performance characteristics.
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 single sentence is efficiently constructed and front-loaded with the action verb. While extremely brief, it contains no redundant words. However, given the high complexity (13 parameters, no output schema), it arguably errs on the side of under-specification rather than optimal 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?
For a tool with 13 parameters and no output schema or annotations, the description is inadequate. It fails to describe what data structure is returned, does not clarify that this queries a catalog rather than availability/bookings, and omits pagination guidance despite having pagination parameters.
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 description coverage is 100%, so the schema adequately documents all 13 parameters. The description adds only the context 'from all suppliers' which subtly hints at the supplierId filter purpose, but provides no guidance on parameter interactions, query logic (AND vs OR), or recommended pagination defaults.
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 provides a clear verb ('Search') and resource ('marketplace products'), and the phrase 'from all suppliers' establishes scope. However, it does not explicitly distinguish from the sibling 'rezdy_agent_get_product' (single retrieval by ID vs. search/filtering) or clarify when to use this versus 'rezdy_agent_search_availability'.
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?
There is no explicit guidance on when to use this tool versus alternatives like 'get_product' or 'search_availability'. It does not mention that all parameters are optional (0 required) or suggest typical query patterns for the 13 available filters.
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 provided, so description carries full burden. While 'Search' implies read-only, the description fails to disclose pagination behavior, rate limits, whether sessions are real-time, or what the return structure contains. Only behavioral hint is 'with pricing', indicating price calculation occurs.
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?
Single sentence efficiently conveys core purpose without redundancy. Front-loaded with action verb and no filler text.
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?
Adequate for a 6-parameter search tool with complete schema coverage, but gaps exist due to missing output schema and zero annotations. Description should ideally explain return values or response structure given no output_schema exists.
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 description coverage is 100%, so parameters are fully documented in structured fields. The description adds minimal semantic value beyond the schema, only hinting at the 'quantities' parameter purpose via 'with pricing'. Baseline score appropriate for high-coverage schema.
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 uses specific verb 'Search' with clear resource 'availability sessions' and scope 'for a product with pricing'. It distinguishes from sibling 'search_products' by focusing on availability sessions rather than product catalogs, though it could further clarify what constitutes an availability session.
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?
Description provides no guidance on when to use this tool versus alternatives like 'get_product' or 'quote_booking'. No mention of prerequisites (e.g., obtaining productId first) or when not to use it.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates 'Get all' (full list retrieval) but fails to mention if this is a safe read-only operation, whether pagination applies, or what structure the returned categories take.
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 5-word sentence that is front-loaded with the action verb. There is no redundant or extraneous text; every word serves a purpose in defining the tool's scope.
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?
While adequate for a simple parameter-less tool, the description lacks indication of return values or data structure (e.g., category IDs and names) given the absence of an output schema. It meets minimum viability but leaves operational gaps.
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?
The input schema contains zero parameters, which establishes a baseline score of 4. No parameter description is needed in the description text since there are none to document.
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 verb 'Get' and resource 'marketplace product categories', distinguishing it from sibling tools like get_product or get_locations. However, it lacks explicit workflow context (e.g., 'use before search_products to filter results').
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 provided on when to use this versus alternatives like search_products, or how it fits into the booking workflow (e.g., browsing categories before searching). The description states what it does but not when an agent should invoke it.
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 provided, so description carries full burden. 'Get' implies read-only, but description doesn't confirm safety, pagination behavior for 'all' results, rate limits, or return structure. 'All' suggests unfiltered retrieval without mentioning performance implications or result set limits.
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?
Four words, zero waste. Single sentence front-loaded with action and target. No redundancy or filler content.
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?
Adequate for a zero-parameter tool, but 'get all' operations typically require pagination or limit documentation which is absent. No output schema means return structure should be described but isn't. Sufficient to identify the tool's basic function but lacks operational context.
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?
Zero parameters present with empty input schema. Per scoring rules, baseline is 4 for tools with no parameters. Description implies no filtering is possible (consistent with 'get all'), which matches the empty schema.
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?
Clear verb ('Get') + resource ('marketplace suppliers') with explicit scope ('all'). Distinguishes from siblings like get_product, get_customer, and get_categories by targeting suppliers specifically. Lacks detail on what constitutes a 'marketplace supplier' in this context.
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 versus alternatives (e.g., whether suppliers are returned via search_products or if this is the only supplier endpoint). No mention of prerequisites, permissions, or when not to use the tool.
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:

[![rezdy-agent-mcp MCP server](https://glama.ai/mcp/servers/jezweb/rezdy-agent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jezweb/rezdy-agent-mcp)

Score Badge

Copy to your README.md:

[![rezdy-agent-mcp MCP server](https://glama.ai/mcp/servers/jezweb/rezdy-agent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jezweb/rezdy-agent-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/jezweb/rezdy-agent-mcp'

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