Flight Ticket MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as getFlightInfo for detailed flight data and getFlightStatus for real-time tracking. However, getAirportFlights and getFlightsInArea could be confused as both query flights in a geographic area, though one uses airport codes and the other uses bounding boxes. The weather tools (getWeatherByCity and getWeatherByLocation) also overlap but are differentiated by input type.
Naming Consistency4/5
Tool names generally follow a consistent verb_noun pattern with 'get' or 'search' prefixes, such as getFlightInfo and searchFlightRoutes. Minor deviations include trackMultipleFlights using 'track' instead of 'get', and getTransferFlightsByThreePlace having a verbose name that breaks the pattern slightly, but overall the naming is readable and predictable.
Tool Count5/5
With 10 tools, the count is well-scoped for a flight ticket server, covering core operations like flight queries, status tracking, weather checks, and route searches. Each tool serves a specific function without redundancy, making the set manageable and appropriate for the domain.
Completeness4/5
The tool surface covers essential flight-related operations, including search, status, weather, and transfers, with no major gaps for typical agent workflows. Minor gaps might include booking or payment tools, but these are outside the scope of query-focused operations, and agents can work around this with the provided tools for information retrieval.
Average 3.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 provided, the description carries full burden but provides minimal behavioral context. It states it's a query operation (implied read-only) and mentions bounding box coordinates, but doesn't disclose rate limits, authentication needs, response format, pagination, or what happens with invalid coordinates. For a tool with 4 parameters and no annotations, this is insufficient.
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?
Two concise sentences with zero waste. The first sentence states purpose, the second explains parameters. It's appropriately sized and front-loaded with the core functionality. No redundant or verbose language.
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?
For a tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers basic purpose and parameter types but lacks critical details like return format, error conditions, coordinate system, and usage context. The agent would struggle to use this effectively without trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions parameters are bounding box coordinates (最小纬度,最大纬度,最小经度,最大经度) which adds meaning beyond the schema's generic number types, but doesn't explain coordinate systems (e.g., WGS84), valid ranges, or ordering requirements. With 4 undocumented parameters, this partial information is inadequate.
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 ('查询' - query) and resource ('航班' - flights) with specific scope ('指定地理区域内' - within a specified geographic area). It distinguishes from siblings like getFlightInfo (specific flight) or getAirportFlights (airport-based), but doesn't explicitly name alternatives. The purpose is unambiguous but lacks 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?
No guidance on when to use this tool versus alternatives. The description mentions the parameter format but doesn't indicate scenarios where this tool is preferred over siblings like searchFlightRoutes or getAirportFlights. There's no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it indicates this is a query/search operation, it doesn't describe what '可用航班信息' (available flight information) includes, whether there are rate limits, authentication requirements, pagination behavior, or what happens when no flights are found. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
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 - a single sentence that efficiently communicates the core functionality. Every word earns its place with no redundant information, making it front-loaded and easy to parse.
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 of flight search (3 required parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what information is returned, how results are structured, whether there are sorting/filtering options, or error conditions. For a search tool with multiple sibling alternatives, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It mentions the three parameters (departure city, destination city, departure date) but provides no additional semantic context beyond their names. No format requirements (e.g., date format, city naming conventions), examples, or constraints are given, leaving parameters largely undocumented.
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 ('查询' - query/search) and resources ('航班信息' - flight information), and identifies the key parameters (departure city, destination city, departure date). However, it doesn't explicitly distinguish this tool from sibling tools like 'getFlightInfo' or 'getTransferFlightsByThreePlace', which appear to be related flight search tools.
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 any prerequisites, exclusions, or comparisons with sibling tools like 'getFlightInfo' or 'getTransferFlightsByThreePlace', leaving the agent with no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 query scope (30km radius) and supported airport codes, but lacks critical details: whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what the output format looks like. For a query tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the core functionality in the first sentence and adds supporting details in the second. There's no wasted text, though it could be slightly more structured (e.g., bullet points for parameters).
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 (query tool with geographic filtering), lack of annotations, and no output schema, the description is incomplete. It misses behavioral traits (e.g., read-only status, rate limits), full parameter documentation, and output details. For a tool with two parameters and no structured support, this leaves significant gaps for an AI 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?
Schema description coverage is 0%, so the description must compensate. It explains 'airport_code' by listing examples (PEK, PVG, CAN) and implies 'flight_type' through context (departures/arrivals), but doesn't detail allowed values or defaults. The description adds some meaning beyond the bare schema, but doesn't fully document both parameters, resulting in a baseline score.
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: '查询指定机场周边30公里范围内的所有航班' (query all flights within 30km of a specified airport). It specifies the verb (query) and resource (flights) with a geographic scope. However, it doesn't explicitly differentiate from sibling tools like 'getFlightsInArea' or 'getFlightInfo', which might have overlapping functionality.
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 minimal usage guidance: it mentions supporting major airport codes like PEK, PVG, CAN, but offers no explicit advice on when to use this tool versus alternatives (e.g., 'getFlightsInArea' or 'getFlightInfo'). There's no mention of prerequisites, exclusions, or comparative context with siblings.
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 mentions the data source (Open-Meteo API) and default date behavior, but doesn't describe important behavioral traits such as rate limits, authentication requirements, error conditions, response format, or what specific weather data is returned. For a tool with 4 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 concise with two sentences that each add value. The first sentence establishes the core purpose and method, while the second provides important default behavior information. There's no wasted language or redundancy, though it could be slightly more structured for clarity.
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 tool's complexity (4 parameters, no output schema, no annotations), the description is insufficiently complete. It covers the basic purpose and default date behavior but misses critical information about parameter formats, return values, error handling, and differentiation from sibling tools. For a weather query tool that likely returns structured data, the lack of output description is particularly problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (none of the 4 parameters have descriptions in the schema), the description provides minimal parameter guidance. It only mentions that dates are optional and have default behavior, but doesn't explain what the latitude/longitude parameters represent (coordinate format, valid ranges), what date format to use, or the relationship between start_date and end_date. The description doesn't adequately compensate for the complete lack of schema documentation.
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: '天气信息查询 - 根据经纬度查询天气信息' (Weather information query - query weather information based on latitude and longitude). It specifies the verb (query) and resource (weather information) with the specific method (using latitude/longitude). However, it doesn't explicitly differentiate from its sibling 'getWeatherByCity' which likely queries by city name instead of coordinates.
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 provides some usage context: '如果不提供日期，默认查询今天和明天的天气数据' (If no date is provided, it defaults to querying today and tomorrow's weather data). This gives guidance on default behavior when parameters are omitted. However, it doesn't explicitly state when to use this tool versus the sibling 'getWeatherByCity' or other weather-related alternatives, nor does it mention any 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions '实时状态' (real-time status) which implies live data retrieval, but doesn't address critical aspects like rate limits, authentication needs, data freshness, error handling, or whether this is a read-only operation. For a tool with no annotations, this leaves significant behavioral gaps.
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 concise with two sentences: one stating the purpose and one explaining the key parameter. There's no wasted text, and the example is helpful. It could be slightly improved by front-loading the purpose more clearly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers the basic purpose and one parameter but misses the optional 'date' parameter, behavioral traits (rate limits, auth, etc.), and output format. For a tool with 2 parameters and real-time data implications, this leaves too many gaps for effective 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 0%, so the description must compensate. It explains 'flight_numbers' as a list of flight call signs with an example ['CCA1234','CSN5678'], which adds meaningful context beyond the bare schema. However, it doesn't mention the optional 'date' parameter at all, leaving half the parameters undocumented. The description provides partial but incomplete parameter semantics.
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: '批量航班跟踪 - 同时查询多个航班的实时状态' (Batch flight tracking - query real-time status of multiple flights simultaneously). It specifies the verb (query/track), resource (flights), and scope (multiple/batch). However, it doesn't explicitly differentiate from siblings like 'getFlightStatus' which might handle single flights.
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. With siblings like 'getFlightStatus' (likely for single flights) and 'getAirportFlights' (airport-specific), there's clear potential for overlap, but the description offers no explicit when/when-not instructions or alternative recommendations.
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 mentions querying detailed information but doesn't specify whether this is a read-only operation, if it requires authentication, rate limits, error handling, or data freshness. For a tool with no annotation coverage, this is a significant gap in 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, efficient sentence that front-loads the core purpose ('航班信息查询') and lists key data points. There's no wasted text, but it could be slightly more structured by separating usage context from data details.
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 of flight data queries, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on return format (e.g., structured data vs. raw text), error cases, and behavioral traits like latency or data sources, making it inadequate for reliable 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?
The input schema has 0% description coverage, so the description must compensate. It adds meaning by specifying that the flight_number parameter is used to query detailed flight info, but it doesn't provide format details (e.g., airline code, number pattern) or examples. This offers basic context but falls short of fully compensating for the schema gap.
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: query detailed flight information based on flight number, listing specific data points like status, seat configuration, price, and weather. It distinguishes from siblings like getFlightStatus (which might only return status) and getAirportFlights (which queries by airport). However, it doesn't explicitly differentiate from all siblings, such as trackMultipleFlights, which might handle multiple flights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating '根据航班号查询' (query based on flight number), suggesting this tool is for single-flight queries. However, it doesn't explicitly state when to use this versus alternatives like getFlightsInArea (for area-based queries) or searchFlightRoutes (for route searches), nor does it mention prerequisites or exclusions, leaving some ambiguity.
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 reveals that the tool defaults to querying today and tomorrow's weather when dates aren't provided, which is useful behavioral context. However, it doesn't mention rate limits, authentication requirements, error conditions, or what happens with invalid city names. The description adds some value but leaves significant behavioral aspects undocumented.
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 concise with two sentences that each serve a clear purpose: the first states the core functionality, the second provides important usage details about supported cities and default date behavior. There's no wasted text, and key information is front-loaded. The structure could be slightly improved with clearer separation of city support vs date behavior.
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 a 3-parameter tool with no annotations and no output schema, the description provides basic but incomplete coverage. It explains the core purpose and some behavioral defaults, but doesn't cover parameter formats, return values, error conditions, or authentication requirements. For a weather query tool that likely returns structured data, the description should ideally mention what weather information is returned (temperature, conditions, etc.) since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description must compensate but only partially does so. It explains that 'city_name' is required and lists example cities, and mentions that date parameters are optional with default behavior when omitted. However, it doesn't explain the format or meaning of 'start_date' and 'end_date' parameters, leaving them largely undocumented. The description adds some semantic value but doesn't fully compensate for the schema coverage gap.
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: '城市天气查询 - 根据城市名查询天气信息' (City weather query - query weather information based on city name). It specifies the verb '查询' (query) and resource '天气信息' (weather information), making the purpose explicit. However, it doesn't explicitly differentiate from its sibling 'getWeatherByLocation' beyond mentioning city-based vs location-based queries.
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 provides some usage context: '支持武汉、北京、上海等主要城市' (supports major cities like Wuhan, Beijing, Shanghai) and '如果不提供日期，默认查询今天和明天的天气数据' (if no date is provided, defaults to querying today and tomorrow's weather data). This gives implied guidance on when to use it (for city-based queries with optional date ranges) but doesn't explicitly state when to choose this over 'getWeatherByLocation' or other alternatives.
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 what the tool does, not behavioral traits like whether this is a read-only operation, what format results return, if there are rate limits, authentication requirements, or error conditions. It mentions default values which is helpful but insufficient for full behavioral understanding.
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 efficiently structured in a single sentence that front-loads the core purpose and lists all parameters with their defaults. Every element serves a purpose with minimal waste, though it could be slightly more polished in phrasing.
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 5 parameters with no schema descriptions, no annotations, and no output schema, the description does a reasonable job explaining the query purpose and parameters but lacks information about return format, result structure, error handling, or any constraints beyond the time defaults. It's adequate but has clear gaps for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 5 parameters, the description adds significant value by listing all parameters (出发地, 中转地, 目的地, 最小转机时间, 最大转机时间) and explaining their purpose in the query context. It also provides default values for time parameters, which compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('查询' - query/search) and resource ('航班中转路线' - flight transfer routes), and distinguishes from siblings by specifying it's for transfer flights with three places (departure, transfer, destination) rather than direct flights, airport flights, or route searches.
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 (when you need transfer flight information with specific transfer place and time constraints) but doesn't explicitly state when to use this vs alternatives like 'searchFlightRoutes' or 'getFlightInfo'. It mentions default values which provide some implicit guidance on typical usage scenarios.
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 the return format ('yyyy-MM-dd 字符串') which is valuable behavioral information. However, it doesn't mention timezone behavior, whether it's server-side or client-side, or any rate limits/authentication needs. It adds some context but leaves gaps.
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?
Perfectly concise - one sentence that states the purpose and key behavioral detail (return format). Zero wasted words, front-loaded with the core function. Every element 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 simple 0-parameter tool that returns a date string, the description is nearly complete. It specifies the return format, which is crucial. Without an output schema, this information is valuable. The main gap is lack of timezone clarification, but otherwise sufficient for the tool's complexity.
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 (empty schema). The description appropriately doesn't discuss parameters since none exist. It focuses correctly on the output behavior. Baseline for 0 parameters is 4.
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 ('获取当前日期' - get current date) and resource (current date), and distinguishes from all sibling tools which are flight/weather-related. It precisely defines what the tool does without being tautological.
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 (when you need the current date in a specific format) but doesn't explicitly state when to use this tool versus alternatives. No sibling tools overlap in functionality, so no explicit differentiation is needed, but no guidance on prerequisites or limitations is provided.
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 it only supports real-time data (date parameter is ineffective), which is a key behavioral trait. However, it lacks details on rate limits, error handling, or response format, leaving gaps in transparency for an API-based query 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 core purpose, followed by specific parameter guidance in a single, efficient sentence. Every part adds value without redundancy, making it 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers the real-time constraint and parameter semantics well, but for a query tool, it should ideally mention the type of data returned (e.g., position, altitude, speed) or potential limitations, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds crucial meaning: it explains that 'flight_number' is the flight call sign (e.g., CCA1234) and that 'date' is ineffective since only real-time data is supported. This clarifies parameter usage beyond the bare 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 specific action ('查询' meaning 'query' or 'retrieve') and resource ('航班实时状态' meaning 'flight real-time status'), and distinguishes it from siblings by specifying it uses OpenSky Network for real-time position and status, unlike other tools that might handle historical data or different queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use this tool: for real-time flight status queries using OpenSky Network, with a flight number as the key input. It implicitly distinguishes from siblings by focusing on single-flight real-time data, but does not explicitly name alternatives or state 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.

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:

[![FlightTicketMCP MCP server](https://glama.ai/mcp/servers/xiaonie7/FlightTicketMCP/badges/card.svg)](https://glama.ai/mcp/servers/xiaonie7/FlightTicketMCP)

Score Badge

Copy to your README.md:

[![FlightTicketMCP MCP server](https://glama.ai/mcp/servers/xiaonie7/FlightTicketMCP/badges/score.svg)](https://glama.ai/mcp/servers/xiaonie7/FlightTicketMCP)

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/xiaonie7/FlightTicketMCP'

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