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., "@Aviation MCP Server What's the weather at KLAX?"
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.
Give your AI agent live aviation data. Connect this MCP server to Claude Desktop, ChatGPT, Cursor, Cline, Continue, or Windsurf and your assistant can pull real METAR weather, airport info, aircraft specs, an aviation glossary, and FAA-style practice questions — on demand.
Powered by the free Rotate Pilot aviation API. No API keys to wrangle, no signup — just connect and go.
Tool | What it does |
| Current decoded METAR for any ICAO airport — flight category (VFR/MVFR/IFR/LIFR), wind, visibility, temp, dewpoint. Optional TAF. |
| Airport info by ICAO — name, IATA, city, country, coordinates, elevation, runways. |
| Aircraft specs by slug — engines, seats, range, cruise, ceiling, MTOW, type rating. |
| Definition of an aviation term (e.g. |
| FAA-style practice exam questions with options + correct answer. Filter by subject. |
| The aviation question of the day. |
Related MCP server: adsb.lol MCP Server
"What's the current weather at KJFK and is it VFR?"
"Pull the specs for a Cessna 172 and a Piper Warrior and compare cruise speed and range."
"Give me 3 FAA meteorology practice questions and quiz me."
"What does the squawk code 7700 mean?"
{
"mcpServers": {
"aviation": {
"command": "npx",
"args": ["-y", "@renzom13/aviation-mcp"]
}
}
}That's it — npx pulls the package and starts the server over stdio. No signup, no token. Data comes from the free Rotate Pilot API.
For a managed, always-on endpoint with nothing to install, use the Apify-hosted version:
{
"mcpServers": {
"aviation": {
"url": "https://renzomacar--aviation-mcp.apify.actor/mcp?token=YOUR_APIFY_TOKEN"
}
}
}Get a free Apify token at console.apify.com/account/integrations. Legacy SSE clients can use /sse instead of /mcp. Hosted calls are billed per tool call.
Pay-per-use: a small charge per tool call (no subscription, no minimum). You only pay for the data your agent actually pulls.
All data comes from the free Rotate Pilot aviation API (docs · OpenAPI spec), built by a commercial pilot. Weather is live; airport/aircraft/glossary data is curated reference data.
Get aircraft specifications by slug: engines, seats, range, cruise speed, ceiling, MTOW, type-rating requirement, and description. Example slugs: cessna-172-skyhawk, piper-pa-28-warrior, airbus-a320neo, boeing-737-800.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Aircraft slug, e.g. cessna-172-skyhawk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only lists output fields and example slugs, with no disclosure about read-only behavior, rate limits, authentication, or any side effects. This is minimal for a simple retrieval tool, but still missing guidance on what happens with invalid slugs.
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 two sentences with no redundancy. It front-loads the purpose and includes examples efficiently. Every sentence earns its place.
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?
For a simple tool with one parameter and no output schema or nested objects, the description covers the purpose, input examples, and output fields adequately. It does not address error handling for invalid slugs, but given the low complexity, it is nearly complete.
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 coverage is 100% with one parameter (slug). The description adds valuable context with concrete example slugs and lists the output fields, which goes beyond the schema's minimal description. This helps the agent select appropriate slug values.
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 aircraft specifications by slug and lists the returned fields (engines, seats, etc.), with specific examples. This distinguishes it from siblings like get_airport or get_metar.
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 implicitly indicates usage for aircraft spec lookups by slug, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions or prerequisites. The sibling context helps but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get airport information by ICAO code: name, IATA code, city, country, region, coordinates, elevation, and runway count.
| Name | Required | Description | Default |
|---|---|---|---|
| icao | Yes | 4-letter ICAO airport code, e.g. KJFK. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states input and output but does not mention idempotency, error handling, auth requirements, or response format. For a simple read tool, this is a partial disclosure.
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 a single concise sentence that effectively communicates purpose, method, and output without extraneous words.
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 no annotations and no output schema, the description adequately covers input and output for a simple retrieval tool. It lacks details on error behavior or response structure, but is mostly complete.
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 covers 100% of parameters, and the description adds meaningful context: it specifies the parameter is a 4-letter ICAO code and provides an example (KJFK), enriching the schema's description.
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 action 'Get airport information' and the resource 'airport', specifies the lookup method 'by ICAO code', and lists specific output fields (name, IATA code, etc.), distinguishing it from siblings like get_aircraft or get_metar.
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 for retrieving airport details by ICAO code but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. However, sibling tools have distinct resources, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the definition of an aviation term from the Rotate Pilot glossary by slug (e.g. squawk, angle-of-attack, v-speeds). Returns the definition, category, and related terms.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Glossary term slug, e.g. squawk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the lookup behavior and return fields, but does not explicitly state it is read-only or mention error handling, rate limits, or availability. The behavior is clear but lacks extra context.
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?
Two sentences with no waste. The first sentence states clear purpose with examples; the second lists return fields. Front-loaded and efficient.
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?
For a simple tool with one parameter and no output schema, the description is sufficiently complete. It explains the input, source, and output. Minor omission: could clarify that the term must be a slug, but the examples convey that.
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 descriptions cover 100% of the parameter, but the description adds value by specifying the glossary source (Rotate Pilot), giving examples of slugs, and indicating the return fields. This goes beyond the schema description.
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 it looks up a definition from the Rotate Pilot glossary by slug, with specific examples (squawk, angle-of-attack, v-speeds) and return fields (definition, category, related terms). It distinguishes itself from siblings like get_aircraft and get_metar.
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 for looking up aviation term definitions, but does not explicitly state when to use or not use this tool compared to alternatives like practice_questions or quiz_of_the_day.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current decoded METAR (aviation weather) for an airport by ICAO code. Returns raw report, flight category (VFR/MVFR/IFR/LIFR), wind, visibility, temperature, dewpoint, and more. Optionally include the TAF forecast.
| Name | Required | Description | Default |
|---|---|---|---|
| icao | Yes | 4-letter ICAO airport code, e.g. KJFK, EGLL, SPJC. | |
| taf | No | Also include the TAF forecast. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions what is returned but does not disclose behavioral traits such as read-only nature, rate limits, or error handling. Lacks transparency beyond the obvious fetch operation.
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?
Two sentences, front-loaded with purpose. Every word is meaningful; no fluff. Efficiently conveys the tool's function.
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?
For a simple 2-parameter tool with no output schema, the description covers the return fields and optional TAF. However, it omits typical error scenarios (e.g., invalid ICAO) and structure of the decoded report.
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 coverage is 100%; both parameters are described in the schema (ICAO code format, TAF boolean). The description adds 'Optionally include the TAF forecast' but does not provide additional semantic value beyond the 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 gets the current decoded METAR for an airport by ICAO code, listing specific fields returned. It is distinct from sibling tools like get_airport or get_aircraft, which handle non-weather data.
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 for aviation weather retrieval but does not specify when to use this tool over alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FAA-style aviation practice exam questions with options and the correct answer. Optionally filter by subject (e.g. meteorology, regulations, navigation). Great for building study tools or quizzing a user.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | No | Optional subject filter, e.g. meteorology, regulations, navigation. | |
| count | No | Number of questions (1-5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the return of questions with options and correct answer, but does not mention whether the operation is idempotent, auth requirements, or rate limits.
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?
Two sentences, front-loaded with purpose and output, then filter and use case. No unnecessary words.
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?
For a simple tool with 2 optional params and no output schema, the description adequately covers purpose, output, filtering, and intended use. No gaps.
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 coverage is 100%, so the description adds only marginal value via 'Optionally filter by subject'. Baseline 3 is appropriate.
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 'Get FAA-style aviation practice exam questions with options and the correct answer', which is a specific verb and resource. It is distinct from sibling tools like get_aircraft or get_airport.
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 says 'Great for building study tools or quizzing a user', providing clear usage context. It does not explicitly list when not to use it, but the guidance is sufficient given the distinct sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the aviation question of the day — a single FAA-style multiple-choice question with the correct answer and explanation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: a read-only retrieval of a single question with answer and explanation. No side effects or state changes; transparency is adequate for a simple getter.
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?
Single sentence, front-loaded with key information, no extraneous content. Every word serves a 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 no parameters, no output schema, and simple behavior, the description provides sufficient context: it explains the output format and content. No gaps for a tool of this complexity.
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?
No parameters; description adds nothing beyond the empty schema. Baseline of 4 is appropriate as no parameter information is needed.
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?
Clearly states the tool retrieves the aviation question of the day, a single FAA-style multiple-choice question with answer and explanation. Distinguished from siblings like practice_questions which likely provide multiple questions.
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?
Implies usage for daily question retrieval but lacks explicit guidance on when to use this versus siblings like practice_questions, which might offer more questions or customization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of aviation: aircraft specs, airport info, glossary terms, weather, and exam questions. No functional overlap exists.
All tool names use a consistent verb_noun pattern with underscores (get_aircraft, get_metar, practice_questions), making the set predictable and easy to navigate.
Six tools is well-scoped for an aviation reference and exam prep server; each tool earns its place without redundancy or excess.
The set covers core aviation reference (aircraft, airports, weather, glossary) and exam preparation (practice questions, quiz). Minor gaps like NOTAMs or flight planning exist but are outside the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
Read-only airport delay, weather, and 24h forecast tools for AI assistants. Airport-level only.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Free no-key search over CASA, FAA, EASA & ICAO aviation regulations. By Deepsky (deepskyai.com).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Perufitlife/aviation-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
