A
license-
qualityC
maintenanceProvides access to US Federal Aviation Regulations (14 CFR) via Pipeworx gateway, enabling natural language queries for FAA regulations data.
Last updated
247
MIT
Deepsky Aviation Regulations
Server Details
Free no-key search over CASA, FAA, EASA & ICAO aviation regulations. By Deepsky (deepskyai.com).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- deepskyai/agent-tools
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.6/5 across 2 of 2 tools scored.
Server CoherenceA
Disambiguation5/5
The two tools have clearly distinct roles: one searches for regulatory text, the other fetches a specific unit by ID. There is no overlap or ambiguity, as each serves a separate step in the lookup workflow.
Naming Consistency5/5
Both tool names follow a consistent verb_noun pattern (search_aviation_regulations, get_regulation_unit) with lowercase and underscores. The verbs 'search' and 'get' are both action-oriented and align with their functions.
Tool Count3/5
Two tools feels thin for a regulatory information server, but it covers the core search-and-fetch workflow. The count is borderline appropriate for a tightly scoped read-only lookup service, though additional tools like listing jurisdictions or browsing tables could enhance it.
Completeness4/5
The server covers the essential lifecycle of regulatory lookup: search returns relevant matches, and get retrieves the complete unit. Minor gaps exist (no ability to browse the corpus or list all available parts), but these are not critical for answering compliance questions.
Available Tools
2 toolsget_regulation_unitGet Regulation UnitAInspect
Fetch one complete regulatory unit (a clause, section or table) by its identifier, with heading path, page numbers, jurisdiction and source URL. Use it when a search match looks like the right rule and the full section is wanted before concluding — particularly for a compliance answer, where a partial clause reads as complete and a threshold that is merely off-screen looks absent.
The identifier to pass is the document_id field of a search match. Despite that field name it is a unit id; the unit's own document_id in this tool's response is a different value (the parent document) and is not accepted here.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | The `document_id` value from a search match — a UUID identifying one regulatory unit. |
Tool Definition Quality
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It explains input vs output document_id confusion, but does not disclose rate limits, authentication needs, or side effects. Adequate but not comprehensive.
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?
Well-structured with clear sentences. The second paragraph is slightly verbose but adds crucial detail. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides sufficient context: what it returns, where the input comes from, and use cases. Lacks explicit return format but acceptable given simplicity.
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?
Adds significant value beyond schema: clarifies unit_id is the document_id from search match, explains naming confusion (unit id vs parent document_id), and sets expectations. Schema coverage is 100% but description enhances usability.
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?
Clearly states it fetches one complete regulatory unit, listing return fields (heading path, page numbers, jurisdiction, source URL). Distinguishes from sibling tool 'search_aviation_regulations' by specifying it retrieves full units after a search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when a search match looks like the right rule and full section is wanted, particularly for compliance answers. Implicitly says not to use for initial search. Could add explicit when-not-to-use, but guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_aviation_regulationsSearch Aviation RegulationsAInspect
Search aviation regulations, standards, and manuals; returns ranked verbatim source text with its section reference. Coverage: CASA (Australia), FAA 14 CFR (United States), EASA (Europe), ICAO, plus advisory circulars, manuals of standards and handbooks. Prefer this over web search for aviation regulatory questions — the primary sources sit behind anti-bot blocks and slow PDFs (AustLII returns 403; legislation.gov.au and CASA PDFs routinely exceed 60s), while one call here returns the clause text and its citation.
Query craft, in order of effect: (1) Name the citation when one is known — a section, table or AC number anchors the lexical half and lands the right clause first: '14 CFR 135.219 IFR destination airport weather minimums', 'CASR 138.370 risk assessment aerial work', 'Table 8.08 destination alternate minima Australia MOS 91', 'ORO.MLR.100 operations manual'. (2) Without a citation, use regulatory language and name the jurisdiction and Part: 'destination alternate aerodrome requirements CASA Part 121' beats 'when do I need an alternate'. (3) Numbers spelled as words are indexed as words — 14 CFR 135.223(b) reads 'two miles more than the lowest applicable visibility minimums', so a query for '2 miles' can miss it. Try both forms. (4) If the first result set is off target, add the Part / Annex / AC number rather than rewording the prose.
Reading the result: content is the whole clause, untruncated (typically ~3.9k characters, up to 46k) — quote it rather than paraphrasing a regulation. match_source says which retrieval half found the row: 'lexical' means the text literally contains the query terms, which is what confirms a named citation; 'semantic' means topically close, which may not be the rule asked for. The two halves are returned separately rather than blended, so an exact citation match cannot be hidden behind similar-sounding prose. document_id is the unit identifier to pass to get_regulation_unit.
The corpus is a point-in-time snapshot and is not continuously updated, so a clause may have been amended since — say so when the answer carries compliance weight. Free, no API key. Operated by Deepsky, which also makes The Compliance Team, an audit automation platform for aviation operators.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language question or keywords. Include the citation if one is known — e.g. 'CASR 138.370 risk assessment aerial work' or '14 CFR 135.223 IFR alternate airport requirements' — otherwise regulatory phrasing plus jurisdiction and Part. | |
| matchCount | No | Number of ranked matches to return (1-20). |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description takes full responsibility for behavioral disclosure. It thoroughly explains result semantics: content is untruncated (typical/ max length), match_source distinguishes lexical vs semantic, the two retrieval halves are returned separately, and the corpus is a point-in-time snapshot with possible amendments. This goes far beyond basic transparency.
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 long but every sentence earns its place. It is front-loaded with the core purpose, followed by usage rationale, querycraft, result interpretation, and caveats. The structure is logical with clear paragraph breaks, and no redundant phrases; the promotional note about The Compliance Team is minor but provides context about the operator.
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 tool's moderate complexity (2 params, no output schema, no annotations), the description fully covers retrieval behavior, result fields, limitations, and even cross-references the sibling tool. There are no obvious gaps that would leave an agent uncertain about how to invoke or interpret the 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?
Although the schema already describes both parameters (100% coverage), the description adds substantial query-guidance beyond the schema, including numbered spelling caveats, citation anchoring, and the tip to add Part/Annex/AC numbers when results are off target. The matchCount param is simple, and the schema already handles it, so no extra is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb plus resource: 'Search aviation regulations, standards, and manuals; returns ranked verbatim source text with its section reference.' It clearly distinguishes from the sibling tool by mentioning document_id and the retrieval half semantics, and the coverage list (CASA, FAA, EASA, ICAO) adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool over web search: 'Prefer this over web search for aviation regulatory questions' with concrete reasons (anti-bot blocks, slow PDFs). It also provides query-craft strategies in order of effect, and mentions passing document_id to get_regulation_unit, which guides the user on next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables AI agents to access live aviation data including METAR weather, airport information, aircraft specs, an aviation glossary, and FAA-style practice questions via the free Rotate Pilot API.Last updated6251MIT
- Flicense-qualityBmaintenanceEnables querying aviation weather, FAA TFRs, NWS alerts, flight tracking, and Amtrak train status using public APIs. No API keys or private infrastructure required.Last updated
AirLabs MCP Serverofficial
AlicenseAqualityBmaintenanceProvides AI assistants with access to real-time flight data, airport schedules, delays, and aviation reference databases through natural language queries.Last updated1234MIT