@striderlabs/mcp-american

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, such as search_flights, select_flight, and select_seats. The only potential confusion is between status and get_aadvantage, both involving account state, but descriptions effectively separate authentication status from loyalty account details.
Naming Consistency4/5
The majority of tools follow a verb_noun pattern (e.g., search_flights, get_reservation, cancel_trip), but some exceptions like logout, login, checkout, status, and upgrade_request deviate from this pattern. Overall, the naming is consistent in style and readable, though not perfectly uniform.
Tool Count4/5
With 17 tools, the server covers the full travel lifecycle from searching and booking to checking in and managing loyalty status. While slightly above the typical 3-15 range, each tool addresses a distinct need and the count is justified by the broad domain.
Completeness3/5
The tool set provides core coverage for booking, reservation management, and check-in, with useful extras like seat maps and upgrades. However, it lacks explicit tools for adding or managing passengers and for selecting payment methods, which are notable gaps for a comprehensive booking assistant.
Average 3.9/5 across 17 of 17 tools scored. Lowest: 3.2/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
- No stable releases found
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the lookup action. It does not mention whether authentication is required, that lastName is needed for unauthenticated lookups (though schema mentions), or what kind of data is returned. Lacks transparency about side effects or limitations.
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 concise sentence that front-loads the purpose without unnecessary words. Every word contributes.
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 no output schema, the description does not explain what the agent should expect as a return value (e.g., reservation details). It also lacks usage context such as preconditions like being logged in. The schema partially compensates by explaining lastName, but the description is incomplete for a tool that needs to be invoked 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?
The input schema fully describes both parameters with examples and notes on lastName requirement, so description adds no new semantic meaning. The mention of 'record locator' in the description is duplicated from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'look up' and resource 'existing American Airlines reservation', and identifies the key parameter 'record locator (confirmation code)'. This differentiates it from sibling tools like search_flights or get_flight_details.
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, such as using get_boarding_pass for boarding passes or check_in for check-in. There is no mention of exclusions or prerequisites.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions availability timing but fails to disclose that check-in is a mutation that modifies the reservation, may generate a boarding pass, or could fail if already checked in. This leaves critical side effects undocumented.
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 concise sentences with the primary action front-loaded. Every word earns its place, and it avoids redundancy with the schema.
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?
While the description covers purpose and timing, it lacks information about preconditions (e.g., having an active reservation), effects, or return value. Given the absence of an output schema and annotations, more detail is needed for a fully self-contained tool description, though it is minimally viable.
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 provides 100% coverage with clear descriptions for both parameters ('Passenger last name' and 'The 6-character confirmation code'). The description adds no parameter-specific information, 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 clearly states the specific action with a verb and resource: 'Complete online check-in for an American Airlines flight.' This distinguishes it from sibling tools like get_boarding_pass or select_seats, and the airline specificity adds useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear temporal guideline ('Available starting 24 hours before departure'), which tells the agent when to use it. However, it does not explicitly mention alternatives or when not to use it, though the context is strong enough for a 4.
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 implies a read-only view operation but does not explicitly state it is read-only or disclose any behavioral traits such as side effects, prerequisites (e.g., a flight must already be selected), or error conditions. The description only lists the content shown, which is minimal for transparency.
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, front-loaded sentence with no fluff. It efficiently conveys the action and the output content. It could be slightly tighter by removing 'available and occupied' since 'seat map' implies it, but it's still concise and well-structured.
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 (1 optional parameter, no output schema, no annotations), the description is largely complete. It explains what the tool shows, and the context of a 'selected flight' covers the precondition. It does not detail fee amounts or how to interpret seat types, but that is beyond what a brief description should provide.
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 schema fully documents the single optional parameter flightNumber with a description (100% coverage). The description's phrase 'for the selected flight' loosely relates to the parameter but adds no additional meaning beyond the schema. Baseline 3 is appropriate since the schema handles the parameter 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 a specific verb ('View') and resource ('seat map'), and specifies the scope: 'for the selected flight'. It also lists what the seat map shows (available/occupied seats, seat types, fees), distinguishing it from sibling tools like select_seats or get_flight_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for the selected flight' provides clear context on when this tool is applicable, but there is no explicit comparison to alternatives or exclusions. It is clear that this is for viewing the seat map rather than selecting or modifying seats, but it does not explicitly say 'use this instead of X'.
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 must disclose side effects. It implies a mutation (selecting seats) but does not state whether it is reversible, requires payment, or how it affects the reservation. Only the prerequisite of viewing the seat map is mentioned.
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 purpose and a useful pointer to get_seat_map. No wasted words or redundant information.
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 is simple with clear parameters, but the lack of annotations and output schema means the description should explain outcomes or side effects. It provides the essential workflow but leaves gaps about post-selection behavior.
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 100% with descriptions for both parameters. The description adds no additional parameter detail beyond the schema, so it meets the baseline for high schema coverage.
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 'Choose' with a clear resource 'seats for passengers' and ties it to the selected flight, making it distinct from siblings like get_seat_map (viewing) and select_flight (choosing the flight).
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?
It explicitly instructs to use get_seat_map first, establishing a clear prerequisite and sequencing. It does not mention exclusions or alternative tools beyond that, but the context is sufficient for basic usage.
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 carries the transparency burden. It discloses that it returns eligibility and waitlist position, but it does not mention whether the request modifies the reservation, deducts miles immediately, or incurs fees, which are significant behavioral traits for a tool that handles upgrades.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource, and includes a concise summary of return behavior. Every word earns its place, with no filler or redundancy.
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 lacks an output schema, but the description does mention return values. However, it omits key context such as prerequisites, whether miles are deducted, and what happens after the request. Given the tool's potential financial impact, this is a notable gap that prevents a higher score.
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?
All three parameters have schema descriptions, and the description references upgrade types via 'using miles or elite status,' but it adds no additional semantic detail beyond the schema. The upgradeType enum is self-explanatory, so the description provides only marginal value here.
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 ('Request') and resource ('upgrade on an American Airlines flight'), clearly distinguishing it from sibling tools like cancel_trip or select_seats. It also specifies the method (miles or elite status) and the expected outcome (eligibility and waitlist position).
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 when a user wants to upgrade a flight, but it does not explicitly state when to use this tool versus alternatives or any exclusions. No guidance is provided on prerequisites such as being checked in, fare eligibility, or when an upgrade request is appropriate.
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 must carry full behavioral disclosure. It states the action and a key business rule (AA charges per bag per segment), but it doesn't mention side effects like modifying the booking total, potential irreversibility, or permissions. It adds some value but leaves significant context undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately stating the purpose and a critical cost detail. No wasted words; front-loaded with the verb and object.
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 two-parameter tool with full schema coverage, the description provides sufficient context: what it does, the cost rule, and implicit modification of a booking. It doesn't explain return values or error conditions, but given no output schema and low complexity, this is acceptable.
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 100% with both 'bags' and 'passenger' described. The description adds no parameter-specific details beyond what the schema already provides. Baseline of 3 applies as the schema does the heavy lifting.
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 function with a specific verb and resource: 'Add checked baggage to the booking.' It distinguishes itself from siblings by focusing on baggage addition, and the cost note adds clarity. No ambiguity.
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?
Usage is implied from the purpose—when one needs to add checked baggage—but there is no explicit guidance on when not to use it or mention of alternative tools. The description doesn't discuss prerequisites or relationship to sibling tools like modify_trip.
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 carries the transparency burden. It discloses that the tool 'initiates the flight change flow,' indicating a multi-step process, but does not explain the full outcome, required permissions, or whether the change is immediately applied. This is some context but leaves significant ambiguity.
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 main purpose and followed by a practical prerequisite. No wasted words; every part contributes to understanding.
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?
Despite clear purpose and schema, the description omits information about the flow's next steps, what the tool returns (no output schema), and how the change is completed. Given the tool's complexity and lack of annotations, this is a notable gap for an agent to know what to expect.
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 100%, and each parameter has a description (e.g., recordLocator, newDepartureDate). The tool description adds no extra parameter nuance, but the schema already documents what each field means, 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 clearly states the tool changes flights on an existing American Airlines reservation, using a specific verb ('change') and resource ('existing reservation'). It distinguishes itself from sibling tools like cancel_trip and search_flights by focusing on modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing to use search_flights to find new options before changing flights. It implies a workflow but does not explicitly state when not to use, such as for cancellations or check-ins, though sibling names make this inferable.
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 the full burden. It does disclose the preview vs. confirm behavior and warns about user confirmation, but this largely restates the input schema's parameter description. It does not explicitly mention possible consequences like irreversibility or financial implication, which would be valuable for a high-stakes action.
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 concise sentences, front-loaded with the primary purpose, followed by the essential usage warning. Every sentence earns its place without unnecessary detail.
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 description explains the preview behavior when confirm is false, but it does not specify what is returned when confirm=true (e.g., a booking reference or confirmation status). Since there is no output schema, this missing success-path information is a gap, though the tool is simple and the context is largely implied.
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 100% because the sole parameter 'confirm' has a detailed description. The tool description adds nothing beyond what the schema already specifies about the parameter's behavior, 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 clearly states the tool's purpose with a specific verb and resource: 'Complete the American Airlines booking.' This distinguishes it from sibling tools like select_flight, modify_trip, or cancel_trip, which handle different stages of the booking lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear and critical usage guideline: set confirm=true only after explicit user confirmation, and without it the tool returns a preview. However, it does not explicitly mention when to use this tool versus alternatives, though the purpose implies it is for finalizing a booking.
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 without confirm=true the tool returns a preview, and emphasizes that confirm=true should only be set after explicit user confirmation. This transparently conveys the destructive nature and the safeguard mechanism, which goes beyond basic information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that state the purpose and critical safety instruction without waste. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the essential behavior (preview vs actual cancellation) and the confirmation requirement, which is adequate for a destructive tool with this schema. It does not explain return values in detail, but no output schema exists and the preview behavior is mentioned. Given the tool's complexity, it is sufficiently 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% for all three parameters. The description adds no additional meaning beyond the schema; it repeats the confirm preview behavior and the warning, which are already in the schema. Therefore, 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's function: 'Cancel an American Airlines reservation.' This distinguishes it from sibling tools like modify_trip or check_in, as it specifically names the cancel action and the resource (reservation).
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 (when you want to cancel a reservation) and includes the important safety instruction about confirm=true, but it does not explicitly discuss when to use this tool versus alternatives like modify_trip. It provides context for safe usage but lacks explicit exclusions or alternative recommendations.
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?
There are no annotations, so the description must convey behavior. It states a key precondition (authentication) and implies a read-only operation via 'Check.' However, it does not disclose output format, error behavior, or any side effects, which are relevant for an unannotated tool.
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 short sentences that are front-loaded with the action and resource. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, the description covers the purpose and a precondition. It lacks explicit return-value details, but the summary of what is checked (balance, status, summary) sufficiently conveys the expected output for a basic check.
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 input schema has zero parameters, so there is nothing to clarify. The description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and clearly identifies the resource: AAdvantage miles balance, elite status, and account summary. This distinguishes it from sibling tools like get_reservation or status by specifying the exact domain (AAdvantage account).
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 only guidance is 'Requires being logged in,' which is a prerequisite rather than a when-to-use instruction. It does not explicitly compare with alternatives like status or get_reservation, so the agent must infer from the domain.
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 provided, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'Retrieve' and adds the prerequisite of prior check-in, but does not disclose return format, error behavior for un-checked-in passengers, or any other side effects. This is adequate but not rich.
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 concise sentences with the verb front-loaded. Every word adds value, and there is no redundant information or repetition of schema details.
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 retrieval tool with complete schema coverage and no output schema, the description provides the core purpose and a key prerequisite. It doesn't explain return values, but that isn't required given the simplicity of the operation. It could mention what the boarding pass contains, but the description is sufficiently complete for an agent to understand when to use it.
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 fully describes both parameters (recordLocator and lastName) with clear descriptions and an example. The description adds no additional parameter context, but the schema alone provides high coverage, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('digital boarding passes for a checked-in flight'), distinguishing it from sibling tools like check_in and get_reservation. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes 'Requires prior check-in', which clearly indicates when this tool is appropriate. Although it doesn't name alternative tools, the precondition is a clear usage guideline that separates it from check-in related actions.
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 the full burden. It lists the types of information returned, which gives some transparency about the tool's output. However, it does not explicitly state that this is a read-only operation, describe error behavior, or mention any prerequisites beyond having a flightId.
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. It front-loads the purpose ('Get detailed information about a specific flight') and then lists the key content categories without unnecessary elaboration.
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 parameter, no output schema), the description is fairly complete. It covers the purpose and the main output categories. It lacks explicit statements about read-only behavior or invalid ID handling, but these are minor gaps for a straightforward retrieval tool.
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 schema already covers the sole parameter (flightId) with a clear description and example ('0', '1', '2'). The description adds no new parameter-level detail—it merely repeats the 'from search results' context. With 100% schema coverage, a 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 function: 'Get detailed information about a specific flight from search results.' It names specific content areas (connection info, aircraft type, baggage policy, fare rules), which distinguishes it from sibling tools like search_flights (list flights) and select_flight (select for booking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from search results' clearly indicates the tool should be used after obtaining a flight ID from search_flights. It provides context for when to use it, but does not explicitly mention alternatives or exclusions (e.g., when to use get_seat_map instead).
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 is the primary source of behavioral info. It discloses the return content (flight numbers, times, stops, aircraft, fares), implying a read-only operation. It doesn't mention authentication or rate limits, but for a search tool this is acceptable.
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 concise sentences with no wasted words. It front-loads the action and resource, then states the output.
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 complexity of 8 parameters and no output schema, the description is adequate. It states the purpose, scope, and return values, though it could mention the need for origin/destination/date, but the schema already covers that.
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 schema provides full descriptions for all 8 parameters with 100% coverage, so the description adds no additional parameter-specific semantics. It only describes output fields, not parameter usage.
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 function with the verb 'Search' and the resource 'flights', and narrows scope to 'American Airlines (aa.com)'. It also lists the return fields, distinguishing it from sibling tools like get_flight_details and select_flight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the context: searching for flights on American Airlines. It does not explicitly mention alternatives or when not to use it, but the scope is clear. Since it says 'Search', it implicitly contrasts with selection/detail 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?
With no annotations, the description carries the burden of disclosure. It explicitly states that this tool modifies state by 'adds the flight to your booking session', which is a key behavioral trait. It doesn't discuss idempotency or error handling, but it gives enough for an agent to understand the side effect.
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 concise sentences, front-loaded with the primary action and immediately providing context and outcome. Every word adds value, with no redundancy 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?
The tool has simple parameters and no output schema, and the description covers the essential context: when to use it (after searching) and what it does (adds to the booking session). It doesn't explicitly mention return values or errors, but for this type of selection tool, the description is sufficiently complete for agent use.
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% for both parameters, so the schema already explains the meaning and roles of outboundFlightId and returnFlightId. The description only loosely mirrors these ('outbound and optionally a return'), adding no new semantic detail, 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 action ('Select') and the resource ('an outbound and optionally a return flight'), and it specifies the context ('after searching') and the effect ('adds the flight to your booking session'). This distinguishes it from sibling tools like search_flights and get_flight_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to use this tool 'after searching', implying search_flights is a prerequisite. It also clarifies that returnFlightId is optional for round trips, giving guidance on when to include it. However, it doesn't explicitly name search_flights or mention alternative tools for when not to use this, so it's not a full 5.
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 carries the full burden. It implies a read-only operation (checking status) and mentions session info, but does not explicitly state that it has no side effects or what exact behavior to expect. It adds value but could be more explicit about non-destructiveness or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose and followed by a usage guideline. Every word earns its place with no redundancy.
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, parameterless tool, the description is largely complete. It states what it does and when to use it. It could optionally specify what is returned (e.g., boolean or session details), but the lack of an output schema means this is not strictly required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is trivially complete. The description does not need to explain parameters, and the baseline of 4 applies for no-parameter tools.
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 the specific verb 'Check' and clearly identifies the resource: 'American Airlines login status and AAdvantage session info.' It distinguishes from siblings like 'login' and 'get_aadvantage' by focusing on session status rather than the login action or account details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to verify authentication before performing other actions.' This provides clear usage context, though it does not name alternatives or specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool opens aa.com for manual user login (not automated), and that the session should be verified via status. It does not mention edge cases like cancellation or already being logged in, but it gives essential 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 three concise sentences, each adding value: the purpose, the manual login mechanism, and the required follow-up. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately explains the workflow and the next step. Minor gaps exist (e.g., handling of login cancellation), but it is sufficiently complete for an agent to understand how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% and the description is not required to explain parameter semantics. The baseline of 4 applies, and no further parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates the American Airlines login flow, specifically opening aa.com for manual AAdvantage login. This distinguishes it from sibling tools like logout and status, which are clearly different actions.
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?
It provides clear context that the tool is for starting a manual login process and explicitly instructs to call status afterward to verify and save the session. No explicit exclusions or alternatives are mentioned, but the flow is well described.
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, the description carries the full burden. It discloses that it clears session and cookies and resets auth state, which is transparent about the destructive effect on local authentication. It doesn't mention server-side effects, but this is adequate for a logout tool.
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 concise sentences, front-loaded with the action. Every word adds value; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logout tool with no parameters and no output schema, the description fully covers what it does and when to use it. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to add parameter details. The baseline for 0 params is 4, and the description appropriately focuses on behavior rather than params.
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 clears saved American Airlines session and cookies, which is a specific action on a specific resource. It distinguishes itself from siblings like login and other flight-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to log out or reset authentication state,' giving clear when-to-use guidance. It doesn't mention alternatives, but no direct alternative exists among the siblings.
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:

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

Score Badge

Copy to your README.md:

[![mcp-american MCP server](https://glama.ai/mcp/servers/markswendsen-code/mcp-american/badges/score.svg)](https://glama.ai/mcp/servers/markswendsen-code/mcp-american)

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/markswendsen-code/mcp-american'

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