Search 8,500+ airport lounges and check access by card or membership.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 21 tools
Most tools target distinct resource-action pairs, and descriptions clarify query facets like airport, network, or access method. However, get_my_passport overlaps with get_my_reviews and get_my_visits, and discover_more_flight_tools is unrelated to the core domain.
Tool names are consistently lowercase snake_case with get_my_* for personal data and *_review/*_visit for lifecycle actions. Minor deviations include mark_lounge_visited, discover_more_flight_tools, and the interchangeable use of get/list/search/find.
At 21 tools, the server sits in the heavy range and feels somewhat over-scoped. Several get_my_* endpoints could potentially be consolidated, and discover_more_flight_tools is off-domain padding.
The toolset covers full lifecycles for reviews, visits, and wishlists, plus multi-faceted lounge discovery and access-method lookups. It lacks a way to read other users' reviews for a lounge, but core agent workflows can still be completed.
Add a lounge to your wishlist. Idempotent — adding a lounge already on your wishlist is a no-op.
| Name | Required | Description | Default |
|---|---|---|---|
| lounge_slug | Yes | Lounge slug (from search results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency, and the description adds concrete meaning by explaining that adding a lounge already on the wishlist is a no-op. This clarifies the actual runtime behavior beyond what the annotation alone communicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the primary action and includes only the essential behavioral note about idempotency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation with no output schema, the description and annotations provide enough context for correct invocation. It could mention response or error behavior, but nothing critical is missing for a typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents lounge_slug as 'Lounge slug (from search results).' The description adds no additional parameter-level detail, so the baseline for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Add a lounge to your wishlist.' It clearly distinguishes the tool from read-only siblings like get_my_wishlist and from remove_from_wishlist, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is obvious from the description, but it does not provide explicit guidance about when to use this tool versus alternatives such as remove_from_wishlist or mark_lounge_visited. Usage is implied rather than directly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete your review of a lounge. Identify it by lounge_slug.
| Name | Required | Description | Default |
|---|---|---|---|
| lounge_slug | Yes | Lounge slug of the review to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true and readOnlyHint=false. The description adds the useful scoping detail that only the user's own lounge review is affected and how it is identified, but doesn't explain idempotency or irreversible effects beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action first and the lookup key second. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with rich annotations, the description is nearly sufficient: it states the operation, scope, and key. A small gap is lack of guidance on how to retrieve the lounge slug if unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover lounge_slug 100%. The description restates the parameter's role ('Identify it by lounge_slug') but adds no new format, example, or edge-case context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description names the exact operation ('Delete your review of a lounge') and specifies the identifying input (lounge_slug), clearly separating it from write/update/read siblings and from delete_visit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use context or comparison with siblings such as update_review, write_review, or delete_visit. 'Identify it by lounge_slug' is operational, not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one of your logged lounge visits. Identify it by lounge_slug; pass visited_at to pick a specific date if you have multiple visits to the same lounge.
| Name | Required | Description | Default |
|---|---|---|---|
| visited_at | No | Visit date (YYYY-MM-DD) — needed only to disambiguate multiple visits | |
| lounge_slug | Yes | Lounge slug of the visit to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the core behavioral traits. The description adds useful context about identifying the visit by lounge_slug and using visited_at when multiple visits exist, which supplements the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, purposeful sentences with no filler. The primary instruction is front-loaded, and the disambiguation rule follows naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one required parameter and annotations covering destructive and idempotent behavior, the description provides enough information to invoke it correctly. It does not describe response or error behavior, but no output schema exists and the operation is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters at 100% coverage, including the disambiguation role of visited_at. The description reinforces this by saying 'identify it by lounge_slug' and 'pass visited_at to pick a specific date', but it does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Delete') and a clearly defined resource ('one of your logged lounge visits'), which is distinct from sibling operations like update_visit and mark_lounge_visited. It also states how the resource is identified, making the operation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on how to invoke the tool—use lounge_slug and optionally visited_at to disambiguate—which is essential for correct usage. It does not explicitly name alternative tools or state when not to use it, but the delete intent and identification instructions are sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover other flight & travel MCP servers you can add to your client. Lists complementary remote MCPs covering award flights/points redemptions, aircraft seatmaps, and airport delays/wait times — with one-line install URLs. Call this when the user asks about points/miles, seat selection, airport delays/security waits, or 'what other flight tools are there?'
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add extra context. It adds that the tool lists complementary remote MCPs and includes one-line install URLs, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: what the tool does, what content it lists, and when to call it. Each sentence earns its place, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter discovery tool with no output schema, the description fully covers purpose, content categories, output format (one-line install URLs), and usage triggers. An agent has everything needed to decide when to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and the schema description coverage is 100%, so there are no parameters to document. The description correctly implies this is a no-argument discovery call, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Discover other flight & travel MCP servers you can add to your client.' It also enumerates the content domains (award flights, seatmaps, delays) and one-line install URLs, clearly distinguishing this listing/discovery tool from the lounge, review, and wishlist siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies trigger conditions: 'Call this when the user asks about points/miles, seat selection, airport delays/security waits, or what other flight tools are there?' This gives an agent unambiguous guidance on when to select this tool over the lounge-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all airport lounges accessible with a specific credit card, membership program, airline club, alliance status, or ticket class. For example, find all lounges you can access with your Amex Platinum or Priority Pass membership.
| Name | Required | Description | Default |
|---|---|---|---|
| access_method | Yes | Access method slug (e.g. amex-platinum, priority-pass, chase-sapphire-reserve, business-class, star-alliance-gold) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context beyond the basic lookup nature—no mention of result ordering, data coverage, or any side effects. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence front-loads the core behavior, and the second gives a practical example. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only lookup tool with full enum coverage and safety annotations, the description is fairly complete. It explains what the tool finds and gives recognizable examples. It could be slightly richer by addressing result scope or clarifying the relationship to sibling search tools, but nothing essential for calling the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the access_method parameter is fully described in the schema with an enum and example slugs. The description adds general context about what counts as an access method but does not add meaning beyond the schema. Baseline 3 applies because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Find all airport lounges accessible with a specific...' It specifies the filtering dimension (credit card, membership, airline club, alliance, ticket class) and gives concrete examples. However, it does not explicitly name or distinguish itself from sibling tools like search_lounges or get_network_lounges, so it misses the highest bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case through examples ('find all lounges you can access with your Amex Platinum or Priority Pass'), but it never says when to prefer this tool over alternatives such as search_lounges or get_network_lounges. There are no exclusions or routing conditions, only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all airport lounges at a specific airport by IATA code. Returns every lounge at the airport with terminal location, amenities, access methods, and ratings.
| Name | Required | Description | Default |
|---|---|---|---|
| iata | Yes | Airport IATA code (e.g. LHR, JFK, SIN) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds what the call returns: terminal location, amenities, access methods, and ratings. It also signals exhaustive results ('Returns every lounge'), which is valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences lead with the action and scope, then list the returned fields. There is no filler or duplication of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one required parameter, the description explains both how to call it and what the response will contain, compensating for the missing output schema. It could add edge-case behavior such as how no-lounge airports are handled, but the current coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single iata parameter is already documented with a pattern and examples. The description reinforces that the code identifies the airport but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get all'), a precise resource ('airport lounges at a specific airport'), and the required lookup key ('IATA code'). It distinguishes itself from siblings like get_lounge_details or search_lounges by defining the exact scope: every lounge at one airport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: retrieve the full lounge set for one airport identified by IATA code. It does not explicitly name when to prefer sibling tools such as find_lounges_by_access or search_lounges, so it stops short of the strongest exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific airport lounge by its slug. Returns full description, amenities, access methods, opening hours, capacity, ratings, and reviews count.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Lounge slug (from search results or airport lounges) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the exact return content: full description, amenities, access methods, opening hours, capacity, ratings, and reviews count. For a simple read-only getter, this is sufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the action and resource, then lists the key return fields. Every clause adds useful information and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only getter with no output schema, the description is complete: it explains what the tool does, how the parameter is obtained, and what the response will contain. Annotations cover side-effect safety, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter 'slug' is documented as coming from search results or airport lounges. The tool description merely says 'by its slug' and adds no additional parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and the specific resource ('a specific airport lounge by its slug'). It distinguishes itself from list/search siblings by focusing on one lounge and enumerating the fields returned. The title 'Lounge details' is weak, but the description fully compensates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after obtaining a lounge slug, which is reinforced by the schema's note that the slug comes from search results or airport lounges. It does not explicitly name alternatives or exclusion cases, but the context of 'specific lounge by slug' makes the appropriate use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your lounge passport — stats (lounges visited, airports, countries, reviews), country stamps, full visit history, and your reviews. Includes a shareable passport URL when your profile is public.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds a meaningful conditional detail: the shareable passport URL is only included when the profile is public. This is useful behavioral context not present in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The main content list is front-loaded, and the conditional URL detail is appended without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description enumerates all major return categories (stats, stamps, history, reviews) and a conditional behavior, which is sufficient for an agent to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no input semantic burden on the description. The baseline for no-parameter tools is 4, and the description appropriately focuses on output content rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('your lounge passport'), then enumerates its contents: stats, country stamps, visit history, reviews, and shareable URL. This clearly distinguishes it from sibling tools like get_my_visits and get_my_reviews by presenting it as an aggregate overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when the agent needs the user's consolidated passport overview rather than individual visit/review/profile data. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it for aggregate personal data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Airport Lounge List profile — username, stats (reviews, visits, wishlisted lounges), and recent activity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful scope ('your' profile) and return contents, but it does not discuss authentication needs, exact response structure, or what 'recent activity' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It names the resource and its key contents efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description sufficiently explains what the tool returns and for whom. However, without an output schema, 'recent activity' remains somewhat vague, leaving a small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter burden for the description to carry. This is the baseline case where parameter semantics are naturally satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('your Airport Lounge List profile'), and enumerates contents (username, stats, recent activity). This clearly distinguishes the aggregate profile tool from sibling list tools like get_my_reviews and get_my_visits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when someone wants their own profile summary, but it does not explicitly say when to prefer this tool over the sibling get_my_* tools or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your lounge reviews, including pending ones. Returns rating, content, approval status, and lounge info.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reviews to return (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral value by stating that pending reviews are included and by listing the exact return fields. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero filler. The action and scope are front-loaded, followed by a compact list of return fields. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, read-only, has one optional parameter, and the description enumerates the response contents. Even without an output schema, an agent has enough information to invoke the tool and interpret its return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, limit, is fully described in the input schema (100% coverage) with its default and maximum. The description does not need to repeat it, and it adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Get your lounge reviews') and adds a distinguishing scope ('including pending ones'). It also enumerates returned fields (rating, content, approval status, lounge info), making the tool's purpose unambiguous even among similar siblings like get_my_visits or write_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is clear from the context: use this when you need the current user's lounge reviews, including pending ones. It does not explicitly name alternatives or exclusions, but the simple read-only nature and the self-describing resource make explicit guidance largely unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your visited lounges list with dates and notes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max visits to return (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, idempotent, and non-destructive behavior, so the description does not need to restate that. It adds useful return scope ('dates and notes'), but does not describe ordering, pagination effects, or empty-list behavior; acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, redundancy, or repetition of the title. The key action and resource are front-loaded, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one optional parameter, rich safety annotations, and no output schema. The description gives the key return aspects ('dates and notes') and clearly scopes the data. Minor missing details like ordering are not critical to correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, limit, is fully documented with its default and maximum. The description adds no parameter-specific detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), the resource ('your visited lounges list'), and the included fields ('dates and notes'). The 'visited' qualifier clearly distinguishes this from sibling list tools like get_my_wishlist and get_my_reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is for retrieving the user's own past lounge visits, which implies when it should be used. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your lounge wishlist — lounges you want to visit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds semantic context about what a wishlist contains but discloses no additional behavioral traits such as return format or ordering; the bar is lower here, and the description meets it without going further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the verb and resource, with a brief parenthetical clarification. Every word earns its place and there is no redundant restating of the title or name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, non-destructive, idempotent read tool, the description is complete enough: it states what the tool retrieves and what the result represents. The output schema is absent, but the description's appositive sufficiently conveys that the return value is a list of lounges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is trivially 100%, so there is no parameter meaning for the description to enrich. Per the 0-parameter baseline, this dimension should be treated as satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise verb and resource: "Get your lounge wishlist." The appositive "lounges you want to visit" defines the resource unambiguously and distinguishes it clearly from sibling getters like get_my_reviews and get_my_visits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "your lounge wishlist" establishes a clear context for when to call this tool, and the sibling names add_to_wishlist and remove_from_wishlist make the read-versus-mutate distinction obvious without needing explicit exclusions. It lacks an explicit when-not-to-use statement, but none is really required for a simple parameterless getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all lounges in a specific lounge network. Returns every lounge that accepts a particular network membership (e.g. all Priority Pass lounges worldwide).
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network slug (priority-pass, loungekey, dragonpass, plaza-premium, amex-centurion) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful return-scope context ('Returns every lounge that accepts a particular network membership') but does not disclose any additional behavioral details such as pagination, response shape, or access requirements. This is consistent with the annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core operation is front-loaded ('Get all lounges in a specific lounge network'), and the example is concise and illustrative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only, idempotent tool with full schema coverage and no output schema, the description adequately explains what will be returned. The only minor gap is the lack of explicit routing guidance versus related siblings, which is slightly more important here because no output schema exists to further disambiguate expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, 'network', already has a clear enum and descriptive text. The description does not add meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the verb ('Get') and resource ('all lounges in a specific lounge network'), and the example ('all Priority Pass lounges worldwide') reinforces the exact scope. This is distinct from sibling tools like get_airport_lounges or search_lounges because the organizing dimension is the network membership, not the airport or free-text search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need every lounge that accepts a given network membership. However, it does not explicitly compare against siblings such as get_airport_lounges, find_lounges_by_access, or search_lounges, nor does it state when not to use this tool, so routing guidance is left partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available lounge access methods including credit cards (Amex Platinum, Chase Sapphire Reserve, etc.), membership programs (Priority Pass, LoungeKey, etc.), airline clubs, alliance status levels, and ticket classes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful content detail by listing credit cards, memberships, airline clubs, alliance levels, and ticket classes, but does not add significant behavioral context beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence with the core purpose front-loaded. The category examples are concise and directly informative without excessive detail or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only listing tool, the description fully conveys what the agent can expect: a comprehensive list of access methods across the major categories. No output schema is present, but the description sufficiently characterizes the return value for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden. The description appropriately focuses on the output content rather than input semantics, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List all available lounge access methods') and the resource, and then enumerates the categories covered. This differentiates it from sibling tools like search_lounges or find_lounges_by_access, which target lounge discovery rather than access-method catalogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: use this tool when the agent needs a catalog of all lounge access methods. It does not explicitly name alternatives or exclusions, but the no-parameter design and 'list all available' phrasing make the appropriate use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all lounge networks (Priority Pass, LoungeKey, DragonPass, Plaza Premium, Amex Centurion) with their descriptions and total lounge counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond annotations by specifying the concrete scope ('all') and the exact result contents: descriptions and total lounge counts. This gives the agent a clearer expectation of what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One focused sentence front-loads the verb and object, then adds the key output fields. No filler or repetition, and every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with strong annotations, the description is complete: it names the result category, the known members, and the included fields. There is no output schema, but the description effectively communicates what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially complete. With no parameters to document, the description does not need to add parameter-level meaning, and the 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a clear resource ('lounge networks'), and enumerates the exact networks (Priority Pass, LoungeKey, DragonPass, Plaza Premium, Amex Centurion). This differentiates it from siblings like get_network_lounges, which focus on lounges within a network rather than the network catalog itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies that this is the tool to use for a full catalog of lounge networks and their counts, but it does not explicitly state when not to use it or name alternative tools. An agent could infer the use case, but there is no direct routing guidance relative to siblings like get_network_lounges or find_lounges_by_access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a lounge visit (check in). Identify the lounge by its slug OR by lounge_name + airport_iata. Optionally add a 1-5 rating and notes. Idempotent: logging the same lounge on the same date updates the existing visit's rating/notes instead of creating a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional notes about your visit | |
| rating | No | Your rating, 1 (poor) to 5 (excellent) | |
| visited_at | Yes | Date of visit (YYYY-MM-DD) | |
| lounge_name | No | Lounge name — use with airport_iata if you don't have the slug. | |
| lounge_slug | No | Lounge slug (from search results). Preferred if known. | |
| airport_iata | No | 3-letter airport IATA code — use with lounge_name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Idempotent: logging the same lounge on the same date updates the existing visit's rating/notes instead of creating a duplicate,' but the annotations declare idempotentHint=false. This is a direct contradiction about whether repeated calls are safe to invoke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both purposeful. The primary action and identification logic are front-loaded, and the idempotency behavior earns its place as critical usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with six parameters and no output schema, the description covers the essential invocation details: what to do, how to identify the lounge, optional fields, and duplicate-handling behavior. It could be more complete by naming sibling alternatives, but nothing critical to calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented well. The description adds value by clarifying the identifier alternatives ('slug OR lounge_name + airport_iata') and by indicating that rating/notes update an existing visit on the same date, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Log a lounge visit (check in).' It clearly identifies the action and the target resource, though it does not explicitly contrast itself with sibling tools like update_visit or write_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by 'Log a lounge visit (check in)' and the identification instructions are clear, but there is no explicit statement of when NOT to use this tool or when to prefer alternatives such as update_visit, delete_visit, or write_review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a lounge from your wishlist.
| Name | Required | Description | Default |
|---|---|---|---|
| lounge_slug | Yes | Lounge slug (from search results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation and repeatability aspects are covered. The description aligns with these annotations and adds the target resource, but it does not disclose permanence, error behavior, or whether the lounge must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear, declarative sentence with no filler. It front-loads the action and avoids redundancy while remaining fully comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation tool, the description plus schema and annotations are sufficient for correct invocation. Annotations cover destructiveness and idempotency, and no output schema is expected for a removal. A note about the removal being permanent would be a minor enhancement, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single lounge_slug parameter is already described as 'Lounge slug (from search results)'. The description adds no parameter-level detail, but none is necessary given the schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('remove') and a clear resource ('a lounge from your wishlist'), making the operation unambiguous. It distinguishes itself from sibling tools like add_to_wishlist and get_my_wishlist by naming the action explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states only the operation and gives no explicit when-to-use guidance or named alternatives. However, since no other sibling tool removes wishlist entries, the intended use is reasonably implicit from context and the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search airport lounges worldwide by name, airport name, IATA code, city, or country. Returns matching lounges with amenities, access methods, and ratings. Use this to find specific lounges or discover lounges in a location.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (lounge name, airport name, IATA code, city, or country) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context by stating the search is worldwide and returns amenities, access methods, and ratings, but it doesn't disclose additional behavioral traits like pagination, result limits, or matching semantics. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero filler: action and scope first, return values second, usage intent last. Each sentence adds distinct information and the most decision-relevant content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search with rich annotations, the description covers what to query and what comes back, which matters given no output schema exists. Minor gaps are unstated result-limit or ordering behavior, but nothing an agent needs to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single query parameter. The description's list of search fields restates the schema rather than adding new format or syntax guidance; baseline 3 applies when the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('airport lounges worldwide'), and enumerates the search dimensions (name, airport name, IATA code, city, country), which differentiates it from siblings like get_airport_lounges or find_lounges_by_access. It also states return content, so an agent knows exactly what the tool does and what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Use this to find specific lounges or discover lounges in a location' gives clear context for when the tool is appropriate. However, it does not explicitly exclude alternatives such as get_airport_lounges for a known airport or find_lounges_by_access for access-based filtering, so sibling routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update your review of a lounge — change the rating and/or the text. Identify the review by lounge_slug.
| Name | Required | Description | Default |
|---|---|---|---|
| rating | No | New rating, 1-5 | |
| content | No | New review text (minimum 10 characters) | |
| lounge_slug | Yes | Lounge slug of the review to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, covering the mutation and overwrite behavior. The description adds that the review is identified by lounge_slug, but does not go beyond the annotations to describe side effects such as permanent replacement of previous contents. There is no contradiction with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the verb and resource, then quickly states the supported updates and the identifying parameter. Every clause earns its place, and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter update tool with full schema descriptions and behavioral annotations, the description covers the essential call context: which review is affected, what fields can change, and how to identify it. There is no output schema, so return-value behavior is unspecified, but this is not critical for a mutation tool whose main effect is the side effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: lounge_slug, rating, and content are already documented with their roles and constraints. The description adds the 'and/or' nuance that rating and text can be changed independently, but this is a minor clarification over the schema's optional-properties information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and identifies the resource ('your review of a lounge') plus the exact update actions ('change the rating and/or the text'). It also names the identifier ('lounge_slug'), making the tool's purpose unmistakable and distinct from sibling tools like write_review or delete_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a user wants to change an existing review's rating or text. However, it does not explicitly state when not to use it or contrast it with alternatives such as write_review, delete_review, or update_visit, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update one of your logged lounge visits — change the rating, notes, or date. Identify the visit by lounge_slug; if you have multiple visits to the same lounge, pass visited_at to pick the one to update.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | New notes | |
| rating | No | New rating, 1-5 | |
| visited_at | No | Existing visit date (YYYY-MM-DD) — needed only to disambiguate multiple visits | |
| lounge_slug | Yes | Lounge slug of the visit to update | |
| new_visited_at | No | Change the visit date to this (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the mutation profile is known. The description adds that the visit is logged and owned by the caller ('your'), but it does not clarify partial-update semantics, such as whether omitted fields are preserved or overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and free of filler. Every sentence contributes useful information about what the tool does or how to identify the target visit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no output schema, the description plus fully documentated schema covers the important aspects: what can change and how to identify the right visit. The main gap is unspecified partial-update behavior, which is minor given the simple resource shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description reinforces lounge_slug as the identifier and visited_at as the disambiguator, but adds little beyond what is already present in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update') and the resource ('one of your logged lounge visits'), and names the mutable fields: rating, notes, or date. It is unambiguous and obviously distinct from sibling tools like update_review, since it targets the visit entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: the visit is identified by lounge_slug, and visited_at is used to disambiguate when multiple visits to the same lounge exist. It does not explicitly contrast this with mark_lounge_visited or update_review, so it stops short of a full when-to-use explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a review for a lounge. Requires the lounge slug, a rating (1-5), and review text (min 10 characters).
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | Rating from 1 (poor) to 5 (excellent) | |
| content | Yes | Review text (minimum 10 characters) | |
| lounge_slug | Yes | Lounge slug (from search results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-destructive, non-idempotent operation, and the description adds little beyond restating the core action. It does not mention side effects, whether it creates a new review, or what happens if a review already exists, which would be useful context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, uses two short sentences, and leads with the primary purpose before listing requirements. Every sentence carries useful information for selecting and invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has a fully described schema, and the description covers the required inputs. However, there is no output schema, and the description does not clarify what is returned or how this operation relates to updating an existing review, leaving minor gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are fully documented in the schema. The description repeats the rating range and minimum content length but does not add new meaning beyond what the schema already provides, matching the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Write') and the specific resource ('a review for a lounge'), which is distinct from update_review or delete_review. However, it does not explicitly call out sibling tools or differentiate itself from them, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required inputs but gives no guidance on when to use this tool versus alternatives like update_review. There is no mention of the conditions for creating a new review or any exclusions, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_to_wishlistdelete_reviewdelete_visitdiscover_more_flight_toolsfind_lounges_by_accessget_airport_loungesget_lounge_detailsget_my_passportget_my_profileget_my_reviewsget_my_visitsget_my_wishlistget_network_loungeslist_access_methodslist_networksmark_lounge_visitedremove_from_wishlistsearch_loungesupdate_reviewupdate_visitwrite_reviewSearch award flight availability and points pricing across 27 airlines and 23 loyalty programs.
Seat maps, seat ratings, traveller reviews and seat alerts for 150+ airlines.
Search live credit card merchant offers across Amex, Chase, Citi, PayPal, Rakuten, Capital One.
Plan trips and track visa days per traveller across 39,601 entry rules
Add one secure layer between your agents and this server.
