get_network_loungesGet 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.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action, and the wishlist/visit/review lifecycles are clearly separated. However, get_my_passport, get_my_profile, and get_my_visits overlap somewhat in stats and visit history, which could cause minor confusion.
All tool names use snake_case and a verb-first structure, which is fairly consistent. The main deviation is mixing get_, list_, search_, find_, and discover_ for read operations, plus discover_more_flight_tools sits outside the domain naming pattern.
21 tools is slightly above the ideal 3-15 range but still well-scoped for a server covering lounge discovery, wishlists, visits, reviews, and user profiles. Each tool has a clear place and there is no obvious bloat.
The tool set provides full CRUD coverage for wishlists, visits, and reviews, plus rich lounge discovery by airport, network, access method, and search. A minor gap is that lounge details only show review counts, not the actual reviews from other users.