Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@EMS MCP Server Show me the 10 most recent flights for aircraft N123AB"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that provides LLM access to the EMS (Event Management System) API for flight data analytics.
Python 3.11+
uv package manager
Related MCP server: Flightradar24 MCP Server
git clone <repo-url>
cd ems-mcp
# Create virtual environment
uv venv
# Activate virtual environment
# Windows (cmd):
.venv\Scripts\activate
# Windows (PowerShell):
.venv\Scripts\Activate.ps1
# macOS / Linux:
source .venv/bin/activate
# Install the package
uv pip install -e .This creates an ems-mcp executable inside the virtual environment:
Windows: .venv\Scripts\ems-mcp.exe
macOS / Linux: .venv/bin/ems-mcp
All MCP clients need three values to connect to your EMS server:
Variable | Description |
| EMS server URL (e.g. |
| Your EMS username |
| Your EMS password |
Create a .mcp.json file in the project root:
{
"mcpServers": {
"ems-mcp": {
"command": "C:\\absolute\\path\\to\\ems-mcp\\.venv\\Scripts\\ems-mcp.exe",
"args": [],
"env": {
"EMS_BASE_URL": "https://your-ems-server.com",
"EMS_USERNAME": "your-username",
"EMS_PASSWORD": "your-password"
}
}
}
}Claude Code reads .mcp.json automatically when you open the project directory.
Edit claude_desktop_config.json:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add the server to the mcpServers block:
{
"mcpServers": {
"ems-mcp": {
"command": "C:\\absolute\\path\\to\\ems-mcp\\.venv\\Scripts\\ems-mcp.exe",
"args": [],
"env": {
"EMS_BASE_URL": "https://your-ems-server.com",
"EMS_USERNAME": "your-username",
"EMS_PASSWORD": "your-password"
}
}
}
}On macOS/Linux, use the Unix-style path to the executable (e.g. /home/user/ems-mcp/.venv/bin/ems-mcp).
Restart Claude Desktop after saving changes.
Create .gemini/settings.json in the project directory:
{
"mcpServers": {
"ems-mcp": {
"command": "C:\\absolute\\path\\to\\ems-mcp\\.venv\\Scripts\\ems-mcp.exe",
"args": [],
"env": {
"EMS_BASE_URL": "https://your-ems-server.com",
"EMS_USERNAME": "your-username",
"EMS_PASSWORD": "your-password"
}
}
}
}list_ems_systems -- List available EMS systems (start here)
list_databases -- Navigate the database hierarchy
find_fields -- Find fields by keyword (mode="search"), browse the field group tree (mode="browse"), or BFS-traverse entity-type databases (mode="deep"); returns numbered [N] references usable directly in other tools
get_field_info -- Get field metadata and discrete value mappings
search_analytics -- Search for time-series analytics by name (altitude, airspeed, etc.)
get_result_id -- (Deprecated) Resolve [N] references to full opaque IDs; no longer needed in the standard workflow
query_database -- Query flight records with filters, sorting, and aggregation
query_flight_analytics -- Get time-series data for specific flights
get_assets -- Get reference data: asset_type of fleets, aircraft (optionally filtered by fleet_id), airports, or flight_phases
ping_system -- Check whether an EMS system is online
The server also exposes MCP resources for stable reference data:
ems://workflow-guide -- Discovery-to-query workflow guide
ems://systems -- List of available EMS systems (cached)
ems://systems/{system_id}/fleets -- Fleet catalog for a system (cached)
ems://systems/{system_id}/airports -- Airport reference data (cached)
ems://databases/common-fields -- Index of databases with curated field vocabularies
ems://databases/{database_name}/common-fields -- Curated common fields for a named database (e.g. FDW Flights)
Reusable templates that pre-encode multi-step EMS workflows:
analyze_flights -- Discovery -> query -> analytics for a tail number / date range
compare_flights -- Side-by-side time-series comparison between two flight IDs
search_flight_parameters -- Discover available fields by keyword, with entity-database support
uv pip install -e ".[dev]"
pytest tests/401 Unauthorized -- Check that EMS_USERNAME and EMS_PASSWORD are correct and that the account has API access.
Connection errors -- Verify EMS_BASE_URL does not include a /api suffix. It should be just the server URL (e.g. https://your-ems-server.com).
Server not found by MCP client -- Make sure the path to the ems-mcp executable in your config is an absolute path and that the virtual environment has been created (uv venv && uv pip install -e .).
Find fields in a database. Three modes available:
search: Fast keyword search (default). Requires search_text. Does NOT work on entity-type databases.
browse: Navigate field group hierarchy. Use group_id to drill down.
deep: BFS traversal across all field groups. Requires search_text. Works on ALL databases including entity-type. Slower (multiple API calls).
Results show numbered references [N] that can be used directly in query_database, get_field_info, etc. Field names also work.
Args: ems_system_id: EMS system ID. database_id: Database ID or name (e.g. "FDW Flights"). mode: "search" (fast keyword), "browse" (navigate groups), or "deep" (BFS). search_text: Search keyword (required for search and deep modes). group_id: Field group ID to navigate into (browse mode only). max_results: Maximum results (search/deep modes, default: 50). max_depth: Maximum traversal depth (deep mode, default: 5, max: 10). max_groups: Maximum API calls (deep mode, default: 50, max: 200). show_ids: If True, show full IDs inline instead of numbered references.
Returns: Fields with names, types, and IDs (or numbered references).
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes | ||
| database_id | Yes | ||
| mode | No | search | |
| search_text | No | ||
| group_id | No | ||
| max_results | No | ||
| max_depth | No | ||
| max_groups | No | ||
| show_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: performance differences ('fast' vs 'slower'), API call implications ('multiple API calls' for deep mode), constraints ('Does NOT work on entity-type databases' for search mode), and output format ('numbered references [N]' usable in other tools). It lacks details on error handling or permissions, but covers most operational aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, mode details, args, returns) and uses bullet points for readability. Every sentence adds value, such as explaining mode differences or parameter interactions. It could be slightly more front-loaded by stating the core purpose more prominently, but overall it's efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, multiple modes) and no annotations, the description is highly complete. It covers input semantics, behavioral context, output usage ('Results show numbered references'), and ties to sibling tools. The presence of an output schema means return values are documented elsewhere, so the description appropriately focuses on usage and integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 fully. It adds significant meaning beyond the bare schema: explains each mode's purpose, which parameters are required for which modes (e.g., 'search_text' required for search/deep), default values and limits (e.g., 'max_depth: default: 5, max: 10'), and practical usage notes (e.g., 'group_id to drill down' in browse mode). This transforms cryptic parameter names into actionable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find fields in a database' with three specific modes (search, browse, deep). It distinguishes from siblings like 'get_field_info' (which likely retrieves details for a known field) and 'query_database' (which uses fields for queries), making the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 each mode: 'search' for fast keyword searches (not on entity-type databases), 'browse' for navigating field groups, and 'deep' for BFS traversal (works on all databases, slower). It also mentions alternatives like using results in 'query_database' or 'get_field_info', helping the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get reference data: fleets, aircraft, airports, or flight phases.
Args: ems_system_id: EMS system ID (from list_ems_systems). asset_type: Type of assets to retrieve. fleet_id: Filter aircraft by fleet ID (only for asset_type="aircraft").
Returns: Formatted list of the requested asset type.
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes | ||
| asset_type | Yes | ||
| fleet_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'gets' data (implying read-only) and returns a 'formatted list', but lacks critical details: whether it's paginated, rate-limited, requires specific permissions, or how errors are handled. For a tool with 3 parameters and no annotation coverage, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured sections for Args and Returns. There's minimal waste, though the 'Args' section could be more integrated into the flow rather than a separate block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema exists (which covers return values), the description is moderately complete. It explains the purpose and parameters to some extent but lacks behavioral context (e.g., error handling, performance) and usage guidance, making it adequate but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 some value by explaining ems_system_id comes from 'list_ems_systems', asset_type options (though the enum already lists them), and that fleet_id filters aircraft only for asset_type='aircraft'. However, it doesn't fully document all parameters (e.g., data types, constraints beyond the enum) or provide examples, leaving room for improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves reference data for specific asset types (fleets, aircraft, airports, flight phases), using the verb 'Get' with the resource 'reference data'. However, it doesn't explicitly differentiate from sibling tools like 'list_ems_systems' or 'get_field_info', which might also retrieve reference data in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions filtering aircraft by fleet ID only for asset_type='aircraft', but offers no explicit advice on when to use this tool versus alternatives like 'list_databases' or 'query_database'. There's no mention of prerequisites (e.g., needing an EMS system ID from list_ems_systems) 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.
Get field metadata including type, units, and discrete value mappings.
Essential for discrete fields: shows numeric code-to-label mappings needed for filtering. String labels in filters are auto-resolved, but use this to verify available values.
Args: ems_system_id: EMS system ID. database_id: Database ID or name (e.g. "FDW Flights"). field_id: Field reference: [N] number from find_fields, field name (e.g. "Takeoff Airport Name"), or bracket-encoded ID.
Returns: Field details with discrete value mappings if applicable.
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes | ||
| database_id | Yes | ||
| field_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes what information is returned (field details with discrete value mappings) and hints at functionality (auto-resolution of string labels in filters). However, it doesn't mention performance characteristics, error conditions, authentication requirements, or rate limits. For a tool with zero annotation coverage, this is adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, usage guidance, parameters explanation, and return value description. Every sentence earns its place by providing essential information. The text is front-loaded with the core purpose and most important usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return value documentation), the description provides good coverage of purpose, usage context, and parameter semantics. With no annotations, it could benefit from more behavioral details, but the presence of an output schema reduces the need to describe return values. The description is reasonably complete for this type of metadata retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It provides a dedicated 'Args' section that explains all three parameters: ems_system_id, database_id, and field_id. The field_id explanation is particularly helpful with examples and multiple valid formats. This adds significant value beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'field metadata' with specific details about what metadata is included (type, units, discrete value mappings). It distinguishes from sibling tools by focusing specifically on field metadata rather than listing fields (find_fields) or querying data (query_database). The purpose is specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: 'Essential for discrete fields: shows numeric code-to-label mappings needed for filtering.' It explains that string labels in filters are auto-resolved but this tool should be used to verify available values. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED: query_database and get_field_info now accept [N] reference numbers and field names directly. This tool is no longer needed in the standard workflow.
Retrieve full opaque IDs for numbered [N] references from search results.
Args: result_numbers: Reference numbers from search results (e.g., [1, 3, 5]).
Returns: The name and full ID for each requested result.
| Name | Required | Description | Default |
|---|---|---|---|
| result_numbers | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes the tool as deprecated and explains its function, but lacks details on permissions, rate limits, error handling, or whether it's read-only. The description doesn't contradict annotations (since none exist), but it could provide more operational context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: it front-loads the deprecation warning, then states the purpose, followed by clear sections for Args and Returns. Every sentence earns its place, with no redundant information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter, no annotations, and an output schema (which handles return values), the description is fairly complete. It covers purpose, usage guidelines, parameter meaning, and return information. However, it could improve by mentioning any prerequisites or behavioral traits like idempotency, but the deprecation note reduces the need for full operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates well: it explains 'result_numbers: Reference numbers from search results (e.g., [1, 3, 5]).' This adds meaningful context about what the parameter represents and provides an example, which is valuable since the schema only indicates it's an array of integers. With 1 parameter and no schema descriptions, this is above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve full opaque IDs for numbered [N] references from search results.' This specifies the verb ('retrieve'), resource ('full opaque IDs'), and scope ('from search results'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_field_info' or 'query_database' beyond mentioning they now accept reference numbers directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it starts with 'DEPRECATED: query_database and get_field_info now accept [N] reference numbers and field names directly. This tool is no longer needed in the standard workflow.' This clearly states when not to use this tool and names specific alternatives, helping the agent avoid unnecessary calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate the database hierarchy. Call without group_id for root level.
The "FDW Flights" database (Flight Data Warehouse) contains flight records.
Args: ems_system_id: EMS system ID (from list_ems_systems). group_id: Group ID to navigate into (omit for root).
Returns: Databases and subgroups at the specified level.
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes | ||
| group_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 hierarchical navigation behavior and mentions the 'FDW Flights' database example, which adds context. However, it doesn't cover important behavioral aspects like pagination, rate limits, authentication needs, error conditions, or whether this is a read-only operation (though implied by 'navigate').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three focused paragraphs: purpose/usage, example database, and parameter/return explanations. Each sentence earns its place, though the 'FDW Flights' example could be more integrated. The structure is logical with front-loaded navigation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 parameters, hierarchical navigation), no annotations, but with an output schema, the description is reasonably complete. It covers purpose, usage, parameters, and return scope. The output schema handles return values, so the description appropriately focuses on navigation behavior rather than output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'ems_system_id: EMS system ID (from list_ems_systems)' and 'group_id: Group ID to navigate into (omit for root).' It adds meaningful context about parameter relationships and sources, though it doesn't provide format details or constraints beyond what's implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Navigate the database hierarchy' with specific guidance on root vs. subgroup navigation. It distinguishes from siblings by focusing on hierarchy navigation rather than querying (query_database) or searching (search_analytics). However, it doesn't explicitly contrast with list_ems_systems which might be related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the tool: 'Call without group_id for root level' and 'Group ID to navigate into (omit for root).' It implies usage for exploring database structure rather than querying content. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available EMS systems. Start here to get system IDs for all other tools.
Returns: EMS systems with IDs, names, and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 listing operation and describes the return format (IDs, names, descriptions), which is helpful. However, it doesn't address potential limitations like pagination, rate limits, authentication requirements, or error conditions that would be important for an agent to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states the tool's function and strategic importance, the second describes the return format. There's zero wasted text, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, has output schema), the description provides adequate context about what the tool does and why to use it. The output schema will handle return value documentation, so the description doesn't need to detail response structure. However, for a tool positioned as an entry point to the system, additional guidance about prerequisites or limitations would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output. This earns a baseline 4 for zero-parameter tools that don't waste space on parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('List') and resource ('EMS systems'), making it immediately understandable. It distinguishes itself from siblings by focusing on EMS systems specifically, though it doesn't explicitly contrast with similar tools like 'list_databases' or 'get_assets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 ('Start here to get system IDs for all other tools'), indicating it's an entry point for subsequent operations. However, it doesn't specify when not to use it or name explicit alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an EMS system is online and responsive.
Args: ems_system_id: EMS system ID.
Returns: System status.
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the tool checks if a system is 'online and responsive', which implies a read-only, non-destructive operation, but doesn't specify behavioral traits like timeout behavior, error handling, performance characteristics, or authentication requirements. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first ('Check if an EMS system is online and responsive'), followed by brief sections for Args and Returns. However, the structure includes redundant labeling ('Args:', 'Returns:') that adds minor verbosity without enhancing clarity, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, simple health check), no annotations, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and parameter semantics adequately, though it lacks details on behavioral aspects like error conditions or performance, which would be beneficial for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'ems_system_id' by specifying it as 'EMS system ID', which clarifies its purpose beyond the schema's type (integer). With 0% schema description coverage and only one parameter, this compensation is effective, though it doesn't detail format constraints (e.g., valid ID ranges). The baseline for 0 parameters would be 4, but here the description adequately supplements the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 verb ('Check') and resource ('EMS system'), specifying it verifies if the system is 'online and responsive'. This distinguishes it from sibling tools like 'list_ems_systems' (which lists systems) or 'get_assets' (which retrieves asset data), making the purpose unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it checks if 'an EMS system is online and responsive', suggesting it should be used for health/availability monitoring. However, it doesn't explicitly state when to use this versus alternatives (e.g., whether it's for pre-operation checks or real-time monitoring), nor does it provide exclusions or prerequisites, leaving some ambiguity in optimal usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query flight records from a database.
Accepts field names (e.g. "Flight Date"), [N] reference numbers from find_fields, or raw bracket-encoded IDs. Database names (e.g. "FDW Flights") are also resolved automatically.
Supports aggregation (avg/count/max/min/stdev/sum/var) and discrete filter auto-resolution (string labels resolved to numeric codes automatically).
Args: ems_system_id: EMS system ID. database_id: Database ID or name (e.g. "FDW Flights"). fields: Fields to retrieve. Each has field_id (name, [N] ref, or bracket ID), optional alias, optional aggregate. filters: Filter conditions (AND-combined). Each has field_id, operator (equal/notEqual/greaterThan/lessThan/between/in/like/isNull/etc.), value. order_by: Sort order. Each has field_id, optional direction (asc/desc). limit: Max rows (1-10000, default: 100). format: 'display' (human-readable, default) or 'raw' (numeric codes). output_format: 'table' (default), 'csv' (compact), or 'json' (structured).
Returns: Results in the requested output format.
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes | ||
| database_id | Yes | ||
| fields | Yes | ||
| filters | No | ||
| order_by | No | ||
| limit | No | ||
| format | No | display | |
| output_format | No | table |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes some behavioral aspects: aggregation support, filter auto-resolution, format options, and return behavior. However, it doesn't cover important aspects like rate limits, authentication requirements, error handling, or whether this is a read-only operation (though 'query' implies read). The description adds value but doesn't fully compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, parameter explanations, returns). It's appropriately sized for an 8-parameter tool with complex functionality. Some sentences could be more concise (e.g., the 'fields' explanation is somewhat verbose), but overall it's efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, 0% schema coverage), the description does a good job of providing context. It explains most parameter semantics, describes behavioral aspects like aggregation and auto-resolution, and mentions the return format. The existence of an output schema means it doesn't need to explain return values in detail. The main gap is lack of sibling tool differentiation and some behavioral aspects like error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It does an excellent job explaining parameter semantics: it clarifies what 'fields' accepts (field names, reference numbers, bracket IDs), explains the aggregation options, describes filter operators, and details the format/output_format options. The only gap is that it doesn't explain 'ems_system_id' or 'database_id' beyond mentioning they're IDs/names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 flight records from a database.' It specifies the verb ('query') and resource ('flight records'), but doesn't explicitly differentiate from sibling tools like 'query_flight_analytics' or 'search_analytics', which might have overlapping functionality. The mention of 'database' provides some context but not full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions that database names are resolved automatically and references 'find_fields' for field references, but doesn't explain when to use this tool versus alternatives like 'query_flight_analytics' or 'search_analytics'. No explicit when/when-not guidance or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get time-series data (altitude, airspeed, etc.) for specific flights.
Flight IDs come from query_database. Accepts human-readable analytic names (e.g. "Airspeed") which are resolved automatically, or raw IDs from search_analytics.
Args: ems_system_id: EMS system ID. flight_ids: Flight record IDs (max 10, from query_database). analytics: Analytic names or IDs (max 20). e.g. ["Airspeed", "Altitude"]. start_offset: Start time in seconds from flight start. end_offset: End time in seconds from flight start. sample_rate: Samples per second (default: 1.0). output_format: 'table' (default), 'csv' (compact), or 'json' (structured).
Returns: Per-flight time-series data in the requested output format.
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes | ||
| flight_ids | Yes | ||
| analytics | Yes | ||
| start_offset | No | ||
| end_offset | No | ||
| sample_rate | No | ||
| output_format | No | table |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 adds useful context beyond basic functionality, such as constraints (max 10 flight IDs, max 20 analytics), data sources (query_database, search_analytics), and output format options. However, it lacks details on permissions, rate limits, error handling, or whether the operation is read-only/destructive, leaving gaps for a tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, usage guidelines, detailed parameter explanations, and return information. It is appropriately sized for a complex tool, though slightly verbose; every sentence adds value, such as clarifying data sources and parameter details, but could be more front-loaded by moving key constraints earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, usage, parameters, and output formats adequately. However, it lacks behavioral details like error conditions or performance implications, which would be beneficial for a data query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates fully for the 0% schema description coverage by explaining all 7 parameters in the 'Args' section with clear semantics, examples (e.g., ['Airspeed', 'Altitude']), defaults (sample_rate: 1.0, output_format: 'table'), and constraints (max values). It adds meaning beyond the bare schema, such as how analytics are resolved and what offsets represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Get time-series data') and resources ('for specific flights'), listing example data types like altitude and airspeed. It distinguishes from siblings by specifying flight IDs come from query_database and analytic names/IDs from search_analytics, avoiding overlap with tools like get_assets or list_databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this tool by stating 'Flight IDs come from query_database' and 'Accepts human-readable analytic names... or raw IDs from search_analytics', directly naming sibling tools as sources. It also implies when not to use it by specifying data types (time-series) and constraints like max 10 flight IDs, though it doesn't explicitly list all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for time-series analytics by name (altitude, airspeed, etc.).
You can pass analytic names directly to query_flight_analytics -- raw IDs are not needed. Use this tool to discover available analytic names.
Args: ems_system_id: EMS system ID. search_text: Keyword to search for in analytic names. group_id: Optional analytic group ID to narrow search. max_results: Maximum results (default: 50). show_ids: If True, show full IDs inline.
Returns: Matching analytics with names, types, units, and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| ems_system_id | Yes | ||
| search_text | Yes | ||
| group_id | No | ||
| max_results | No | ||
| show_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the search functionality and output format but lacks details on permissions, rate limits, error handling, or pagination behavior. The description adds some context about discovering names but doesn't fully compensate for missing annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose, followed by usage guidelines, args, and returns. Every sentence adds value without redundancy. The bullet-point style for args and returns enhances readability while maintaining brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no annotations, the description does a good job explaining parameters and output. However, it lacks details on behavioral aspects like authentication or error handling. The presence of an output schema reduces the need to fully describe returns, but some gaps remain for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lists all 5 parameters with brief explanations (e.g., 'Keyword to search for in analytic names', 'Optional analytic group ID to narrow search'), adding meaningful semantics beyond the bare schema. However, it doesn't provide examples or format details for parameters like 'ems_system_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for time-series analytics by name (altitude, airspeed, etc.)' with specific examples. It distinguishes from sibling tools by mentioning 'query_flight_analytics' as an alternative for direct querying, making the distinction explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this tool to discover available analytic names' and contrasts with 'query_flight_analytics' for direct querying. It specifies when to use this tool (for discovery) versus when to use the alternative (for querying with known names).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap between find_fields and search_analytics as both involve searching for metadata with similar arguments (search_text, group_id, max_results). However, their domains (database fields vs. flight analytics) are clearly separated, and the descriptions help clarify their distinct use cases.
Tool names follow a consistent verb_noun pattern (e.g., find_fields, get_assets, list_databases), with minor deviations like ping_system (verb_noun but less standard) and get_result_id (deprecated, but fits the pattern). Overall, the naming is predictable and readable across the set.
With 10 tools, the server is well-scoped for interacting with EMS systems, covering essential operations like listing systems, querying databases, retrieving metadata, and accessing flight analytics. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain.
The tool set provides comprehensive coverage for flight data analysis, including system discovery (list_ems_systems, ping_system), database navigation (list_databases), field and analytic metadata retrieval (find_fields, get_field_info, search_analytics), asset reference data (get_assets), and core querying (query_database, query_flight_analytics). No obvious gaps exist for the intended workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Read-only airport delay, weather, and 24h forecast tools for AI assistants. Airport-level only.
The Turkish Airlines MCP server enables AI models to securely access live airline data and services, designed for developers and power users to build and test AI-driven travel solutions. It provides 13 specialized tools covering flight information (real-time status, schedules, availability), booking management (PNR details, check-in, baggage allowances), and personalized services (Miles&Smiles profiles, flight history, promotions). The server uses OAuth 2.0 authentication and is deployed on cloud-native infrastructure with enterprise-level security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mattsq/ems-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
