Skip to main content
Glama

Deepsky Aviation Regulations

by com.deepskyai

Search Aviation Regulations

search_aviation_regulations

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesNatural-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.
matchCountNoNumber of ranked matches to return (1-20).

TDQS

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.

All Deepsky Aviation Regulations toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
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.

Resources