Gondola AI

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action on a specific resource (hotels, flights, vehicles, loyalty, profiles, etc.) with no significant overlap. For example, search_hotels, get_hotel_details, compare_rates, book_hotel, predict_price, and get_hotel_stats all have clearly differentiated purposes.
Naming Consistency4/5
The vast majority of tools follow a consistent verb_noun snake_case pattern (e.g., search_hotels, book_vehicle, get_loyalty_accounts). Minor deviations include 'credit_card_coverage' (missing verb) and 'optimize_loyalty_portfolio' (uses 'optimize' instead of get/search).
Tool Count4/5
With 34 tools, the count is high but still appropriate for the broad travel domain covering hotels, flights, vehicles, loyalty programs, and user profiles. Each tool serves a specific function, though some consolidation (e.g., unifying booking links) could reduce the count slightly.
Completeness3/5
The tool set covers most core workflows for hotels and vehicles, including search, details, booking, and management. However, there are notable gaps: no flight booking tool (only search), no hotel cancellation tool, and no direct flight details or alerts.
Average 4.4/5 across 34 of 34 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 3 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on July 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 6 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context beyond stating it returns coverage details or an error. It does not mention any side effects, prerequisites, or response format details.
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 with two sentences plus Args/Returns. It front-loads the purpose without any redundant or extraneous text.
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?
With an output schema (not shown) and only one required parameter, the description sufficiently covers the tool's function. It mentions coverage details and errors, which is adequate for a simple read-only retrieval 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?
The description explains that booking_id is a 'Gondola booking ID of the vehicle booking', adding clarity beyond the schema's simple type and title. Schema coverage is 0%, so this parameter information is valuable.
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 rental car CDW/LDW coverage for a vehicle booking, using specific terms. It distinguishes from siblings like get_vehicle_booking and credit_card_coverage.
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 provide explicit guidance on when to use this tool versus alternatives like credit_card_coverage. It only states what it does, not when 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the action of cancelling but provides no additional behavioral details like refunds or side effects. It partially adds value by specifying the parameter but does not deeply expand on 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 brief and front-loaded, with the purpose in the first sentence, followed by clear parameter and return sections. It avoids fluff but includes standard headers that could be trimmed.
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 simple 1-parameter tool with an output schema, the description covers the essential: what it does, the input parameter, and that it returns a result. It does not explain the return structure, but the output schema covers that. Overall, it is adequately complete.
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 0%, so the description compensates by explaining booking_id as 'The Gondola booking ID (confirmation number) of the vehicle booking.' This adds meaningful context beyond the schema's type and title.
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 an existing vehicle booking," with a specific verb and resource. It distinguishes from sibling tools like book_vehicle, get_vehicle_booking, etc.
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 usage is implied (use when you need to cancel), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites mentioned.
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 and destructiveHint=false. The description adds context about output (per-supplier status, rate breakdown) but does not disclose potential behavioral traits like data freshness, error handling, or rate limits. With annotations covering safety, a 3 is appropriate for lack of additional behavioral depth.
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 relatively concise, with a clear first sentence stating purpose followed by a structured Args section. Some redundancy exists (e.g., 'e.g.' examples), but overall it is efficient and well-organized.
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 moderate complexity and an existing output schema (not shown), the description adequately explains inputs and output content. It lacks details about error scenarios or pagination, but the combination with annotations and output schema makes it sufficiently complete.
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 must compensate. It fully describes each parameter: hotel_id (type), checkin/checkout (format), num_adults (default), and rate_sources (optional, with comma-separated examples). This adds significant meaning beyond the raw 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 tool's purpose: 'Diagnose rate availability and source statuses for a specific hotel.' It explains the use case ('investigate why certain rates are or aren't showing') and distinguishes from siblings like compare_rates or get_multi_night_rates by focusing on diagnostic breakdown per supplier.
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 guides usage by stating 'Use this to investigate why certain rates... are or aren't showing.' However, it does not explicitly mention when not to use or provide alternatives among siblings. The guidance is present but not comprehensive.
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 and destructiveHint=false. Description does not add significant behavioral context beyond stating it returns a list. It is consistent with annotations, but the bar is lower due to annotations covering safety profile.
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 concise and well-structured: one-line purpose, usage guidance, then args and returns. Every sentence serves a purpose with no extraneous text.
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 and presence of an output schema (mentioned in context), the description covers the key aspects: purpose, usage, parameters, and return type. No major gaps.
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 descriptions are absent (0% coverage). The description provides brief but helpful explanations for each parameter, e.g., 'The hotel's Vervotech property ID (from search results)' and 'Check-in date in YYYY-MM-DD format.' This adds value but is minimal.
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 title 'Get similar hotels' and first sentence 'Find hotels similar to one the user is looking at' clearly state the verb and resource. It distinguishes from siblings like search_hotels, get_hotel_details, and compare_rates.
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 says 'Use this when a user wants alternatives, comparisons, or asks show me hotels like this one.' Provides clear context but does not mention 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 declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns a list of vehicles with rates and details, which provides additional context about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is briefly structured with args listed and a return statement. It is front-loaded with purpose. Could be slightly more concise, but no wasted sentences.
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?
Given the 4 parameters, no nested objects, and presence of an output schema, the description covers all necessary aspects: purpose, parameter semantics, and return format. It is complete for an agent to use the tool.
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?
With 0% schema description coverage, the description fully explains each parameter: pickup_location as 'Airport IATA code' with examples, datetime fields in ISO format, and vehicle_class with a list of options. This adds significant value beyond the schema structure.
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 'Search for rental vehicles at an airport or city' with a specific verb and resource. It is distinct from sibling tools like get_vehicle_details or book_vehicle, but does not explicitly differentiate itself.
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 searching available vehicles with location and dates. It provides examples for pickup location (IATA codes) but does not explicitly state when to use this tool vs. alternatives like get_vehicle_details or other search 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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by explaining the return content (dates, confirmations, costs, etc.) and the possibility of returning instructions to connect an account, which goes beyond the annotations.
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 structured in three paragraphs: first states purpose, second lists return contents, third mentions prerequisite. It is clear and not overly verbose, though slightly wordier than necessary.
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?
Given there are no parameters and an output schema exists, the description covers the purpose, return format, and prerequisites adequately. It is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema coverage, the baseline is high. The description does not need to elaborate on parameters and does not add anything misleading. A score of 4 is appropriate.
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 tool gets upcoming trips including hotels, flights, and car rentals. It distinguishes from sibling tools like get_past_trips by specifying 'upcoming' and lists the types of reservations included.
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 mentions a prerequisite ('Requires a Gondola account (API key)') but does not explicitly state when to use this tool over siblings or when not to use it. Usage context is implied 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?
Annotations already indicate destructiveHint=true, so the destructive nature is known. The description adds that it requires authentication and returns a confirmation, but does not elaborate on side effects like irreversibility. With annotations covering the primary behavioral trait, the description adds moderate value.
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 very concise: one sentence for purpose, one for requirement, then structured Args/Returns. Every sentence is meaningful and no wasted words.
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?
Given the tool's simplicity (one parameter, no nested objects, output schema present), the description covers all necessary details: purpose, prerequisites, argument source, and return value. It is fully adequate for an agent to use the tool correctly.
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 only parameter, alert_id, has no description in the schema (0% coverage). The description adds value by specifying 'from get_rate_alerts', telling the agent how to obtain the ID. This goes beyond the schema's bare type information.
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 'Delete' and the resource 'rate alert', and explains the purpose 'so you stop monitoring a hotel for price drops'. This effectively distinguishes it from sibling tools like create_rate_alert and get_rate_alerts.
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 specifies a prerequisite ('Requires a Gondola account with an API key'), which helps the agent determine if it can use the tool. However, no explicit guidance on when not to use or alternatives are provided, though the context of deletion is clear from the verb.
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 indicate readOnlyHint=true. The description adds useful behavioral details: what each certificate includes (program, count, coverage, expiry, top-up) and that it returns a formatted list or instructions. It also requires an API key.
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 sentences, no redundant words. The most important information (action and resource) is front-loaded. Every sentence adds value.
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?
With no parameters, an output schema available, and annotations providing safety profile, the description covers purpose, prerequisites, return details, and even potential alternative outcomes ('instructions to connect'). No 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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, but it is not needed. Baseline of 4 is appropriate given no burden.
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') and the resource ('free night certificates across loyalty programs'). It distinguishes from sibling tools like 'get_loyalty_accounts' by specifying certificates instead of general accounts.
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 mentions a prerequisite ('Requires a Gondola account (API key)') but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives are named.
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 and destructiveHint=false, so the agent knows it's a safe read. The description adds context about the output: 'Shows cash rates, points rates, and value percentiles for each available check-in date,' which goes beyond annotations. 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 moderately long but well-structured: first line states purpose, followed by usage guideline, output summary, and parameter list. It is front-loaded and every sentence adds value. No unnecessary fluff.
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 4 parameters and an existing output schema, the description covers purpose, usage, parameter semantics, and return summary. It does not mention pagination or behavior for unavailable dates, but overall it provides sufficient context for correct tool 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 description coverage is 0%, meaning property descriptions are missing in the schema. However, the description compensates by explaining each parameter: hotel_id is from search results, date formats, and nights default. This adds meaning beyond the schema titles, though some details like date format are assumed.
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 tool retrieves a rate calendar showing prices across a date range for a hotel. The verb 'get' and resource 'rate calendar' are specific, and it distinguishes itself from siblings like compare_rates (which compares multiple hotels) and predict_price (which predicts future prices).
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 explicitly says 'Use this when a user has flexible dates and wants to find the cheapest time to stay.' This provides clear context for when to use the tool. It does not directly name alternatives but implies that for fixed dates other tools might be used; overall guidance is solid.
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 and destructiveHint=false. The description adds value by specifying return structure (list of rate alerts with hotel names, dates, current rates) and noting API key requirement, which enhances transparency beyond 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 three sentences plus a Returns line, efficiently front-loaded with the main purpose. Every sentence adds value without waste.
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?
Given low complexity (no parameters, read-only), existing annotations, and an output schema, the description adequately covers the tool's behavior, specifying return fields and prerequisites.
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 exist, and schema coverage is 100%. With zero parameters, the description cannot add meaning beyond what the schema provides, earning a baseline of 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 clearly states the tool gets active rate alerts for the current user, specifically for monitoring hotel price drops. This verb+resource combination is distinct from sibling tools like create_rate_alert and delete_rate_alert.
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 retrieving the user's rate alerts but does not explicitly state when to use this tool versus alternatives like create_rate_alert or delete_rate_alert. It mentions a prerequisite (requires Gondola account with API key) but lacks guidance on selection.
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 annotations (readOnlyHint=true, destructiveHint=false), the description adds behavioral context: returns results based on preferences, recent searches, popular destinations, and upcoming holidays. This helps the agent understand the personalization logic.
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?
Three sentences plus a concise return description. Front-loaded with purpose. Every sentence earns its place. Could be slightly shortened, but no waste.
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 zero parameters and good annotations, the description covers purpose, usage context, and return value. No obvious gaps. An output schema exists, so return details are likely handled there.
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 0 parameters and 100% schema coverage, the baseline is 4. The description adds value by explaining that results are influenced by user context and popular trends, which is not captured in the empty 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 explicitly states it provides 'personalized travel suggestions and trip inspiration' and 'curated hotel recommendations'. It clearly distinguishes from sibling tools like search_hotels or get_hotel_details by focusing on suggestion-based discovery.
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?
Directly states when to use: 'Great for when the user doesn't know where to go.' While it doesn't list exclusions or alternatives, the sibling tool names and clear purpose allow the agent to make appropriate choices.
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 and destructiveHint=false. The description adds behavioral context: requires a Gondola API key, returns formatted travel context or instructions to build one, and lists the types of data returned (loyalty programs, home airport, etc.). No contradiction with annotations.
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 core purpose in the first sentence. It then adds behavioral and usage details. While it has three paragraphs, each sentence adds meaningful information. Slightly longer than minimal but still 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 no parameters and the presence of an output schema (likely detailed), the description covers prerequisites (API key), usage timing, and return content. It is complete for this tool's simplicity and 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?
There are no parameters (0 params, 100% schema coverage), so baseline is 4. The description adds value by detailing what the tool returns, which is beyond the schema's scope (schema only says 'object'). No further parameter information needed.
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 'Get the user's saved travel context to personalize recommendations.' It uses a specific verb ('Get') and resource ('travel context'). It distinguishes from siblings by positioning itself as 'the single best source of who this traveler is' and advising to call it first.
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 explicitly says to 'Call this once at the start of a travel or planning session and weigh it across hotel, flight, and car recommendations.' This gives clear context for when to use it, though it does not explicitly list alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds that it requires an account and payment, but could further disclose potential charges or irreversibility. No contradiction with 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 concise with clear sections (prerequisites, args, returns). Every sentence adds value with no redundancy.
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?
Given 11 parameters, 9 required, and an output schema, the description covers prerequisites, parameter details, and returns adequately for invocation.
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?
With 0% schema coverage, the description fully explains all 11 parameters, including sources (e.g., 'from search results'), format (e.g., phone number example), and optional usage (disambiguation, loyalty points).
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 rental vehicle from a search result.' with a specific verb and resource, distinguishing it from sibling tools like search_vehicles and cancel_vehicle_booking.
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?
Prerequisites are explicitly listed (requires Gondola account and saved payment method) and refers to get_payment_methods for the payment ID. It explains where to obtain search_id, vendor_code, etc. No explicit when-not usage, but context is clear.
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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description confirms by saying 'Create a rate alert' and adds details like email notification and optional date constraints, beyond what annotations provide.
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 well-structured with an introductory line, usage note, and parameter list. It is concise without being overly terse. Slight improvements could include shortening the prerequisites line, but overall effective.
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?
Given the tool's moderate complexity (3 parameters, output schema exists), the description covers purpose, usage prerequisites, parameter details, and return value. No obvious gaps are present.
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 0%, but the description includes an exhaustive 'Args:' section explaining each parameter, constraints (e.g., checkin/checkout must be provided together), and the source of hotel_id. This compensates well for the lack of 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 tool creates a rate alert to monitor a hotel for price drops. It uses a specific verb ('create') and resource ('rate alert'), distinguishing it from related tools like 'delete_rate_alert' and 'get_rate_alerts'.
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 explains when to use the tool (set up an alert for price drops) and mentions prerequisites (requires Gondola account with API key). It does not explicitly state when not to use it or compare to alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds detail on return values (hotel, dates, room, rate, status), which is useful context beyond annotations. It does not disclose auth requirements or potential failures, but for a read-only retrieval tool, it is sufficient.
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 concise with three sentences: a main line, an Args section, and a Returns section. It is well-structured, front-loads the purpose, and contains no fluff.
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 simple tool with one parameter and an output schema, the description explains the return value and parameter meaning. It is complete enough given the tool's complexity and the presence of an output schema.
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?
The input schema has one parameter with no description (0% coverage). The description adds 'The booking ID or confirmation number', which clarifies the parameter's nature beyond the schema title 'Booking Id'. This fully compensates for the lack of schema description.
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 'Get details for a specific hotel booking', using the specific verb 'Get' and resource 'booking'. It distinguishes from sibling tools like get_vehicle_booking by specifying 'hotel booking'.
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 when to use (to retrieve a specific booking) but does not provide explicit guidance on when not to use or mention alternatives like get_booking_link. It is adequate but lacks clarity for an AI agent to discriminate among siblings.
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 indicate readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds valuable context about return fields (vendor, pickup/dropoff, vehicle, rate, status), enhancing transparency beyond 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 short paragraphs, front-loaded with the main purpose. Every sentence adds value—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?
For a simple read-only tool with one parameter and output schema, the description covers the argument and return content. It could mention error handling (e.g., invalid ID) but is adequate given the tool's simplicity.
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 schema has one string parameter with 0% description coverage, but the description adds meaning: 'The Gondola booking ID (confirmation number).' This clarifies the parameter's format and context, compensating for the schema's lack of description.
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 'Get details for a specific vehicle booking' with a specific verb and resource. It distinguishes from siblings like 'get_vehicle_details' (vehicle info) and 'book_vehicle' (creation).
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 explains the required argument (booking_id as Gondola confirmation number), providing clear context. However, it does not explicitly guide when to use this over siblings like 'get_booking', but the purpose is sufficiently clear.
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, openWorldHint, and destructiveHint. Description adds context about ranking based on loyalty/status and travel history, and that results include a link. This goes beyond annotations. No mention of rate limits or auth requirements, but these are less critical given the read-only nature.
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?
Well-structured with a brief introductory sentence, followed by Args and Returns sections. Each parameter description is concise yet informative. Could be slightly shorter, but the level of detail is justified for a tool with 10 parameters and nuanced behavior like mode and pagination.
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 (10 params, pagination, two modes, airline loyalty ranking), the description covers essential aspects: what the results contain, how to paginate, when to use 'book' mode, and optional filters. An output schema exists, so return values are covered. It might benefit from mentioning error cases or limitations, but it's sufficiently complete for an AI agent.
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?
The description has an explicit Args section describing every parameter in detail, including examples (e.g., origin 'LAX'), format ('YYYY-MM-DD'), valid values (cabin_class enum), and behavior (page incrementing). Schema has 0% coverage, so description fully compensates, adding significant meaning beyond just the type/required field.
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 the tool searches for flights by route and date and returns cash-priced options. The verb 'search' and resource 'flights' are specific, and 'cash-priced' distinguishes it from potential points-based searches. Sibling tools are all for different domains (hotels, vehicles), so no confusion.
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?
Provides explicit guidance on pagination (page parameter) and the mode parameter, warning that 'book' is restricted and should only be used if the user explicitly asks to book. Also explains default behavior for num_passengers, airlines, and max_stops. Lacks explicit comparison to alternatives, but the domain difference with siblings makes it clear.
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 and destructiveHint=false, so the description adds value by describing the return format (comparison table with cash rate, points rate, CPP valuation, value signals) and the constraint of max 5 hotel_ids. This goes beyond what annotations provide, though it could mention rate limits or data freshness.
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 well-structured: purpose, usage context, return value, then args list. It is not overly long, but the args list somewhat repeats information already in the schema. Could be slightly more concise, but overall efficient.
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?
Given the tool has an output schema (not shown but stated), the description doesn't need to detail return values beyond mentioning the comparison table and highlights. All four parameters are explained, and the context of using after search_hotels is clear. The description is complete for the tool's complexity.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, including the constraint that hotel_ids come from search_hotels and max 5, the date format YYYY-MM-DD, and the default for num_adults. This adds significant meaning beyond the raw 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 it compares cash vs points rates across multiple hotels side-by-side. It specifically distinguishes from sibling tools like search_hotels (which searches for hotels) and get_hotel_details (which gets details for a single hotel), making the purpose precise and unique.
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 explicitly says 'Use this after search_hotels to help a user decide between their top hotel picks,' providing clear context. However, it does not mention when not to use it or alternative tools like get_multi_night_rates for single hotel rates, which would have earned a 5.
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 it as read-only (readOnlyHint: true). The description adds context: anonymous users get only one path, card-eligible users get a second path, and deep-linking behavior. No contradictions with annotations.
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?
Well-structured with front-loaded purpose, clear bullet points for paths, and an Args section. Slightly lengthy but every sentence adds value. No fluff.
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?
Given the presence of an output schema (which likely documents return structure), the description covers all necessary aspects: purpose, usage context, parameter details, and auth-related behavior. Complete for the tool's complexity.
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 0% schema description coverage, the description provides detailed parameter explanations in an Args section, including formats, defaults, and context (e.g., hotel_id from search_hotels, gondola_rate_id from get_hotel_details). Completely compensates for missing schema documentation.
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 'Get booking options for a hotel' and distinguishes two booking paths. It differentiates from sibling tools like book_hotel by focusing on presenting links/instructions rather than executing a booking, and specifies usage after search_hotels or get_hotel_details.
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 explicitly says to use after search_hotels or get_hotel_details when a user wants to book, and advises passing gondola_rate_id for deep-linking. It implies not to use for actual booking (reserved for book_hotel) but could be more direct about when not to use or 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral detail: returns up to 10 recent reviews with ratings and comments, 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 plus structured Args/Returns section. No redundant information; every sentence adds value.
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?
Given single param, clear output description (formatted list with author, rating, text, limit 10), and output schema exists, the description is fully complete for agent 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?
Single parameter hotel_id explained as 'The hotel's Vervotech property ID (from search results),' adding source context beyond schema type/title. Schema coverage 0% but description 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?
Clearly states 'Get guest reviews for a specific hotel' using a specific verb and resource. Distinguishes from siblings as no other review tools exist.
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?
Provides explicit usage context: 'Use this to help users understand what other guests thought about a hotel.' Lacks exclusion criteria but appropriate given no alternative review siblings.
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 and destructiveHint=false. The description adds value by explaining the returned fields (brand, last 4 digits, expiration, payment ID) and the booking eligibility flag, which goes beyond 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 concise, with a clear first sentence stating the purpose, followed by necessary prerequisites and return details. Every sentence adds value without redundancy.
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?
The tool has no parameters and an output schema (assumed to be present). The description explains the return values and even mentions the dependency on book_hotel. It is fully complete for an agent to use correctly.
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?
There are no parameters, and schema coverage is 100%. The description adds meaning by detailing what the tool returns, which compensates for the lack of parameters.
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 name and description clearly state 'List the user's saved payment methods for booking.' It uses a specific verb and resource, and no sibling tool overlaps with this functionality.
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 specifies that a Gondola account (API key) is required and that the tool is needed for book_hotel. It does not explicitly mention when not to use it, but the context is clear given the unique purpose.
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 indicate readOnlyHint=true and destructiveHint=false. The description adds that it requires an API key and describes the return value (formatted list or instructions). No contradiction; adds useful context beyond 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 concise (three short paragraphs), well-structured with purpose, usage, requirement, and return value. Every sentence contributes meaning without redundancy.
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?
Given the tool's simplicity (no parameters) and the existence of an output schema, the description covers all essential aspects: what it does, how to use it (with book_hotel), prerequisites, and output summary. It is fully complete.
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?
There are zero parameters, and schema coverage is 100%. With no parameters, the baseline is 4; the description appropriately doesn't need to add parameter 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?
The description clearly states the action ('Get') and resource ('user's saved travel profiles'), and distinguishes itself from siblings by explaining how profiles are used with book_hotel, setting it apart from other tools.
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 explains when to use the tool (to prefill guest details during hotel booking) and mentions the alternative of manual entry. It also states the requirement of a Gondola account. However, it does not explicitly list when not to use it or compare with siblings.
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 (readOnlyHint=true) already indicate safety. Description adds behavioral context: authenticated vs anonymous users get different reference, and it returns instructions plus link. No contradiction. Lacks details on expiration or errors, but adequate.
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 concise: a two-sentence overview, then structured Args and Returns. No extraneous information, front-loaded with the key purpose.
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?
With an output schema present, the Returns section is sufficient. The description covers key aspects: source of parameters, auth behavior, and fallback. Could mention error handling, but overall complete for a 5-param tool.
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?
Input schema has 0% description coverage, but the description's Args section explains each parameter's origin (e.g., search_id from search_vehicles, vendor_code from search results). This fully compensates for the schema gap, making parameter semantics clear.
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 gets a Gondola.ai deep link for a specific vehicle from search results, distinguishing it from siblings like get_booking_link and book_vehicle. It specifies the auth-based behavior, making the purpose precise.
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 indicates it should be used after search_vehicles by referencing search_id and other fields from search results. It mentions auth status but does not explicitly exclude when not to use it, e.g., for actual booking. Still, clear context is provided.
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 and destructiveHint=false. The description adds that it uses historical price data and returns a recommendation, confidence level, and key signals. This adds value beyond annotations.
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 well-structured with a concise intro, usage note, and organized Args section. It is front-loaded with purpose and contains no fluff, though could be slightly shorter.
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?
Given 6 parameters (5 required), 0% schema coverage, and an existing output schema, the description provides sufficient context for parameter meanings and usage context. It is complete enough for an agent to use the tool correctly.
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%, but the description includes an Args section with clear explanations for each parameter, such as hotel_id being the Vervotech property ID, date formats, and currency examples. This fully compensates for the lack of 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 it predicts whether to book now or wait for a better price using historical data. It specifies the verb 'predict' and the resource 'price timing', and distinguishes itself from siblings like 'compare_rates' and 'diagnose_rates'.
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 says to call when a user asks 'Should I book now or wait?' or wants to know if a price is good. It provides clear context but does not mention when not to use or contrast with 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?
Annotations already indicate a non-destructive write (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral context: requires API key, returns confirmation/error, and entries persist across sessions.
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?
Well-structured with clear purpose, usage guidelines, parameter/return details. Every sentence adds value, though could be slightly more concise.
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 prerequisites, parameter semantics, return values, and persistence. With only one parameter and output schema, it is quite complete. Could mention if updating existing entries replaces or appends, but not critical.
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 0%, so the description carries full burden. It explains the parameter profile_entry with specificity and actionability guidance, including good/bad examples.
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 ('Save') and resource ('traveler profile'), clearly distinguishing this write operation from siblings like get_traveler_context. It explicitly states what is saved: durable preferences, likes, dislikes, trip experiences.
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 guidance: use for durable preferences (examples given), not for temporary logistics. Also notes the prerequisite of a Gondola account and explains that saved entries persist and come back via get_traveler_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?
Annotations already declare readOnlyHint and destructiveHint, so the description adds value by specifying what the tool returns (room options, pricing, cancellation policies, amenities). It aligns with annotations and provides useful context without redundancy.
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 concise with no wasted sentences. It starts with a clear purpose, flows into usage guidance, then details parameters and return value. Every sentence adds value and is appropriately front-loaded.
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?
Given the presence of an output schema, the description's summary of return content ('rooms, rates, policies, amenities') is sufficient. It also covers parameter semantics and usage flow. For a tool with 4 parameters and a well-defined output structure, this is complete.
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%, but the description compensates fully with an Args section that explains each parameter: hotel_id's source (Vervotech property ID from search_hotels), date formats (YYYY-MM-DD), and num_adults default. This adds critical meaning beyond the schema's bare types and titles.
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 'Get' and the resource 'detailed information, room types, and rates for a specific hotel.' It distinguishes from siblings like search_hotels (which returns a list) and compare_rates (which compares multiple hotels), making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this after search_hotels to get full details for a hotel the user is interested in.' This provides clear context for when to use it. However, it does not explicitly exclude alternative tools like get_hotel_reviews or compare_rates, leaving some room for improvement.
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 and destructiveHint=false. The description adds context about historical comparison and percentile rankings, which aligns with read-only behavior. No contradictory or missing behavioral details.
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?
Description is concise with a clear intro, usage guidance, and well-structured Args/Returns sections. Every sentence contributes value without redundancy.
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?
Given the low complexity, schema coverage, and output schema existence, the description provides sufficient information about purpose, parameters, and return type (percentile rankings and value assessment). No major gaps.
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 coverage is 0%, but the description fully explains each parameter's meaning and source (e.g., hotel_id as Vervotech property ID, nightly_cash_cost as current cash rate). This compensates completely for lack of 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 it provides 'pricing analytics and percentile data for a hotel rate' and explains it shows historical comparison of cash and points rates. This distinguishes it from sibling tools like search_hotels, book_hotel, etc.
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 'Use this to help users understand if a rate is a good deal', providing clear context. However, it does not mention when not to use it or compare to alternatives like compare_rates or predict_price.
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, openWorldHint, destructiveHint. Description adds value by specifying the type of details returned, 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?
Description is extremely concise, with clear sections for purpose, usage, and arguments. Every sentence adds value, no redundancy.
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?
Given the simple retrieval nature, output schema exists, and description covers usage, parameters, and expected details. Complete for agent decision-making.
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 0% schema description coverage, the description explains all three parameters with examples ('ZE' for Hertz, 'AL' for Alamo) and links them to search results. Fully compensates for missing 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?
Description clearly states it gets detailed information about a rental vehicle option, listing specific details (extras, insurance, charges, cancellation policy). Purpose is distinct from sibling tools like search_vehicles or book_vehicle.
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 says 'Use this after search_vehicles', providing clear context and sequence. Does not mention when not to use, but the guidance is sufficient.
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 and destructiveHint=false, and the description adds valuable context: trip-independent, looks across all programs, reports expiring points, transfer opps, tailors to travel profile. Does not contradict annotations.
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?
Description is informative and well-structured, front-loaded with the main verb and resource. A few sentences could be tightened but no wasted words.
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?
Covers all aspects: behavior, when to use, no arguments, return format (Markdown portfolio summary or instructions to connect accounts). With an output schema existing, no further detail on return 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?
Tool has zero parameters (schema coverage 100%), so baseline is 4. The description explicitly states 'Takes no arguments', which is clear 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 uses specific verbs ('analyze', 'surface') and resource ('loyalty portfolio') and clearly distinguishes from siblings by mentioning alternatives for trip-specific booking.
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 states when to use ('how to make the most of points, expiring, transfers') and when not to use (specific trips, pointing to search_hotels/compare_rates).
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 behavioral context beyond annotations: it explains return format (cash vs points rates, CPP, deal scores), chain_name fallback, and limit behavior. No contradiction with readOnly/readOnly/world/destructive hints. The annotations already cover the read-only safety, so the description supplements well.
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 well-structured with an introductory paragraph and bullet-like Args section. Every sentence adds value, from the unique selling point to detailed parameter semantics. It is concise yet thorough, with no redundant information.
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?
Given 8 parameters and an existing output schema, the description covers all necessary information: parameters, return summary, edge cases, and usage guidelines. It is self-contained and leaves no ambiguity for an AI agent.
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%, but the description's Args section provides comprehensive parameter explanations including examples, defaults, and conditional behaviors (e.g., chain_name case-insensitive match, loyalty_points affordability check). This fully compensates for the lack of schema-level 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 tool searches hotels by location and dates with cash and points pricing, and explicitly highlights its unique advantage over other travel searches, distinguishing it from siblings like get_hotel_details or book_hotel.
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 detailed guidance on parameter usage, defaults, and edge cases (e.g., chain_name fallback behavior, limit usage advice). However, it lacks explicit when-to-use versus alternative tools, though the uniqueness statement partially addresses this.
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 indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by stating it creates a booking. Adds behavioral context: rate ID source, payment method requirement, loyalty account override, and error message return. 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 well-structured with a clear first paragraph (purpose and prerequisites) followed by detailed parameter explanations. While somewhat lengthy, every sentence is informative and avoids redundancy. Could be slightly more concise, but structure is effective.
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?
Given the tool's complexity (9 parameters, dependencies on multiple sibling tools, and destructive nature), the description is thorough. It covers all prerequisites, parameter interdependencies (e.g., travel_profile_id and loyalty_account_id overrides), and the return type. An output schema exists, so the brief return description is sufficient.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, source, and optionality. For example, it clarifies that gondola_rate_id comes from get_hotel_details room rates, and loyalty_account_id overrides email. This adds significant value beyond the bare 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 explicitly states the tool books a hotel room using a rate from get_hotel_details. It clearly differentiates from sibling tools like book_vehicle and cancel_vehicle_booking. The verb 'book' and resource 'hotel room' are specific and 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 detailed usage context: requires Gondola account (API key), saved payment method, and rate ID from get_hotel_details. Explains alternatives like using travel_profile_id to prefill guest details, and loyalty_account_id to earn points. Explicitly mentions when not to use (e.g., if no account) and references sibling tools for prerequisites.
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 and destructiveHint=false. The description adds context about the two query modes and the return structure (coverage type, max days, summary). However, it does not disclose edge cases like what happens if no coverage is found or if the card is unrecognized. Since annotations carry the read-only signal, a slight gap remains.
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 front-loaded with the purpose, followed by usage instructions and return values, in three short paragraphs. Every sentence serves a clear purpose with 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?
The tool has an output schema (not shown but mentioned), so the description's brief return summary is acceptable. It covers the core functionality but could mention error handling or what happens with invalid inputs. Given low complexity, it is nearly complete.
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?
The input schema has 0% description coverage for parameters. The description fully compensates by explaining each parameter's semantics: 'credit_card_product_name' is the exact product name, 'card_number_bin' is the first 6-8 digits, 'card_provider' is the network, and it clarifies the required combination. This adds essential meaning beyond the raw 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 tool's action: 'Look up rental car CDW/LDW coverage provided by a credit card.' It uses a specific verb ('look up') and resource (credit card coverage), which distinguishes it from sibling tools like search_vehicles or get_vehicle_booking_coverage.
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?
The description explicitly tells when to use each parameter set: 'Provide EITHER credit_card_product_name OR card_number_bin + card_provider.' It also specifies the exact values for card_provider ('visa', 'mastercard', 'amex', or 'discover') and the BIN format ('First 6-8 digits'). This provides clear guidance for correct invocation.
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?
Annotations already indicate readOnlyHint=true, but the description adds valuable behavioral details: it returns a formatted list including points balance, tier status, estimated cash value, recent changes, expiration dates, and instructions to connect if no accounts. 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?
The description is concise with three short paragraphs. Every sentence adds value: purpose, returned fields, auth requirement, and return format. No unnecessary words.
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?
Given the low complexity (0 parameters, read-only), the description fully covers the tool's purpose, behavior, and prerequisites. The presence of an output schema means return values need not be elaborated further.
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 tool has zero parameters, so the description cannot add meaning beyond the schema. Per guidelines, baseline is 4. The description appropriately outlines what the tool returns without needing parameter details.
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 'Get the user's hotel and airline loyalty accounts', specifying the verb and resource. It distinguishes from sibling tools like get_payment_methods and get_free_night_credits by focusing on loyalty accounts.
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 notes that a Gondola account (API key) is required, providing context. It does not explicitly exclude scenarios or mention alternatives, but the requirement gives a clear prerequisite.
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?
Discloses need for API key, returns summary with dates/numbers/costs/loyalty, explains limit behavior (most recent first, response notes existence of more). Annotations already declare readOnlyHint=true and no destruction; description adds useful context beyond 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?
Concise three paragraphs: purpose, summary of returns, parameter details. Front-loaded with primary action. Every sentence adds value without redundancy.
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?
Given one simple parameter, comprehensive annotations, and output schema (implied by 'Returns formatted list'), the description covers account requirement, parameter behavior, and return value expectations. Fully sufficient for correct tool selection and invocation.
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 has one parameter 'limit' with no description in schema (0% coverage). Description fully compensates: explains that limit controls count, default 20, most recent first, and that the response indicates if more exist, guiding agent to raise limit only when full history is needed.
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?
Clearly states 'Get the user's past trips including hotel stays and flights.' The verb 'Get' and specific resource 'past trips' with included types distinguish it from siblings like 'get_upcoming_trips'.
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?
Implies when to use: when user wants past travel history. Mentions requirement of Gondola account. Does not explicitly contrast with alternatives like 'get_upcoming_trips' or provide when-not-to-use guidance, which would be ideal.
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:

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

Score Badge

Copy to your README.md:

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

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