Skip to main content
Glama

search_filings

Read-only

Search space regulatory filings by keyword, agency, type, status, date, or file number across FCC, ITU, UNOOSA, and other agencies; returns paginated results.

Instructions

Search space regulatory filings by keyword, agency, type, status, date range, agency file number (exact or prefix such as SES-LIC), FCC station call sign or applicant entity. Returns a paginated list of filings from FCC, ITU, UNOOSA, and other agencies.

Input Schema

NameRequiredDescriptionDefault
qNoSearch query for filing titles and summaries
pageNoPage number (default 1)
typeNoFilter by filing type, one of: ADVANCE_PUBLICATION, COMMENT, EARTH_STATION_PERMIT, ENVIRONMENTAL_ASSESSMENT, EXPERIMENTAL_LICENSE, EX_PARTE, LAUNCH_LICENSE, MODIFICATION, OPPOSITION, ORBITAL_DEBRIS_PLAN, OTHER, PETITION, REENTRY_LICENSE, REGISTRATION, REMOTE_SENSING_LICENSE, RENEWAL, SATELLITE_LICENSE, SPECIAL_TEMPORARY_AUTH, SPECTRUM_COORDINATION, TRANSFER_OF_CONTROL. For FCC application types such as SES-LIC use source_id_prefix
agencyNoFilter by source agency, one of: ACMA_AU, CNES_FR, FAA_AST, FCC, ITU, NOAA, NTIA, OFCOM_UK, OTHER, SEC, STATE_AK, STATE_FL, STATE_TX, STATE_VA, UN_OOSA, USPTO
docketNoFilter by docket number, e.g. 22-271 (also accepts 'IB Docket No. 22-271', RM-11348, FAA-2024-2006)
statusNoFiling (application) status, one of: ACCEPTED, CANCELLED, COMMENT_PERIOD, DENIED, DISMISSED, EXPIRED, FILED, GRANTED, PUBLIC_NOTICE, UNDER_REVIEW, UNKNOWN, WITHDRAWN
per_pageNoResults per page (default 10, max 100)
call_signNoFCC station call sign, e.g. E970199 or ANIK D (case-insensitive): every filing for that earth or space station. A call sign is a station, not a filing id; use this instead of get_filing_detail
entity_idNoApplicant entity UUID (from search_entities): filings this entity filed
source_idNoAgency file number, exact match (e.g. SAT-LOA-20200526-00055, LLO-22-126)
count_onlyNoIf true, return only {total: N} without fetching rows
filed_afterNoMinimum filed date (YYYY-MM-DD)
filed_beforeNoMaximum filed date (YYYY-MM-DD)
administrationNoITU only: notifying administration code, e.g. USA, CHN, F, G, D (case-insensitive)
source_id_prefixNoFile-number prefix: an application type (SES-LIC, SAT-LOA, SES-T/C, LLO), narrowed by year (SES-LIC-2024, VOL-23), a whole file number to include its revisions (VOL-23-129), or a UN document series (ST/SG/SER.E/12, A/AC.105)
brought_into_use_afterNoITU only: networks brought into use on or after this date (YYYY-MM-DD). For ITU networks filed_after/filed_before filter the first notification's receipt date instead
brought_into_use_beforeNoITU only: networks brought into use on or before this date (YYYY-MM-DD)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.10.0
    • addedInput schema / properties / administration
      Added value: +{
      +  "description": "ITU only: notifying administration code, e.g. USA, CHN, F, G, D (case-insensitive)",
      +  "type": "string"
      +}
    • addedInput schema / properties / brought_into_use_after
      Added value: +{
      +  "description": "ITU only: networks brought into use on or after this date (YYYY-MM-DD). For ITU networks filed_after/filed_before filter the first notification's receipt date instead",
      +  "type": "string"
      +}
    • addedInput schema / properties / brought_into_use_before
      Added value: +{
      +  "description": "ITU only: networks brought into use on or before this date (YYYY-MM-DD)",
      +  "type": "string"
      +}
    • changedInput schema / properties / docket / description
      Previous value: -"Filter by docket number (exact match)"New value: +"Filter by docket number, e.g. 22-271 (also accepts 'IB Docket No. 22-271', RM-11348, FAA-2024-2006)"
  2. Changed1 schema field changedv0.8.1
    • changedInput schema / properties / source_id_prefix / description
      Previous value: -"File-number prefix, e.g. SES-LIC, SAT-LOA, SES-T/C or LLO: filters by FCC application type"New value: +"File-number prefix: an application type (SES-LIC, SAT-LOA, SES-T/C, LLO), narrowed by year (SES-LIC-2024, VOL-23), a whole file number to include its revisions (VOL-23-129), or a UN document series (ST/SG/SER.E/12, A/AC.105)"
  3. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / call_sign
      Added value: +{
      +  "description": "FCC station call sign, e.g. E970199 or ANIK D (case-insensitive): every filing for that earth or space station. A call sign is a station, not a filing id; use this instead of get_filing_detail",
      +  "type": "string"
      +}
  4. Changed6 schema fields changedv0.7.0
    • changedInput schema / properties / agency / description
      Previous value: -"Filter by source agency (FCC, ITU, UN_OOSA, FAA_AST, NOAA)"New value: +"Filter by source agency, one of: ACMA_AU, CNES_FR, FAA_AST, FCC, ITU, NOAA, NTIA, OFCOM_UK, OTHER, SEC, STATE_AK, STATE_FL, STATE_TX, STATE_VA, UN_OOSA, USPTO"
    • addedInput schema / properties / entity_id
      Added value: +{
      +  "description": "Applicant entity UUID (from search_entities): filings this entity filed",
      +  "type": "string"
      +}
    • addedInput schema / properties / source_id
      Added value: +{
      +  "description": "Agency file number, exact match (e.g. SAT-LOA-20200526-00055, LLO-22-126)",
      +  "type": "string"
      +}
    • addedInput schema / properties / source_id_prefix
      Added value: +{
      +  "description": "File-number prefix, e.g. SES-LIC, SAT-LOA, SES-T/C or LLO: filters by FCC application type",
      +  "type": "string"
      +}
    • changedInput schema / properties / status / description
      Previous value: -"Filter by status (FILED, GRANTED, DENIED, UNDER_REVIEW, etc.)"New value: +"Filing (application) status, one of: ACCEPTED, CANCELLED, COMMENT_PERIOD, DENIED, DISMISSED, EXPIRED, FILED, GRANTED, PUBLIC_NOTICE, UNDER_REVIEW, UNKNOWN, WITHDRAWN"
    • changedInput schema / properties / type / description
      Previous value: -"Filter by filing type (SATELLITE_LICENSE, EARTH_STATION_PERMIT, SPECTRUM_COORDINATION, etc.)"New value: +"Filter by filing type, one of: ADVANCE_PUBLICATION, COMMENT, EARTH_STATION_PERMIT, ENVIRONMENTAL_ASSESSMENT, EXPERIMENTAL_LICENSE, EX_PARTE, LAUNCH_LICENSE, MODIFICATION, OPPOSITION, ORBITAL_DEBRIS_PLAN, OTHER, PETITION, REENTRY_LICENSE, REGISTRATION, REMOTE_SENSING_LICENSE, RENEWAL, SATELLITE_LICENSE, SPECIAL_TEMPORARY_AUTH, SPECTRUM_COORDINATION, TRANSFER_OF_CONTROL. For FCC application types such as SES-LIC use source_id_prefix"
  5. First observedv0.3.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is carried by structured data. The description adds real context: results are paginated and aggregated across FCC, ITU, UNOOSA, and other agencies. It does not disclose default ordering, what a filing record contains, or how count_only interacts with pagination, so it adds modest rather than rich behavioral context.

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?

Two sentences, front-loaded with the verb and resource, with zero boilerplate. The long mid-sentence filter enumeration is dense but each item corresponds to a distinct search dimension an agent would need. Slightly list-like, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter read-only search tool with 100% schema coverage but no output schema, the description covers scope, source agencies, and pagination adequately. The main residual gap is that, absent an output schema, nothing states what fields a returned filing record contains or its default sort order.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 17 parameters thoroughly, including enum value lists. The description restates the filter dimensions (keyword, agency, type, status, date range, file number exact-or-prefix, call sign, entity) at a level of detail the schema already provides. It adds marginal value by grouping the filters conceptually but does not extend meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Search space regulatory filings') and enumerates the filterable dimensions (keyword, agency, type, status, dates, file number, call sign, entity), plus the source agencies covered. It is unambiguous what the tool does. What it lacks is any naming of siblings like search_sec_filings, search_semantic, or search_space_station_authorizations, so the agent cannot tell from the description alone which search entry point applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use / when-not-to-use guidance in the description body. Usage is only implied by the enumerated filter fields, and the sibling routing hints ('use this instead of get_filing_detail', 'from search_entities') live inside individual schema parameter descriptions rather than the description itself. With six search_* siblings, this omission is material.

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