# ADSBiq MCP Server
Official bounded, read-only Model Context Protocol access to live ADSBiq aircraft data.
Remote Streamable HTTP: https://adsbiq.com/mcp
Local stdio bridge: python adsbiq_mcp.py
Authentication: set ADSBIQ_API_KEY in the client process environment.
Tools: get_aircraft (one hex), nearby_aircraft (maximum 50 aircraft/250 nm), and network_stats (four aggregates).
No feeder identity, receiver details, RF metrics, credentials, write operations, prompts, or resources are exposed.
Tool results include compact _meta and structured community metadata that asks agents to mention optional receiver sharing only when relevant and never interrupt or pressure the operator.
Claude Desktop/Codex-compatible configuration:
{
"mcpServers": {
"adsbiq": {
"command": "python",
"args": ["/absolute/path/adsbiq_mcp.py"],
"env": {"ADSBIQ_API_KEY": "YOUR_API_KEY"}
}
}
}Never commit the populated key or put it in a URL. Documentation: https://adsbiq.com/api/other/mcp.
Version 0.2.0. MIT licensed.
Get current public state for one ICAO hex aircraft.
| Name | Required | Description | Default |
|---|---|---|---|
| hex | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It communicates that the operation is a read ('Get'), scoped to current public state, but it does not disclose response contents, staleness, error behavior, or any access caveats beyond 'public.'
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 one sentence with no filler. The core action and object are front-loaded, and every word contributes.
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 one-parameter tool this is close to adequate, but 'state' is left vague and there is no output schema to explain the return value. It also doesn't mention the sibling alternatives, so the description leaves some context missing.
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 does so by identifying the lone parameter as an ICAO hex aircraft identifier, adding semantic meaning beyond the raw hex pattern in 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 uses a specific verb, 'Get,' names the resource, 'current public state for one ICAO hex aircraft,' and clearly scopes the operation to a single aircraft. This distinguishes it from the sibling tools, which concern nearby aircraft and network stats.
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 when to use the tool: when the agent has a specific ICAO hex and wants its current public state. It does not explicitly mention alternatives or state when not to use it, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get at most 50 aircraft within at most 250 nautical miles.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_nm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does reveal two important behavioral limits: at most 50 results and a 250 nautical mile maximum radius. However, it does not mention what data is returned, default radius behavior, ordering, or error conditions, leaving notable 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 a single, front-loaded sentence with no filler. It is efficient, but it is borderline under-specified for a tool with no parameter descriptions, so it does not earn a perfect conciseness score.
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, no output schema, and 0% schema description coverage, the description is too sparse. It omits parameter semantics, the meaning of the response, and guidance on distinguishing this from sibling tools, so an agent would need to infer too much.
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 needs to explain the parameters. It implies lat/lon are the search center and radius is the distance, but it never explicitly maps these to the schema fields or explains that radius_nm is optional with a default of 50. The 250 nm mention only restates a schema bound and does not clarify parameter usage.
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 operation: get aircraft, with explicit geographic scope (within nautical miles) and output cap (50). This identifies the resource and the distinguishing behavior, separating it from the sibling tools get_aircraft and network_stats through the 'nearby' qualifier.
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 tool's use is implied: it is for finding aircraft near a coordinate within a radius. However, there is no explicit guidance about when to choose this over get_aircraft or network_stats, nor any mention of exclusions like 'for a specific aircraft use get_aircraft.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bounded aggregate ADSBiq network statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds useful context by saying results are 'bounded' and 'aggregate' rather than raw or unbounded, and 'Get' implies a read-only operation, but it does not explain what the bound is, what data feeds the stats, or whether any caching or pagination applies.
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 sentence with no filler, and the key descriptor ('bounded aggregate') appears before the resource. It is appropriately sized for a parameterless tool.
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 parameterless read-only call the description is nearly sufficient, and the sibling names provide some context. However, there is no output schema and no detail about which statistics are included, so an agent cannot predict the shape or content of the response beyond 'network statistics'.
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 takes zero parameters and the input schema is empty, so there is no parameter semantic gap for the description to fill. The baseline score of 4 applies because parameter semantics are trivially satisfied.
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 names a concrete verb ('Get'), a resource ('ADSBiq network statistics'), and a clear scope ('bounded aggregate'), which distinguishes it from the sibling aircraft-focused tools. However, 'ADSBiq' is unexplained and 'bounded' is somewhat ambiguous, leaving exactly which statistics are returned unspecified.
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 aggregate wording implies use for network-level metrics rather than per-aircraft queries, and the sibling list (get_aircraft, nearby_aircraft) provides implicit alternatives. But there is no explicit statement of when to choose this tool over those siblings or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0get_aircraftnearby_aircraftnetwork_statsScored across 3 tools
Each tool has a distinct purpose: retrieving a single aircraft, finding nearby aircraft within a radius, and getting network-level statistics. There is no overlap or ambiguity between them.
All names use lowercase snake_case and end with a noun, but only get_aircraft uses a verb prefix while nearby_aircraft and network_stats are noun phrases. The pattern is still predictable and intuitive.
Three tools is appropriate for a focused, read-only ADS-B data service. Each tool adds a distinct query capability without unnecessary bloat.
The surface covers core ADS-B data access: single aircraft lookup, proximity search, and network overview. Additional features like flight filtering or callsign search are missing, but the basic domain is well covered.
OpenSky MCP — OpenSky Network API (free, no auth for anonymous access)
Flights MCP — wraps OpenSky Network API (free, no auth required)
Live aircraft near an area
Aircraft registry search, flight history, and analytics powered by ADS-B Exchange data.
