Delta Air Lines MCP Server

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 distinct purposes with clear boundaries (e.g., search_flights vs. select_flight vs. get_flight_details). However, some overlap exists: manage_booking includes 'add baggage' functionality, which could be confused with the dedicated add_bags tool, and get_booking vs. manage_booking might cause minor confusion about which to use for viewing details.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout (e.g., search_flights, get_booking, add_bags, select_seats). All tools use snake_case with clear, descriptive verbs, making the set predictable and easy to understand.
Tool Count5/5
With 17 tools, the count is well-suited for a comprehensive airline operations server. It covers the full booking lifecycle (search, select, checkout), management (get_booking, manage_booking), check-in (check_in, get_boarding_pass), and account features (login, get_skymiles), without feeling bloated or sparse.
Completeness5/5
The toolset provides complete coverage for Delta Air Lines operations: flight search and booking (search_flights, select_flight, checkout), booking management (get_booking, manage_booking), check-in and boarding (check_in, get_boarding_pass, get_seat_map, select_seats), flight details and status (get_flight_details, get_flight_status), account management (login, logout, status, get_skymiles), and extras (add_bags, get_trip_extras). No obvious gaps exist for core airline workflows.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.9/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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pricing and membership benefits, which adds some context, but fails to describe critical behaviors such as whether this is a read-only or mutation operation, what happens on success/failure, or any rate limits or authentication requirements. For a tool that likely modifies a booking, this is a significant gap.
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 appropriately sized with two sentences that convey essential information (purpose and pricing/benefits) without unnecessary details. It is front-loaded with the core purpose, though the second sentence could be more tightly integrated to improve flow.
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 lack of annotations and output schema, the description is incomplete for a tool that likely performs a mutation (adding baggage). It omits critical context such as return values, error conditions, dependencies on other tools (e.g., requiring a booking ID), or how it fits into the broader workflow with sibling tools. The pricing info is helpful but insufficient for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter documentation (e.g., 'bags' as 'Number of checked bags to add (0-4)'). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'passengers' interacts with 'bags' or clarifying pricing per passenger. This meets the baseline score of 3 when schema coverage is high.
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's purpose with a specific verb ('Add') and resource ('checked baggage to your booking'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_trip_extras' or 'manage_booking', which might also handle baggage-related operations.
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. While it mentions pricing and Medallion member benefits, it doesn't specify prerequisites (e.g., must have an existing booking), exclusions, or direct comparisons to sibling tools like 'manage_booking' that might offer similar functionality.
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 of behavioral disclosure. While it lists possible actions, it doesn't describe what each action entails (e.g., cancellation policies, upgrade availability, baggage fees), required permissions, rate limits, or response formats. 'Modify' implies mutation, but specifics are missing.
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, efficient sentence that front-loads the core purpose ('Modify an existing Delta booking') and lists key actions. It avoids redundancy, though it could be slightly more structured (e.g., separating actions with commas instead of em dashes). Every word 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?
Given the complexity (multiple mutation actions), lack of annotations, and no output schema, the description is incomplete. It doesn't explain behavioral details, error conditions, or what to expect after actions like 'cancel' or 'upgrade'. For a multi-action tool with no structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond implying that actions like 'view' might not require 'lastName', which is partially covered by the schema's 'required for some actions' note. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Modify an existing Delta booking' followed by specific actions (view details, cancel, change flights, request upgrades, or add baggage). It uses a specific verb ('Modify') and resource ('Delta booking'), but doesn't explicitly distinguish it from sibling tools like 'get_booking' or 'add_bags' which handle similar operations.
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. It doesn't mention prerequisites (e.g., authentication), when not to use it, or how it differs from sibling tools like 'get_booking' (for viewing) or 'add_bags' (for baggage). The agent must infer usage from the action list alone.
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 of behavioral disclosure. It states the tool is for viewing (implying read-only), but doesn't cover critical aspects like authentication needs (e.g., whether login is required), rate limits, error conditions, or what happens if parameters are missing. For a tool with zero annotation coverage, this is inadequate, scoring 2 for minimal transparency beyond the implied 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('View the aircraft seat map') and specifies key details without waste. Every word earns its place, making it highly concise and well-structured, deserving a score of 5.
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 moderate complexity (viewing seat maps with two optional parameters), no annotations, and no output schema, the description is partially complete. It covers the purpose and data shown but lacks usage guidelines, behavioral details, and output information. This results in a score of 3, as it's minimally adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., it doesn't clarify the relationship between flightNumber and flightId or when one is preferred). According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description, which applies here.
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's purpose with the verb 'View' and resource 'aircraft seat map', specifying what information is shown (available/occupied seats, seat types, upgrade pricing). It distinguishes itself from siblings like 'select_seats' (which implies action) and 'get_flight_details' (which is more general), but doesn't explicitly name alternatives. This earns a 4 for being clear but lacking explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a booking is required), timing (e.g., before seat selection), or exclusions. With siblings like 'select_seats' and 'get_flight_details' available, this omission is a significant gap, resulting in a score of 2 for no usage guidance.
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 states this is a 'View' operation, implying read-only behavior, but doesn't clarify if it requires authentication, what data format it returns (e.g., list of add-ons with prices), or any rate limits. The description adds minimal context beyond the implied read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action ('View') and lists specific examples of add-ons. It is appropriately sized with zero wasted words, making it easy to scan and understand quickly.
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 low complexity (0 parameters, no output schema, no annotations), the description is complete enough to convey its basic purpose. However, for a tool that likely requires context like a booked trip or user session, it lacks details on prerequisites or return format, leaving gaps in usability for an AI agent.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, which is efficient. A baseline of 4 is applied since no parameter information is needed, and the description doesn't mislead about inputs.
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's purpose with specific verbs ('View') and resources ('available upgrade options, Wi-Fi passes, priority boarding, and other add-ons for your trip'), making it easy to understand what it does. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_booking' or 'get_flight_details', which might also provide trip-related information.
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 implies usage context by mentioning 'for your trip', suggesting it should be used when a trip is booked or in progress. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., 'get_booking' for general booking info or 'get_flight_details' for flight specifics), nor does it mention prerequisites like needing a logged-in session or booking reference.
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 mentions this 'begins the booking process', implying a state change or reservation initiation, but doesn't disclose critical behavioral traits: whether this creates a temporary hold, requires payment, affects availability, has time limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core action and purpose. Every word earns its place: 'select' (verb), 'outbound (and optionally return) flights' (resource), 'from search results' (source), 'to begin the booking process' (goal). No wasted words or redundancy.
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 this is a mutation tool (implied by 'select' to begin booking) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, side effects, or dependencies. For a tool that likely changes system state in a booking workflow, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds minimal value beyond the schema: it clarifies that flights come 'from search results' and that returnFlightId is for 'round trips', but doesn't provide additional syntax, format, or validation details. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('select outbound (and optionally return) flights') and resource ('from search results'), with a specific purpose ('to begin the booking process'). It distinguishes from siblings like 'search_flights' (which finds flights) and 'select_seats' (which picks seats), but doesn't explicitly differentiate from all booking-related tools like 'checkout' or 'manage_booking'.
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 context by mentioning 'from search results' and 'to begin the booking process', suggesting it should follow 'search_flights' and precede other booking steps. However, it doesn't explicitly state when to use this vs. alternatives like 'checkout' or 'manage_booking', nor provide exclusions or prerequisites beyond the implied search step.
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 describes the type of information returned but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication (implied by context but not stated), rate limits, error conditions, or response format. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the purpose and lists key details without waste. Every part earns its place by specifying the action, target, and included information types.
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 moderate complexity (retrieving detailed flight info), no annotations, and no output schema, the description is minimally adequate. It covers what information is returned but lacks details on behavior, authentication, or output structure, leaving room for improvement to fully guide an agent.
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 doesn't add meaning beyond the input schema, which has 100% coverage and fully documents the 'flightId' parameter. The baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with additional context like valid ID ranges or examples 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 verb ('Get') and resource ('detailed information about a specific flight'), specifying what information is retrieved (aircraft type, layover details, baggage policy, fare rules). It distinguishes from siblings like 'get_flight_status' (status only) or 'search_flights' (multiple flights), but doesn't explicitly contrast them.
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 by mentioning 'flight result ID from search_flights', suggesting it should be used after a search to get details for a specific result. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_booking' or 'get_flight_status', nor does it provide 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 full burden but only states basic functionality. It doesn't disclose behavioral traits like authentication requirements (implied by sibling 'login' tool), rate limits, whether results are cached/live, error conditions, or pagination behavior beyond 'maxResults'. The description is minimally adequate but lacks important operational 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?
Two concise sentences with zero waste: first sentence defines purpose and key parameters, second sentence specifies return values. Information is front-loaded and every word earns its place. No redundant or verbose language.
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?
For a search tool with 8 parameters, no annotations, and no output schema, the description is minimally complete. It covers basic purpose and return types but lacks context about authentication (implied by 'login' sibling), result format details, error handling, or operational constraints. The description should provide more guidance given the tool's complexity and lack of structured metadata.
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%, providing detailed parameter documentation. The description adds minimal value beyond schema by mentioning origin, destination, and travel dates as key parameters, but doesn't explain parameter interactions (e.g., 'returnDate' optionality) or provide additional semantic context. Baseline 3 is appropriate given comprehensive 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 clearly states the specific action ('Search for Delta flights'), the resource ('flights'), and key parameters ('by origin, destination, and travel dates'). It distinguishes this search tool from sibling tools like 'get_flight_details' or 'get_flight_status' by emphasizing comprehensive flight search with availability and pricing.
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 finding available flights with pricing, but provides no explicit guidance on when to use this versus alternatives like 'get_flight_details' for specific flights or 'select_flight' for booking. It mentions returning flight information but doesn't specify prerequisites or exclusions.
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 implies a write operation ('Choose') but doesn't specify if this is a tentative hold, a confirmed booking, or requires payment. It also lacks details on permissions, error handling, or rate limits, leaving significant gaps for a tool that likely 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which are essential: the first states the purpose, and the second provides critical usage guidance. There is no wasted verbiage, and it is front-loaded with the core action.
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 complexity of a seat selection tool with no annotations or output schema, the description is minimally adequate. It covers purpose and a key prerequisite but lacks details on behavioral outcomes (e.g., confirmation status) and error conditions. For a state-changing tool, this leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (e.g., 'seats' as an array of strings, 'passengerCount' with a default). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Choose specific seats') and the resource ('for passengers'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_seat_map' by focusing on selection rather than viewing availability. However, it doesn't specify what happens after selection (e.g., reservation confirmation), keeping it from a perfect score.
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 explicit guidance to 'Use get_seat_map first to see availability,' which clearly indicates a prerequisite and distinguishes it from that sibling tool. However, it doesn't mention when not to use it (e.g., if seats are already booked) or alternatives like 'manage_booking,' so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'real-time status' which implies dynamic data, but does not disclose behavioral traits like rate limits, authentication needs, error conditions, or whether it requires an active session (e.g., from 'login'). For a tool with no annotations, this leaves significant gaps in understanding how it behaves operationally.
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, efficient sentence that front-loads the core purpose and lists key information types without unnecessary words. Every element ('real-time status', specific data points) earns its place by clarifying scope and utility.
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 no annotations and no output schema, the description provides basic purpose and parameter context but lacks completeness for a tool that likely interacts with external systems. It does not cover return values, error handling, or prerequisites (e.g., authentication), which are important for an agent to use it correctly in a flight-related context with sibling tools like 'login'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (flightNumber format, date format and default). The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid flight numbers beyond the schema's 'e.g., DL 123 or 123' or constraints on date ranges. Baseline 3 is appropriate 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 specific action ('Get real-time status') and resource ('for a Delta flight'), with explicit details on what information is included (departure/arrival times, gate information, delays, baggage claim). It distinguishes from sibling tools like 'status' (generic) and 'get_flight_details' (likely broader details) by focusing specifically on real-time operational status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'real-time status' and listing the types of information retrieved, which helps differentiate it from tools like 'get_booking' (reservation data) or 'get_flight_details' (possibly static details). However, it does not explicitly state when not to use this tool or name alternatives, such as clarifying if 'status' is a duplicate or different.
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 full burden. It discloses the return content (flight details, passenger info, booking status) which is valuable, but doesn't mention authentication requirements, error conditions, or rate limits. 'Retrieve an existing' implies read-only but isn't explicit about safety.
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 with zero waste: first states purpose and input, second specifies return values. Front-loaded with core functionality. Every word earns its place.
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 single-parameter read tool with no output schema, the description provides good context: purpose, input, and return content. However, without annotations or output schema, it could benefit from mentioning authentication needs or error handling for 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?
Schema description coverage is 100%, so the schema already documents the single parameter fully. The description adds no additional parameter semantics beyond what's in the schema (confirmation number format example). Baseline 3 is appropriate when 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 specific action ('Retrieve'), target resource ('Delta booking'), and key identifier ('by confirmation number'). It distinguishes from siblings like get_flight_status (status only) or get_flight_details (flight-specific) by focusing on the complete booking record.
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 need booking details via confirmation number, but doesn't explicitly state when to use this vs. alternatives like manage_booking (for modifications) or get_flight_status (for status only). No exclusion criteria or prerequisites are mentioned.
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 full burden. It discloses key behavioral traits: 'Opens the Delta sign-in page' (implies a UI interaction) and 'saves your session' (implies state persistence). However, it lacks details on authentication requirements, error handling, or rate limits, leaving gaps for a login 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 front-loaded with the main purpose, followed by additional context in two concise sentences. Every sentence adds value: the first explains the action, the second provides usage guidance. There is no wasted text.
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 complexity (login flow with session management) and no annotations or output schema, the description is somewhat complete but lacks details on return values, error cases, or prerequisites. It covers the basic flow but could benefit from more behavioral context for a secure operation.
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 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary details.
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's purpose: 'Initiate Delta Air Lines login flow' and 'saves your session'. It specifies the action (initiate login flow) and resource (Delta Air Lines), though it doesn't explicitly differentiate from sibling tools like 'logout' or 'status' beyond mentioning the latter.
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 context for usage: 'After logging in, use status to verify.' This indicates when to use this tool (to start login) and what to do next, though it doesn't explicitly state when not to use it or compare it to alternatives among siblings.
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 full burden. It discloses key behavioral traits: timing constraint (24-hour window) and success outcome (boarding pass info). However, it lacks details on error conditions, authentication requirements, rate limits, or whether this is a mutating operation (implied but not stated).
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 with zero waste: first states purpose and timing, second states outcome. Front-loaded with essential information, appropriately sized for a simple tool with good schema coverage.
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 2 parameters with full schema coverage and no output schema, the description provides good context: purpose, timing, and success outcome. However, as a mutation tool with no annotations, it should ideally mention authentication needs or error scenarios for full 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?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no format examples or validation rules). Baseline 3 is appropriate when schema does all the work.
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 ('Complete online check-in'), target resource ('for an upcoming Delta flight'), and outcome ('Returns boarding pass info on success'). It distinguishes from siblings like 'get_boarding_pass' (which retrieves without checking in) and 'manage_booking' (broader scope).
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 context on when to use ('Check-in opens 24 hours before departure'), which helps timing decisions. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'get_booking' for pre-check-in info or 'manage_booking' for other modifications.
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 full burden of behavioral disclosure. It states the authentication requirement ('Requires being logged in'), which is valuable context. However, it doesn't describe other behavioral traits like rate limits, error conditions, response format, or whether this is a read-only operation (though implied by 'Check').
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 that are front-loaded with the core purpose and followed by an essential prerequisite. Every word earns its place—no redundancy, no fluff, and it efficiently communicates both what the tool does and when to use it.
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 low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete for a simple read operation. It covers the purpose and authentication need. However, without annotations or output schema, it could benefit from more behavioral context (e.g., response format, error handling) to fully guide the agent.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters, maintaining focus on what the tool does rather than inputs. A baseline of 4 is applied for zero-parameter tools when the description doesn't mislead about inputs.
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 verb ('Check') and resource ('SkyMiles account'), listing exactly what information is retrieved (balance, Medallion status, tier-qualifying miles, recent activity). It distinguishes from sibling tools like 'get_booking' or 'get_flight_status' by focusing on loyalty program data rather than flight operations.
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 context for when to use this tool ('Check your SkyMiles account...') and includes a prerequisite ('Requires being logged in'), which is helpful guidance. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings (e.g., whether 'get_booking' might overlap with 'recent activity').
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 full burden of behavioral disclosure. It mentions the prerequisite (check-in) which is useful context, but does not describe what happens if not checked in, whether it retrieves passes for all passengers or specific ones, or the format/limitations of the digital passes. It adds some value but lacks comprehensive behavioral details.
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 with zero waste—each sentence earns its place by stating the purpose and prerequisite. It is front-loaded with the core function and appropriately sized for the tool's complexity.
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 moderate complexity (2 required parameters, no output schema, no annotations), the description is mostly complete: it states purpose, prerequisite, and distinguishes from siblings. However, it lacks details on output (what the boarding pass contains) and edge cases (e.g., multiple passengers), leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (confirmationNumber and lastName). The description does not add any additional meaning or context about these parameters beyond what the schema provides, such as format examples or relationship between them. Baseline 3 is appropriate when 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 specific action ('Retrieve digital boarding pass(es)') and resource ('for a checked-in flight'), distinguishing it from siblings like get_booking or get_flight_details that handle different aspects of travel. It precisely defines the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Must be checked in first using check_in') and names the prerequisite tool ('check_in'), providing clear guidance on the required sequence of operations. This helps the agent understand it should not be invoked before check-in.
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 full burden. It discloses that this tool checks login status and session info, implying it's a read-only operation without side effects, but lacks details on error handling, response format, or session validity criteria. It adds some context about authentication verification but doesn't fully describe behavioral traits like what happens if not logged in.
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 front-loaded with the core purpose in the first sentence and adds a usage guideline in the second, with no wasted words. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and well-structured.
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 low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete for its purpose. However, it could be more thorough by explaining what the check returns (e.g., session details, expiration) or error cases, which would enhance completeness despite the simple context.
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 0 parameters with 100% schema description coverage, so the schema already documents this fully. The description doesn't need to add parameter details, and it appropriately focuses on the tool's purpose and usage without redundant information, earning a baseline score above 3 for efficient handling of a parameterless tool.
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 specific verbs ('Check', 'verify') and resources ('Delta Air Lines login status', 'SkyMiles session info'), distinguishing it from siblings like login, logout, or get_skymiles by focusing on authentication verification rather than authentication actions or account data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool ('to verify authentication before performing account-specific actions'), which helps differentiate it from siblings such as get_booking or manage_booking that require authentication, making it clear this is a prerequisite check.
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 of behavioral disclosure. It clearly explains the dual behavior (purchase vs preview) and the critical safety requirement for user confirmation before purchase. However, it doesn't mention error conditions, response format, or what happens after purchase completion.
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 with zero waste. The first states the purpose, the second provides critical usage guidance. Every word earns its place, and the structure is front-loaded with the most important information.
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 single-parameter tool with 100% schema coverage but no annotations or output schema, the description provides excellent context about the tool's dual behavior and safety requirements. The main gap is lack of information about return values or error conditions, but given the simplicity of the tool, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'confirm' parameter. The description reinforces the parameter's purpose but doesn't add meaningful semantic information beyond what's in the schema description. Baseline 3 is appropriate when 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 specific action ('Complete the flight booking') and distinguishes it from siblings like 'search_flights' or 'select_seat' by focusing on the final purchase step. It explicitly mentions both the purchase action and preview functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Set confirm=true only when you have explicit user confirmation to purchase' and clarifies the alternative behavior: 'Without confirm=true, returns a preview.' This directly addresses when to use each mode of the tool.
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 full burden. It discloses that the tool clears session data and cookies (destructive behavior) and resets authentication state. However, it doesn't specify whether this requires current authentication, what happens to active sessions, or if there are any side effects beyond clearing data.
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 with zero waste. The first sentence states the action and what gets affected, the second provides clear usage guidance. Every word earns its place.
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 0-parameter authentication management tool with no annotations and no output schema, the description provides good coverage of purpose and usage. It could be more complete by mentioning whether authentication is required to execute logout or what the expected response looks like, but it adequately covers the core functionality.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and 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 specific action ('Clear saved Delta session and cookies') and resource (authentication state), distinguishing it from sibling tools like 'login' which establishes authentication. It goes beyond the tool name 'logout' by explaining what gets cleared.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this to log out or reset authentication state.' This provides clear context for when this tool should be invoked versus alternatives like 'login' or other session management tools.
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-delta MCP server](https://glama.ai/mcp/servers/markswendsen-code/mcp-delta/badges/card.svg)](https://glama.ai/mcp/servers/markswendsen-code/mcp-delta)

Score Badge

Copy to your README.md:

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

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-delta'

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