exascale.build

Query Space Satellite Filings (FCC satellite licensing docket)

query_space_satellite_filings_v1

Read-onlyIdempotent

Query the verified FCC satellite licensing docket — every space-station (SAT) filing in the FCC's own daily IBFS database dump, back to the 1960s — by applicant, application type, status, and filing date.

Use this for "who is authorized to operate what in orbit, what has been filed, and where does each filing stand" questions — the satellite-buildout licensing pipeline. Each filing carries the FCC's public filing key (file_number, e.g. "SATLOA2025061800149"), the callsign (e.g. "S3069" = SpaceX Gen2), the application type and status in the FCC's OWN vocabulary — verbatim codes plus the FCC's own decode text from the same dump vintage (app_type_code "LOA" = Launch and Operating Authority, "STA" = Special Temporary Authority, "MOD" = Modification; status_code "A/C" = Action Complete, "ATPN" = Action Taken Public Notice — codebooks in describe) — the full lifecycle date family (filed / granted / expires / …), the FCC's plain-English description of the filing, and the applicant identity (applicant_name, the FCC's verbatim registrant, e.g. "Space Exploration Holdings, LLC"). Filter by applicant_name, app_type_code, status_code, callsign, file_number, state (the APPLICANT's address state), applicant_country, report_period (the filing date) via report_period_from/report_period_to, or date_grant/date_expire ranges. Group by any of applicant_name, app_type_code, status_code, state, applicant_country. Pass each parameter as a top-level key of params (flat — not nested under a filter, filters, or where key). Example: {"applicant_name": "Space Exploration Holdings, LLC", "group_by": ["app_type_code"]} for one operator's filing mix; {"report_period_from": "2020-01-01", "group_by": ["applicant_name"], "order_by": "source_record_count", "top_n": 10} for the most active filers of the 2020s. Returns JSON aggregates with citations and optional row-level records when include_records is true — every record cites its exact row in the FCC's dump, re-verifiable via get_source_evidence_v1.

THE ENGRAVED BOUNDARY: new-filing intake into IBFS structurally ENDED at the FCC's ICFS system cutover (~mid-2025), and ICFS publishes no bulk data — so filings SUBMITTED after the cutover are not in this docket, and counts near/after 2025 UNDERCOUNT new filing activity (say so when answering; every response carries an icfs_cutover note). The FCC has not regenerated this dump since 2026-07-16 (it previously updated daily), so status changes after that date are not reflected. For filings and actions since the cutover, use query_space_satellite_notices_v1 (the FCC's weekly satellite public notices). A filing is an authorization EVENT: never a satellite count (one NGSO grant can cover thousands of satellites), never an orbital catalog (satellites in orbit are not served here), never launch activity (FAA data, not served here). state/applicant_city are the APPLICANT's mailing address — satellites are not in states. Earth stations (SES) and non-satellite FCC dockets are out of scope. The one measure is source_record_count (filings in scope).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedJul 5, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only/idempotent safety; the description adds substantial behavioral context beyond them: the ICFS cutover boundary that causes structural undercounting, the stale dump date (2026-07-16), the presence of an icfs_cutover note in every response, and citations re-verifiable via get_source_evidence_v1. This is exactly the kind of caveat an agent needs and structured fields cannot supply.

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?

Purpose and scope are strongly front-loaded and almost every clause adds usable signal, but the description is very dense and some points (the cutover explanation, the alternative tool) are restated in more than one place. Slightly longer than necessary for its job.

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?

An output schema exists, so return-format exposition is unnecessary, and the description still covers the sole measure (source_record_count), the record-inclusion flag, temporal boundaries, and the sibling for out-of-scope filings. Nothing an agent needs to call this correctly appears to be missing.

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?

Schema coverage is 0% and the input schema is an opaque free-form bag, so the description carries the full burden — and does: it lists each filter key, the flat-top-level-key requirement (not nested under filter/where), grouping dimensions, ordering, top_n, include_records, and report_period_from/report_period_to ranges, with two concrete invocation examples.

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?

States a specific verb and resource ('Query the verified FCC satellite licensing docket — every space-station (SAT) filing in the FCC's own daily IBFS database dump') and enumerates the fields each filing carries. It clearly demarcates itself from siblings, naming query_space_satellite_notices_v1 and the describe_* codebooks as distinct.

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 it ('who is authorized to operate what in orbit...') and when not to, plus the exact alternative for post-cutover activity ('use query_space_satellite_notices_v1'). It also rules out adjacent interpretations (never a satellite count, never an orbital catalog, never launch activity) and out-of-scope dockets (SES, non-satellite).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All exascale.build tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?