aa-mcp-server

by thehesiod

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools target distinct domains like auth, account summary, credits, loyalty, and reservations. Minor overlap between get_flight_credits and get_trip_credits, and get_account_summary vs get_profile_details, but descriptions clarify differences.
Naming Consistency5/5
Almost all tools follow a consistent verb_noun pattern (get_, check_, save_, search_). The naming is predictable and clear, with only minor deviation like 'search_change_flights'.
Tool Count5/5
13 tools is well-scoped for an airline account management server, covering account info, credits, loyalty, notifications, offers, profile, reservations, and session management without being excessive.
Completeness3/5
Covers account info, credits, loyalty, and reservation retrieval well, but lacks core operations like booking, canceling, or actually changing reservations (only search for changes). Notable gaps in flight lifecycle management.
Average 3.4/5 across 13 of 13 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or destructive actions. The description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which avoids fluff, but it lacks necessary detail. While concise, it is under-specified for an agent to understand the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown), the description does not need to detail return values, but it omits high-level context about what partner offers are, how they are displayed, or any filtering logic. The description is incomplete for smooth agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions 'account' is optional and uses default, but does not define what account means, what the default resolves to, or how it affects results. With 0% schema description coverage, more semantic detail is needed.
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 states it retrieves partner offers/promotions on the dashboard, which is clear and specific. However, it does not elaborate on whether it lists or shows details, and it does not distinguish itself from sibling tools like get_flight_credits beyond the unique noun.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description simply states what it does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies read-only behavior but does not explicitly state idempotency, authorization requirements, or whether the tool modifies state.
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?
Very concise, with purpose stated upfront and parameters listed. Could be slightly more structured but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of a sibling tool for trip credits and no output schema explanation, the description is incomplete. Lacks context on when to query flight vs trip credits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description only lists parameter names with defaults, adding no additional meaning about valid locale codes or account naming conventions.
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?
Clearly states it retrieves flight credits from cancelled flights. However, it does not differentiate from sibling tool 'get_trip_credits', which may be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_trip_credits or get_account_summary. Simply lists parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions an optional parameter and does not disclose read-only nature, auth requirements, or behavioral traits like pagination or notification types.
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?
Very concise at two sentences with clear parameter listing. Minimal waste, but the first sentence is a fragment ('Account notifications panel') which slightly reduces clarity.
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?
Given the tool's simplicity (1 optional param, output schema exists), the description covers the basics but lacks explanation of the panel contents or behavior. For a get-tool, more context about what is returned would improve completeness.
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 description adds 'Account name' for the parameter, which the schema already shows as a string with a default. Schema description coverage is 0%, so description must compensate. It adds minimal value beyond the schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Account notifications panel' hints at retrieving notifications, but lacks a clear verb like 'retrieve' or 'get'. It is not tautological but is vague. Sibling tools are similar (get_account_summary, etc.), but 'notifications' is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention any prerequisites, context, or exclusions. With multiple sibling get-tools, this omission reduces usability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It states the tool returns data (read-only implied) but does not mention authentication requirements, rate limits, side effects, or that no changes are made. The output schema exists, but the description adds no behavioral context beyond the data listing.
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 concise (two sentences) with no wasted words. Front-loaded with the output purpose, followed by the parameter. Slightly improved structure could show parameter info as a bullet, but it is already efficient.
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?
Given the single optional parameter and existence of output schema, the description is adequate but incomplete. It omits usage guidance and behavioral details, and acronyms (EQDs, EQMs, EQSs) are not expanded, potentially confusing agents unfamiliar with airline jargon.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the account parameter is optional and uses a default, adding meaning beyond the schema's type and default empty string. However, it does not specify what the default account is, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns elite status progress including Loyalty Points YTD, last-year EQDs/EQMs/EQSs, and tier thresholds. This distinguishes it from sibling tools like get_mile_activity (miles) and get_account_summary (broader account info). However, it lacks an explicit verb like 'Retrieves' or 'Gets,' relying on the tool name for action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_mile_activity or get_account_summary). The description only notes the account parameter is optional, with no when/when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, if it has side effects, or any other behavioral traits. The phrase 'Upcoming flight reservations' weakly implies a read operation, but this is not explicit, missing important transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first establishes purpose, second describes the parameter. No wasted words, front-loaded with the core functionality. Ideal structure for a simple tool.
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?
Given the simplicity (one optional param, output schema exists), the description is mostly adequate for retrieval. However, it omits what 'upcoming' means (e.g., time window) and any default behavior like sorting. The presence of the output schema helps, but a bit more context would improve completeness.
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 0% description coverage, so the description must compensate. It adds that 'account' is an account name and defaults if omitted, providing basic semantics. However, this is minimal and does not explain format or allowed values beyond the schema type 'string'.
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 'Upcoming flight reservations with record locators' clearly indicates the tool retrieves a list of upcoming flight reservations that include record locators. This distinguishes it from siblings like get_reservation_by_locator (single reservation) and search_change_flights (search/modify). However, it lacks a specific verb like 'list' or 'get', so it's not maximally explicit.
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 only explains the optional account parameter ('Account name (optional, uses default).') but provides no guidance on when to use this tool versus alternatives like get_reservation_by_locator or search_change_flights. There is no mention of prerequisites or typical use cases.
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?
With no annotations, the description partially discloses behavior by listing returned fields. However, it does not mention read-only nature, authentication needs, or side effects. The 'get' in the name implies read-only but is not explicit.
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 concise, using two lines to summarize output and the argument. It is front-loaded with the key info. Minor improvement could be a more structured format.
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?
An output schema exists, so return value details are not needed. However, given the context (siblings like check_auth_status, get_profile_details), the description does not help the agent choose this tool over others. It lacks when to use it context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter with 0% description coverage. The description adds minimal information: 'Account name (optional, uses default).' It does not explain what 'account' refers to or what the default value is, adding little value 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 clearly states the tool returns member info including name, AAdvantage number, mile balance, status, etc. It uses specific verb+resource and lists fields, but does not differentiate from siblings like get_profile_details or get_mile_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It only notes the account parameter is optional and uses a default, but does not explain prerequisites or when this summary is appropriate over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as being read-only, authentication requirements, rate limits, or error handling. The description only states the functional purpose.
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 very concise, with a brief purpose statement followed by parameter arguments in a clear format. No unnecessary words, and the purpose is front-loaded. Could be improved by structuring the args more readably.
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?
Given the low parameter count and existence of an output schema, the description is mostly adequate. However, it misses usage guidelines and behavioral transparency, making it incomplete for an agent to use without additional 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 0%, so the description must compensate. It provides basic meaning for 'locale' (default en_US) and 'account' (optional, uses default), but lacks details on format, allowed values, or behavior. Adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Trip credits' and specifies they are 'multi-passenger / itinerary-level credits,' which distinguishes it from the sibling tool 'get_flight_credits' that likely operates per passenger.
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_flight_credits' or 'get_account_summary.' The context signals indicate sibling tools exist but the description does not help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose whether the tool modifies state, whether a session must exist, or what happens on failure. It implies a read-only check but is not explicit.
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 concise with a clear one-line summary and an 'Args' section. It front-loads the key purpose, but the parameter documentation could be more detailed.
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?
Given the presence of an output schema, the description does not need to detail return values. However, it lacks context on prerequisites (e.g., need for a saved session) and potential errors, which are important for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'account' parameter by stating it is optional and uses a default. This goes beyond the schema's minimal definition, though it is brief.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'saved AA session', and lists specific return fields (token expiry, AAdvantage #, cookie count). This distinguishes it from sibling tools that deal with other account details or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_profile_details' or 'save_session_from_browser'. Does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output fields but does not mention that the tool is likely read-only, require authentication, or have any side effects. This is adequate but lacks explicit safety or behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value. No unnecessary repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description adequately covers purpose and parameter. It could mention that it's a read operation, but overall it is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the single parameter 'account' as optional with a default, adding clear meaning beyond the schema which has 0% description coverage. This compensates well for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a detailed profile with specific fields (DOB, partners, sales city, mile expiration, million-miler stats). The verb 'get' and resource 'profile details' are explicit, and the listed fields distinguish it from siblings like get_account_summary.
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 indicates when to use it (for detailed profile) and notes the account parameter is optional with a default. However, it does not explicitly state when not to use the tool or compare it to siblings like get_account_summary, leaving some ambiguity for the agent.
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?
With no annotations provided, the description carries the full burden. It discloses that records are returned as activity cards with selected fields, includes pagination details (starting_index, page_size with server cap ~50), and describes filtering (search_string). While it does not explicitly mention authentication or rate limits, it is fairly transparent for a read operation.
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 starts with a clear one-sentence summary, followed by parameter docs in a bullet-like format. It is well-structured and front-loaded, though a bit verbose. Each sentence adds value, but minor trimming could improve conciseness.
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?
An output schema exists (not shown in detail), so the description does not need to explain return values. It covers all parameters, pagination, and filtering. It lacks explicit error handling or exact output format details, but is otherwise complete for the use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the tool description provides detailed semantics for all 7 parameters: data types, defaults, inclusive date format YYYY-MM-DD, allowed values for sort_direction ('asc'/'desc'), and usage notes (server caps page_size ~50, optional account). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns AAdvantage mile/loyalty-point transaction history with specific fields (date, type, miles earned/used, etc.). This distinguishes it from siblings like get_account_summary or get_loyalty_points_progress, which cover summaries or progress rather than detailed transaction history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving transaction history in a date range, but does not explicitly state when to use it over alternatives, nor does it mention when not to use it. The sibling list provides indirect context, but the description itself lacks explicit guidance.
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?
Describes validation of first+last name against lead passenger and lists return fields. Since no annotations exist, description carries burden; could explicitly state read-only but adequately covers behavioral aspects.
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?
Well-structured: summary, return contents, behavioral note, parameter list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a lookup tool; covers purpose, behavior, parameters, and return fields. Output schema exists so return details are bonus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds examples and explanations for all parameters (e.g., '6-character PNR', lead passenger name), significantly enhancing schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Full reservation details by record locator + lead passenger name', specifying the verb, resource, and lookup method. Unique among siblings.
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?
Implies usage as a lookup tool but does not provide explicit when-to-use or alternatives. No exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool connects via CDP, saves all aa.com cookies, and depends on an external browser session. Does not specify overwrite behavior, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: one-liner purpose, numbered workflow, then parameter docs. Every sentence adds value, no fluff, 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?
Given the tool's complexity (requires prior steps, state-changing), the description covers prerequisites, workflow, and parameters. There is an output schema, so return value need not be explained. Could mention multiple runs, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description adds value by explaining each parameter's purpose (account name, port) and details why port should be passed as string, with defaults clearly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool pulls cookies from a Chromium browser started by aa-auth-browser and saves them. It includes a workflow that differentiates it from sibling tools (e.g., check_auth_status are read-only queries).
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?
Explicit workflow steps are provided: run aa-auth-browser, log in, then call this tool. While no direct alternatives are mentioned, the context makes usage clear. Lacks explicit when-not-to-use, but strong for its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes return payload structure and pricing behavior. Does not explicitly state that this is a pure search (read-only) operation, which could cause ambiguity about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with high-level purpose first, then detailed return description, warnings, and parameter list. Slightly long but each section adds necessary information. Concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and output schema existence, the description covers return format, pricing details, split PNR caveats, and parameter explanations thoroughly. Leaves minimal gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the 'Args' section explains each parameter with format and constraints (e.g., 6-character PNR, YYYY-MM-DD for dates, meaning of slice_index and carousel_days). Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'search alternative flights for an existing reservation (the 'change flight' flow)', with specific verb and resource. Distinguished from sibling tools like get_reservation_by_locator which is about viewing reservations, not changing.
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?
Explains when to use for change flight flow, gives context on pricing scope and PNR splitting. Does not explicitly state when not to use, but provides enough context with alternatives like needing an agent for partial changes.
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:

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

Score Badge

Copy to your README.md:

[![aa-mcp MCP server](https://glama.ai/mcp/servers/thehesiod/aa-mcp/badges/score.svg)](https://glama.ai/mcp/servers/thehesiod/aa-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thehesiod/aa-mcp'

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