EMS MCP Server

by mattsq

Overview Schema Related Servers Score Discussions

Python

Remote

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, 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 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.
Conciseness4/5
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.
Completeness3/5
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.
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 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.
Purpose4/5
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.
Usage Guidelines2/5
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.
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 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.
Conciseness4/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate 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.
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 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.
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 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.
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 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.
Conciseness4/5
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.
Completeness4/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 (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.
Parameters4/5
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.
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 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.
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 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.
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 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.
Conciseness4/5
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.
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 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.
Parameters4/5
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.
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 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.
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 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.
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 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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (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.
Parameters4/5
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.
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 ('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.
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 ('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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
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: '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.
Usage Guidelines5/5
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.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate 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.
Purpose5/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 '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.
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: '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.
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 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.
Conciseness4/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (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.
Parameters5/5
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.
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 ('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.
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 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/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 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.
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: '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.
Usage Guidelines5/5
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.
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 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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/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 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.
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: '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.
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 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.

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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mattsq/ems-mcp'

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