seats.aero MCP server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation3/5
The tool names and descriptions suggest overlapping purposes: get_destinations, get_routes, get_flights, get_trips, and get_bulk_avail all appear to return availability data at different granularities, but the distinctions are not always obvious. An agent might struggle to choose between get_routes and get_destinations, or get_flights and get_trips, without deeper documentation.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (get_destinations, get_trips, refresh_cached_data, live_search, get_flights, get_bulk_avail, get_routes). The verbs and nouns are clear and predictable, providing a consistent naming convention across the set.
Tool Count5/5
With 7 tools, the server is well-scoped for an award travel search domain. Each tool covers a distinct aspect of querying or managing availability data, and the number is neither excessive nor insufficient.
Completeness4/5
The tool surface covers the main workflows: finding destinations, routes, flights, bulk availability, live search, and refreshing cached data. A minor gap exists in that there is no explicit tool for detailed pricing per flight or for managing specific search parameters, but agents can likely work around this with the available tools.
Average 3.7/5 across 7 of 7 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating a safe, non-mutating operation. The description adds no behavioral details such as pagination, rate limits, or result completeness, but it also does not contradict the annotations. The annotations carry the transparency burden, so the score is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, front-loading the action. However, it is so brief that it verges on under-specification; it could have added useful context while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no output schema, and complex sibling tools. The description 'Find bulk availability for a particular source' is too thin to explain what 'bulk availability' means, what the response contains, or how to construct a query. Significant gaps remain 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, with detailed descriptions for most parameters, so the baseline is 3. The description only adds marginal meaning by implying the 'source' parameter is the key filter ('for a particular source'), but it offers no additional syntax or contextual detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and resource 'bulk availability' scoped to 'a particular source,' which helps distinguish it from sibling tools like get_flights or get_destinations. However, it does not clarify what 'bulk availability' means (e.g., multi-date or multi-route results), leaving some ambiguity about the tool's exact function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like live_search or get_flights. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.
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, openWorldHint, and idempotentHint, so the safety profile is established. The description adds no additional behavioral context beyond stating the action, such as return format or side effects. This is adequate for a simple getter but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the verb and object. It contains no filler or redundant information, making it optimally 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?
For a simple one-parameter read-only tool with strong annotations, the description is mostly complete. However, without an output schema, it does not clarify what 'routes' specifically returns (e.g., city pairs, flight numbers) or any limitations, leaving a minor gap. The enum and sibling names provide some disambiguation, so it remains adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'source' parameter, including an enum and a clear description ('Mileage program source to list routes for'). The description does not add extra semantic detail, but the schema already provides sufficient meaning, aligning with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('get') and resource ('routes') and specifies the scope ('for a particular source'). It does not explicitly distinguish from sibling tools like get_destinations or get_flights, but the term 'routes' provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The implication that it is meant for a specific source is only derived from the parameter definition, not from the description itself.
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, openWorldHint, and idempotentHint, covering the safety profile. The description adds the 'cached' nature, which signals possibly stale data, but gives no further behavioral details such as pagination or data freshness. With annotations present, the incremental context is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero wasted words. It immediately communicates the core action, and the schema handles all technical detail, so this brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 17 parameters and no output schema, yet the description is only one sentence. It does not explain the return shape, pagination, the meaning of cursor, or how include_trips affects results. The schema covers parameter meaning, but the description leaves the agent without essential behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 17 parameters have meaningful descriptions), and the tool description adds no parameter-level semantics. The baseline of 3 applies because the schema carries the full burden of parameter explanation.
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 ('Get') and resource ('cached award flights') on seats.aero, clearly distinguishing it from sibling tools like live_search (cached vs. live) and get_trips/get_routes (award flights vs. trips/routes).
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?
No explicit when-to-use or when-not-to-use guidance is provided. The word 'cached' implies this tool serves cached data rather than live searches, but it does not name alternatives like live_search or refresh_cached_data. Usage context is only implied.
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, idempotentHint, and openWorldHint, covering the safety profile. The description adds meaningful access restrictions ('cannot be used by Seats.aero Pro users', 'requires a commercial agreement') and the 'live' nature of the search, which go beyond annotations. It doesn't describe rate limits or response format, but the annotations lower the bar.
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 exactly two sentences, front-loaded with the core purpose and followed by an important access restriction. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain return values, pagination, or result structure, which is a gap for a search tool. However, the access restrictions and 'live' nature provide useful context, and the rich parameter schema covers the input side. It is adequate but not deeply complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-level detail beyond what the schema already provides (e.g., origin/destination/departureDate/source are all well-documented). The phrase 'one route, date, and mileage program' maps directly to existing schema fields without extra semantics.
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 'Run a live award search for one route, date, and mileage program' – a specific verb, resource, and scope. This distinguishes it from siblings like get_bulk_avail (multiple routes) or get_flights (cached searches) by emphasizing 'live' and 'one route'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_flights or get_bulk_avail. The only context is an access restriction ('cannot be used by Pro users', 'requires commercial agreement'), which is not usage guidance. There are no when/when-not statements or named 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 readOnly, openWorld, and idempotent hints, so safety is covered. The description adds key behavioral context beyond annotations, such as 'cheapest raw mileage price per cabin' and the directionality of search. However, it does not detail return format or behavior when both params are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and includes a meaningful detail. Every word contributes value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explicitly describe the return values or behavior when both optional parameters are provided or omitted. While annotations and schema cover safety and parameter semantics, the description leaves some ambiguity about output structure and edge cases, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already having a description. The tool description adds no additional parameter meaning beyond what is in the schema, so the baseline 3 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 finds airports reachable nonstop from or to one airport, with a specific detail about pricing (cheapest raw mileage price per cabin). This is a specific verb+resource and distinguishes it from sibling tools like get_routes or get_flights.
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 the tool's use case (finding nonstop destinations/origins with price) but does not explicitly state when to use it over alternatives or mention any exclusions. There is no reference to sibling tools or conditions where this tool should not be used.
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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the 'cached' qualifier but does not explain implications like openWorldHint or what specific trip fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that gets straight to the point, with no redundant information. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple 2-parameter schema, annotations, and sibling context, the description is sufficient for an agent to understand the tool's purpose, though it lacks detail about the output format. Since there is no output schema, a brief mention of the return structure could improve it, but it's not critical.
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 fully cover both parameters (id and include_filtered), so the description need not add more. It does not explain how include_filtered affects results beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'flight-level trip details for a cached Availability object,' clearly distinguishing it from sibling tools like get_flights or get_destinations.
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 implies the tool is used when you have a cached Availability object ID and need trip-level flight details, but it does not explicitly mention when not to use it or alternative tools for other scenarios.
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 readOnly=false and idempotent=true, so the agent knows this is a mutating but idempotent operation. The description adds the behavioral trait of 'queue or poll' and highlights the commercial restriction, which goes beyond what annotations convey. It does not detail side effects, but given the annotations, this 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 composed of two concise sentences, with the primary action stated first and the restriction/alternative immediately after. Every word earns its place, and there is no fluff or 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 a single parameter fully described in the schema, no output schema, and annotations covering safety profile. The description provides the essential context: what it operates on, the quantity limit, and the exclusion for commercial users. This is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema fully documents the availabilityIds parameter with constraints (1-250 items, string format). The description does not add extra semantics beyond restating the count range, 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.
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: to queue or poll refreshes for 1-250 cached Availability objects. It uses a specific verb ('queue or poll') and resource ('cached Availability objects'), and it distinguishes itself from siblings by explicitly comparing to live_search.
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 provides explicit usage guidance, stating that commercial users cannot use this endpoint and should use live_search instead. This clearly signals when to use this tool versus an alternative, fulfilling the dimension fully.
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:

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

Score Badge

Copy to your README.md:

[![seats.aero-mcp-server MCP server](https://glama.ai/mcp/servers/gavgrego/seats.aero-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/gavgrego/seats.aero-mcp-server)

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/gavgrego/seats.aero-mcp-server'

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