exascale.build

Query Space Satellite Notices (FCC weekly satellite public notices)

query_space_satellite_notices_v1

Read-onlyIdempotent

Query the FCC Space Bureau's weekly satellite public notices since the ICFS cutover (2025-06-18) — every satellite application the FCC accepted for filing and every action it took (grants, partial grants, dismissals, surrenders), as printed.

Use this for "what satellite filings has the FCC received or acted on since mid-2025" questions — the current licensing pipeline, which the pre-cutover docket (query_space_satellite_filings_v1) does not carry. Each record is one listing of a filing in one notice: the notice (report_number e.g. "SAT-02040", notice_kind "Applications Accepted for Filing" or "Actions Taken", release_date), the FCC file_number (e.g. "SAT-MOD-20260603-00225") and its filing_type_code (LOA, MOD, STA, AMD, T/C…), the call_sign, the applicant as printed (e.g. "Space Exploration Holdings, LLC"), the printed date_filed and filing_type, on Actions Taken notices the action (e.g. "Grant of Authority") and action_date, and the entry's full text as printed (entry_text, which carries the FCC's description of the request). Filter by notice_kind, filing_type_code, action, applicant, report_number, file_number, call_sign, informative, or the ranges report_period_from/report_period_to (release date), date_filed_from/date_filed_to, action_date_from/action_date_to. Group by notice_kind, filing_type_code, action, applicant or report_number. Pass each parameter as a top-level key of params. Example: {"applicant": "Space Exploration Holdings, LLC", "include_records": true} for SpaceX's listings; {"notice_kind": "Actions Taken", "action": "Grant of Authority", "group_by": ["applicant"], "order_by": "source_record_count", "top_n": 10} for the operators granted most often. Every record cites its line in the FCC's notice text, re-verifiable via get_source_evidence_v1.

Read carefully: one filing can be listed in several notices, so source_record_count counts listings, not distinct filings. Values are what each notice prints: the same filing can show a different date_filed or applicant name in different notices. action_date is null when the notice prints none (the notice states its release date is then the effective date). The notices carry no status history and omit filings the FCC has not listed; a filing is never a satellite count, an orbital catalog or launch activity. Earth-station (SES) notices are out of 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.

AddedSep 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare a safe read-only, idempotent profile, but the description adds substantial behavioral context beyond them: source_record_count counts listings not distinct filings, values are as-printed and may vary across notices, action_date is null when unprinted (release date becomes effective date), and the notices carry no status history and omit unlisted filings.

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?

It is long, but front-loaded with the core purpose before the field list and caveats, and every section (purpose, routing, fields, examples, caveats) earns its place. Slight over-length keeps it from a 5.

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?

For a single-params query tool with an output schema, the description supplies everything an agent needs: purpose, routing, full parameter vocabulary, examples, and critical interpretation caveats. Nothing needed to call it correctly is 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% — the schema exposes only an opaque free-form params object — so the description carries the full burden and does so: it enumerates every filterable field (notice_kind, filing_type_code, action, applicant, report_number, file_number, call_sign, informative), all range params, group_by options, and worked examples with order_by/top_n/include_records.

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 precise verb and resource (query FCC Space Bureau weekly satellite public notices), the temporal scope (since the ICFS cutover, 2025-06-18), and explicitly distinguishes from the sibling query_space_satellite_filings_v1, which carries the pre-cutover docket. An agent can tell exactly what this returns without opening the schema.

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?

Gives an explicit when-to-use trigger ('what satellite filings has the FCC received or acted on since mid-2025') and names the alternative tool plus the condition that differentiates them. It also states scope exclusions ('Earth-station (SES) notices are out of scope').

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?