Search FCC radio licenses, find nearby licensed sites, and see who is licensed on a frequency.
Scored across 5 tools
Each tool has a clearly distinct purpose: spatial transmitter search, frequency/band search, license/lease attribute search, full record retrieval, and reference decoding. Descriptions cross-reference each other to steer users correctly (e.g., find_transmitters for coordinate-based site search), so an agent can reliably select the right tool.
All tools follow a consistent fcc_spectrum_ prefix with verb_noun snake_case (find_transmitters, get_license, list_reference, search_frequencies, search_licenses). The pattern is predictable and readable.
Five tools is well-scoped for a read-only FCC spectrum data server, covering the core access patterns without redundancy. Each tool earns its place.
The surface covers license search, frequency search, spatial transmitter search, full record retrieval, and code decoding, which are the main workflows. Minor gaps exist, such as no direct search by station class, emission designator, or coordinate-based license search, but agents can work around these via other tools.
Find FCC-licensed sites within a radius of a coordinate, nearest first, each with its callsign, licensee, distance, coordinates, filed location type and class, ground elevation, structure height, and authorized frequencies. Filter by frequency or band, radio service, location type, location class, and live status (active by default). Unset location_class keeps all filed roles, including receive and passive locations; filed classes describe authorization, not actual on-air activity. Coordinates are decimal degrees or DMS strings. Mobile and temporary-fixed operating areas are returned at their center with radiusKm and match when the center lies within radius_km. Locations without valid coordinates are omitted; market-area licenses without site records are found with fcc_spectrum_search_frequencies.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | Unit of the frequencies: kHz, MHz (default), or GHz. | MHz |
| limit | No | Positive integer sites per page; values above 100 are clamped to 100 with a notice. | |
| cursor | No | nextCursor from the previous page of the same search; omit for the first page. | |
| status | No | A active (default), L pending legal, X term pending, or "any" for all three. Other statuses keep no site records. | A |
| latitude | Yes | Search center latitude: decimal degrees (47.6205, "47.6205") or a DMS string with hemisphere ("47-37-13.8 N", "47°37'13.8"N"). | |
| longitude | Yes | Search center longitude: decimal degrees (-122.3493) or a DMS string with hemisphere ("122-20-57.5 W"). | |
| radius_km | No | Search radius in km (0.1–100). | |
| frequency_low | No | Only sites authorized on this frequency, in unit; with frequency_high, the band's lower edge. Matches any assignment whose occupied band overlaps. | |
| location_type | No | One ULS location type code, case-insensitive: "F" keeps fixed sites only, "M" mobile and "T" temporary-fixed operating areas; see fcc_spectrum_list_reference topic "location_types". Omit for every type. | |
| radio_service | No | Two-character radio service code, e.g. "IG" (industrial/business pool); see fcc_spectrum_list_reference topic "radio_services". | |
| frequency_high | No | Band upper edge in unit; requires frequency_low. | |
| location_class | No | One filed FCC location class, case-insensitive: C Centerpoint, L IQ/QQ Area of Operation Desc, P Passive Repeater Location, R Receive Location, T Transmit Location. Omit for every class; filed classes do not establish actual on-air activity. | |
| max_frequencies_per_site | No | Positive integer frequency budget per site; values above 50 are clamped to 50 with a notice. frequencyCount carries the full count. |
| Name | Required | Description |
|---|---|---|
| cap | No | The page limit applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Sites on this page. |
| sites | No | FCC-licensed sites, nearest first; filed classes can include transmit, receive, and passive roles. |
| notice | No | Why nothing matched and how to widen the search, or how to page further. |
| dataAsOf | No | Creation time of the newest applied ULS file (ISO 8601). |
| truncated | No | True when more sites follow this page. |
| nextCursor | No | Pass as cursor with the same inputs for the next page; absent on the last page. |
| totalCount | No | Sites within the radius matching the filters, across every page. |
| searchCenter | No | The search circle as the server applied it (DMS input converted). |
| appliedFilters | No | Filters as the server applied them, normalized values and defaults included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safe-read profile, but the description adds substantial behavioral detail beyond them: clamping notices for limit/frequency budget, mobile/temporary areas matched at center with radiusKm, omission of sites without valid coordinates, and the crucial caveat that filed classes describe authorization rather than on-air activity.
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?
Dense but front-loaded, leading with purpose and returned fields before the filter and edge-case caveats. Every sentence carries semantics, with only mild redundancy in re-listing returned fields already covered by the output schema.
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 13-parameter geo search with an output schema present, the description is complete on filtering semantics and edge cases without needing to explain return values. Enumerating returned fields is slightly redundant given the output schema, but nothing an agent needs to call correctly is 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 coverage is 100%, so the baseline is 3, but the description adds interpretive value: it clarifies that unset location_class retains all filed roles including receive/passive, and that coordinates accept decimal or DMS forms. These go beyond restating 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?
States a specific verb and resource ('Find FCC-licensed sites within a radius of a coordinate') plus ordering ('nearest first') and the returned fields. It clearly distinguishes itself from siblings by routing market-area licenses to fcc_spectrum_search_frequencies.
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?
Provides clear context (radius search, active-by-default, filterable dimensions) and explicitly redirects to a sibling for market-area licenses lacking site records. It does not state when to prefer this over fcc_spectrum_search_licenses, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one FCC ULS license or spectrum lease in full by callsign or unique system identifier (USI): licensee (the lessee on a lease), status and key dates, its locations with coordinates, elevation, structure height, and ASR number, each location's antennas, and each antenna's authorized frequencies with power, ERP/EIRP, station class, transmitter, and emission designators; geographic-area licenses list their market and spectrum blocks, and lease links are shown in both directions. Large records are paged: one call lists whole locations up to 50 sites and 100 antennas, up to max_frequencies frequency rows, and 100 leases, and names the location_offset or lease_offset that reads the rest; location_number starts the locations at a location number the search tools return. Technical detail is kept for active, pending-legal, and term-pending records only. A callsign shared by several records returns the active one, else the most recent.
| Name | Required | Description | Default |
|---|---|---|---|
| usi | No | Unique system identifier, as digits: the usi field of fcc_spectrum_search_licenses, fcc_spectrum_find_transmitters, or fcc_spectrum_search_frequencies results. Pass this or callsign, not both. | |
| callsign | No | Callsign or lease ID, e.g. "KNKA123" or "L000012345". Case, spaces, and one trailing portable suffix ("/4") are normalized. Pass this or usi, not both. | |
| lease_offset | No | Lease to start at, counted from 0 in lease-ID order; pass nextLeaseOffset from the previous call to read the next 100. | |
| location_number | No | Location number to start at: the locationNumber of a fcc_spectrum_find_transmitters or fcc_spectrum_search_frequencies result. A number the record does not file starts at the next one it does. Pass this or a nonzero location_offset, not both; page on with nextLocationOffset. | |
| location_offset | No | Location to start at, counted from 0 in location-number order; pass nextLocationOffset from the previous call to read the next locations. To start at a location number instead, pass location_number. | |
| max_frequencies | No | Positive integer frequency-row budget across the locations this call lists; values above 1000 are clamped to 1000 with a notice. Rows beyond it are dropped from the last locations first. Large microwave and land-mobile licenses exceed the default. |
| Name | Required | Description |
|---|---|---|
| cap | No | The max_frequencies cap applied. |
| error | No | Present when the call failed. Absent on success. |
| found | No | True when a record matched; false returns guidance and candidates instead. |
| shown | No | Frequency rows returned. |
| notice | No | What this call left out and the call that reads it, where an unfiled location_number started the locations, or why an offset or location number listed nothing. |
| license | No | The record; present when found is true. |
| dataAsOf | No | Creation time of the newest applied ULS file (ISO 8601). |
| guidance | No | Why nothing matched and where to look next; present when found is false. |
| locations | No | Locations with antennas and frequency rows, one entry per location number (a number filed at several sites lists them in sites): whole locations from location_offset or location_number up to 50 sites and 100 antennas, or one larger location alone; present when found is true. |
| siteTotal | No | Sites the record files, each site of a shared location number counted; present when found is true. |
| truncated | No | True when this call leaves part of the record out: locations after the ones listed, frequency rows beyond max_frequencies, or leases after the ones listed. |
| candidates | No | Up to 5 records whose callsign starts with the one requested; present when a callsign lookup found nothing. |
| locationTotal | No | Location numbers the record files; present when found is true. |
| nextLeaseOffset | No | Pass as lease_offset to read the leases after these; absent when none follow. |
| technicalRetained | No | False when the status is not A, L, or X (active, pending legal, term pending): sites and frequencies are kept only for those, so locations is empty. |
| nextLocationOffset | No | Pass as location_offset to read the locations after these; absent when none follow. |
| otherCallsignRecords | No | Other records under the same callsign (ULS reuses callsigns); present when found is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/closed-world, but the description adds substantial non-obvious behavior: paging limits (50 sites, 100 antennas, max_frequencies rows, 100 leases) with the offsets that resume them, frequency-budget clamping to 1000 with a notice, rows dropped from the last locations first, and the retention rule that technical detail is kept only for active/pending-legal/term-pending records. The callsign-collision resolution rule ('returns the active one, else the most recent') is exactly the kind of behavior an agent could not infer.
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?
Front-loaded correctly: the verb, resource, and lookup keys come first, with paging and edge-case rules following. However, the opening sentence is a very long semicolon chain and the paging rules are densely packed, making it heavier to parse than necessary for the amount of information conveyed.
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 six parameters, non-trivial paging, and a present output schema, the description covers everything an agent needs: how to identify the record, what the record contains, how to page through locations/leases/frequencies, and which records retain technical detail. Return-value formatting is correctly left to the output schema.
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 baseline is 3, and the description exceeds it by tying the parameters into a coherent paging model — explaining what location_offset and lease_offset resume, how location_number interacts with offset, and that max_frequencies is a budget across locations that can be exceeded by large microwave/land-mobile licenses. It largely restates the per-parameter text rather than adding new syntax, so it is not a 5.
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?
States a specific verb and resource: 'Fetch one FCC ULS license or spectrum lease in full by callsign or unique system identifier (USI).' It then enumerates the record contents (licensee, status, locations, antennas, frequencies), which distinguishes it clearly from the search/list siblings. An agent can tell this is the single-record detail fetch without opening a schema.
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 gives clear context: it fetches ONE record 'in full', and references identifiers the search tools return ('location_number ... a location number the search tools return'), implying it is the detail step after a search. It does not, however, explicitly say when not to use it or name a sibling as the alternative, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode FCC ULS codes used by the other tools — radio service codes, station classes, license statuses, location types, antenna types, applicant types, amateur operator classes — or report coverage: which service groups this index holds, record counts, and when each was last updated. Works before the index is built. Station classes describe licensed categories, not actual on-air activity.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | What to list: a code vocabulary (radio_services, station_classes, license_statuses, location_types, antenna_types, applicant_types, operator_classes) or coverage, the index build state and loaded service groups. | |
| filter | No | radio_services and station_classes only: keep entries whose code and label contain every token given, in any order (e.g. "700 public safety" or "FB2"). Case- and accent-insensitive; punctuation separates tokens. A nonblank filter must normalize to at least one ASCII letter or digit; blank means unset. Other topics disclose that filter was not applied. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| index | No | Index build state; present for coverage. |
| topic | No | The topic answered. |
| groups | No | Every weekly service group this server can index, with whether it is loaded; present for coverage. |
| notice | No | Guidance when a filter matched nothing, was not applied, or the index is not built yet. |
| entries | No | Decoded codes, in code order; present for every topic except coverage. |
| dataAsOf | No | Creation time of the newest applied ULS file (ISO 8601); absent before the index is built. |
| redactIndividuals | No | True when individual licensees are redacted and excluded from name search; present for coverage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/closed-world, so the description earns credit for going further: it discloses that the tool still functions before the index is built, and warns that station classes are licensed categories rather than actual on-air activity — a semantic caveat an agent would otherwise get wrong.
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?
Dense but front-loaded, leading with the decode purpose before the coverage alternative and the station-class caveat. No wasted sentences, though the long em-dash enumeration is slightly heavy.
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?
With an output schema present, return values need not be described, and annotations cover safety. The description covers both modes (decode vs coverage) and the key caveat; the only omission is an explicit statement of when to prefer this over fetching a license directly.
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% (baseline 3), but the description adds real meaning beyond the schema: it spells out what "coverage" returns (service groups held, record counts, last-updated) and characterizes the vocabularies. It does not restate the filter's token-normalization rules, which the schema already handles.
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?
Specific verb+resource: decode FCC ULS code vocabularies or report index coverage. The enumeration of code families makes it immediately distinguishable from the fcc_spectrum_search_*/find_* siblings, which operate on records rather than reference vocabularies.
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?
"Decode FCC ULS codes used by the other tools" frames this as the lookup companion to the sibling search tools, and "Works before the index is built" gives a clear precondition context. No explicit when-not guidance, but the reference-vs-record distinction is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find FCC ULS authorizations whose occupied band overlaps a frequency or band. Site assignments (land mobile, microwave, paging, cellular sites) return one row per site and frequency with the site's state and coordinates; market-area licenses and leases (PCS, AWS, 700 MHz, 3.45 and 3.7 GHz, and other auctioned blocks) return one row per spectrum block with its market code and name; 3.5 GHz Priority Access Licenses file no frequency, so list them with fcc_spectrum_search_licenses and radio_service PL. Filter by state, radio service, licensee, FRN, market code, and live status (active by default). For transmitter sites near a coordinate, use fcc_spectrum_find_transmitters.
| Name | Required | Description | Default |
|---|---|---|---|
| frn | No | Licensee's FCC Registration Number, up to 10 digits; spaces and hyphens are removed and it is left-padded with zeros. Individual licensees match and are returned redacted. | |
| kind | No | site: transmitter-site assignments only; market: market-area spectrum blocks only; both (default). | both |
| unit | No | Unit of the frequencies: kHz, MHz (default), or GHz. | MHz |
| limit | No | Positive integer rows per page; values above 200 are clamped to 200 with a notice. | |
| state | No | Two-letter USPS code or full state name. Sites match on their filed state, or the state derived from their coordinates. Market blocks match when their FCC market area reaches the state (a multi-state market matches each of its states), their market name carries the state code, or their license files a site there; nationwide and Gulf of Mexico markets match no state. | |
| cursor | No | nextCursor from the previous page of the same search; omit for the first page. | |
| status | No | A active (default), L pending legal, X term pending, or "any" for all three. Other statuses keep no frequency records. | A |
| licensee | No | Licensee name words, with at least one letter or digit; every word must match the start of a word in the name, in any order. A word joined by - or & ("T-Mobile", "AT&T") matches its pieces side by side. | |
| market_code | No | Market code of the license, matched exactly, e.g. "PEA016", "CMA020", or "NW" (nationwide); market rows carry it as marketCode. Applies to site and market rows alike, since cellular (CMA) licenses file sites rather than blocks. Case, spaces, and hyphens are ignored, and the digits are left-padded with zeros ("pea16" reads as PEA016). | |
| frequency_low | Yes | Frequency in unit; with frequency_high, the band's lower edge. Matches any authorization whose occupied band overlaps. | |
| radio_service | No | Two-character radio service code, e.g. "WU" (700 MHz upper band); see fcc_spectrum_list_reference topic "radio_services". | |
| frequency_high | No | Band upper edge in unit; omit to search a single frequency. |
| Name | Required | Description |
|---|---|---|
| cap | No | The page limit applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Rows on this page. |
| notice | No | Why nothing matched, what the state and redaction rules skipped, or how to page further. |
| dataAsOf | No | Creation time of the newest applied ULS file (ISO 8601). |
| truncated | No | True when more rows follow this page. |
| nextCursor | No | Pass as cursor with the same inputs for the next page; absent on the last page. A page over a dense band can hold fewer rows than limit and still carry one. |
| totalCount | No | Rows matching the filters, across every page; at least this many when totalIsLowerBound is true. |
| assignments | No | Matching site assignments and market blocks, frequency ascending. |
| appliedFilters | No | Filters as the server applied them, normalized values and defaults included. |
| totalIsLowerBound | No | True when a dense band was counted only in part, so totalCount is a lower bound; absent when the count is exact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-open-world profile, but the description adds genuinely useful behavior: site assignments return one row per site+frequency with state/coordinates, market-area licenses return one row per spectrum block with market code and name, and status defaults to active while other statuses keep no frequency records. It does not discuss pagination/cursor exhaustively, but the important shape-branching semantics are disclosed.
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?
Front-loads the core operation in the first sentence, then layers result-shape and routing detail. It is dense and multi-clause, and the row-shape sentences partly overlap the output schema, but no sentence is filler.
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?
With 12 parameters, an output schema, and annotations already present, the description still supplies the routing decisions, default-status behavior, and the site-vs-market row semantics an agent needs to interpret results correctly. Nothing material is 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 coverage is 100%, so every parameter is already documented in detail, including unit, kind, limit clamping, and the market_code pattern. The description's list of filter dimensions (state, radio service, licensee, FRN, market code, status) largely restates the schema, so the baseline 3 applies.
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?
States a specific verb and resource ('Find FCC ULS authorizations') plus the precise matching semantics ('whose occupied band overlaps a frequency or band'). This clearly separates it from fcc_spectrum_search_licenses (license-level lookups) and fcc_spectrum_find_transmitters (site search near a coordinate).
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?
Explicitly routes the agent: use fcc_spectrum_search_licenses with radio_service PL for 3.5 GHz PALs that file no frequency, and fcc_spectrum_find_transmitters for transmitter sites near a coordinate. It also names the filter dimensions and the default status scope, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FCC ULS licenses and spectrum leases by callsign, licensee name, FCC Registration Number (FRN), market code, radio service, status, and licensee state, returning one row per record with its unique system identifier (USI) for fcc_spectrum_get_license. At least one of callsign, licensee, frn, market_code, radio_service, or state is required; status only narrows. Defaults to active records; pass status "any" to include expired, cancelled, and terminated ones. Licensee name matching is word-based (every word must appear as a word prefix), not fuzzy.
| Name | Required | Description | Default |
|---|---|---|---|
| frn | No | FCC Registration Number, up to 10 digits; spaces and hyphens are removed and it is left-padded with zeros. | |
| limit | No | Positive integer records per page; values above 100 are clamped to 100 with a notice. | |
| state | No | Licensee mailing state: a two-letter USPS code (incl. DC, PR, VI, GU, AS, MP) or a full state name. This is the licensee's address, not the site location. | |
| cursor | No | nextCursor from the previous page of the same search; omit for the first page. | |
| status | No | License status: A active, L pending legal, X term pending, E expired, C canceled, T terminated, P parent station canceled, or "any" for every status. Defaults to A. | A |
| callsign | No | Exact callsign or lease ID, e.g. "KNKA123" or "L000012345". Case, spaces, and one trailing portable suffix ("/4") are normalized. ULS reuses callsigns, so several records can match. | |
| licensee | No | Licensee name words, with at least one letter or digit; every word must match the start of a word in the name, in any order (e.g. "verizon wireless"). A word joined by - or & ("T-Mobile", "AT&T") matches its pieces side by side. | |
| market_code | No | Market code of a geographic-area license, matched exactly, e.g. "PEA016", "CMA020", "D06037", or "NW" (nationwide); results carry it as marketCode. Case, spaces, and hyphens are ignored, and the digits are left-padded with zeros ("pea16" reads as PEA016). | |
| radio_service | No | Two-character radio service code, e.g. "CD" (paging) or "BR" (BRS); see fcc_spectrum_list_reference topic "radio_services". |
| Name | Required | Description |
|---|---|---|
| cap | No | The page limit applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Records on this page. |
| notice | No | Why nothing matched, what redaction excluded, or how to page further. |
| dataAsOf | No | Creation time of the newest applied ULS file (ISO 8601). |
| licenses | No | Matching records, ranked by name-match relevance when licensee is given and in callsign order otherwise. |
| truncated | No | True when more records follow this page. |
| nextCursor | No | Pass as cursor with the same filters for the next page; absent on the last page. |
| totalCount | No | Records matching the filters, across every page. |
| appliedFilters | No | Filters as the server applied them, normalized values and defaults included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds non-obvious behavior well beyond the readOnly/idempotent annotations: default filtering to active records, that status "any" is needed to see expired/cancelled/terminated ones, that results are one row per record, and that licensee matching is word-prefix based rather than fuzzy. These are exactly the traits an agent would otherwise get wrong on the first call.
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?
Three dense sentences with zero filler: search scope first, the required-term constraint second, then defaults and matching semantics. Every clause carries operational information and the most important constraint is front-loaded.
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 9-parameter search tool with an output schema and read-only annotations, the description covers what the structured fields cannot: the required-term rule, default status filtering, and name-matching algorithm. Pagination and value formats are fully handled by the schema, so nothing consequential is 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 100%, so the baseline is 3, and the description adds a genuine semantic that the schema does not encode: the at-least-one-search-term requirement. It also reinforces status-narrowing and the non-fuzzy licensee semantics, though per-field syntax details remain the schema's job.
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?
States a specific verb (search) and resource (FCC ULS licenses and spectrum leases), enumerates the searchable fields, and describes the return shape (one row per record with its USI). It also names the sibling fcc_spectrum_get_license as the consumer of the returned USI, so an agent can distinguish it from search_frequencies and find_transmitters.
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?
Gives a hard usage constraint that isn't in the schema (at least one of callsign/licensee/frn/market_code/radio_service/state is required, status only narrows) plus the default-status behavior and the "any" escape hatch. It routes to fcc_spectrum_get_license but never explicitly contrasts itself with the other search siblings, so it stops short of full when-not/alternative coverage.
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.
fcc_spectrum_find_transmitters11 fields changedInput schema / properties / limit / descriptionPrevious value: -"Sites per page (1–100)."New value: +"Positive integer sites per page; values above 100 are clamped to 100 with a notice."Input schema / properties / limit / maximumPrevious value: -100New value: +9007199254740991Input schema / properties / location_classAdded value: +{
+ "description": "One filed FCC location class, case-insensitive: C Centerpoint, L IQ/QQ Area of Operation Desc, P Passive Repeater Location, R Receive Location, T Transmit Location. Omit for every class; filed classes do not establish actual on-air activity.",
+ "enum": [
+ "C",
+ "L",
+ "P",
+ "R",
+ "T"
+ ],
+ "type": "string"
+}Input schema / properties / max_frequencies_per_site / descriptionPrevious value: -"Most frequencies listed per site (1–50); frequencyCount carries the full count."New value: +"Positive integer frequency budget per site; values above 50 are clamped to 50 with a notice. frequencyCount carries the full count."Input schema / properties / max_frequencies_per_site / maximumPrevious value: -50New value: +9007199254740991Output schema / properties / appliedFilters / properties / location_classAdded value: +{
+ "description": "Filed location class filter.",
+ "type": "string"
+}Output schema / properties / sites / descriptionPrevious value: -"Transmitter sites, nearest first."New value: +"FCC-licensed sites, nearest first; filed classes can include transmit, receive, and passive roles."Output schema / properties / sites / items / descriptionPrevious value: -"One transmitter site."New value: +"One FCC-licensed site with its filed location role."Output schema / properties / sites / items / properties / frequencies / items / properties / stationClasses / descriptionPrevious value: -"Distinct station classes filed for this frequency across antennas and modulation steps."New value: +"Distinct station classes filed for this frequency across antennas and modulation steps; decode each with fcc_spectrum_list_reference, topic \"station_classes\", filter set to the code. Unknown filed codes remain unchanged."Output schema / properties / sites / items / properties / locationClassCodeAdded value: +{
+ "description": "Filed FCC location class: C centerpoint, L area description, P passive repeater, R receive, T transmit; absent when not filed.",
+ "type": "string"
+}Output schema / properties / sites / items / properties / locationClassLabelAdded value: +{
+ "description": "FCC label of the filed class; absent for an unknown code. Authorization metadata does not establish actual on-air activity.",
+ "type": "string"
+}fcc_spectrum_get_license7 fields changedInput schema / properties / max_frequencies / descriptionPrevious value: -"Most frequency rows to return across the locations this call lists (1–1000); rows beyond it are dropped from the last locations first. Large microwave and land-mobile licenses exceed the default."New value: +"Positive integer frequency-row budget across the locations this call lists; values above 1000 are clamped to 1000 with a notice. Rows beyond it are dropped from the last locations first. Large microwave and land-mobile licenses exceed the default."Input schema / properties / max_frequencies / maximumPrevious value: -1000New value: +9007199254740991Output schema / properties / locations / items / properties / antennas / items / properties / antennaNumber / descriptionPrevious value: -"Antenna number within the location."New value: +"Filed antenna number within the location; absent for an independently retained unnumbered AN record, which has no associated frequency rows."Output schema / properties / locations / items / properties / antennas / items / properties / frequencies / items / properties / stationClass / descriptionPrevious value: -"ULS class-of-station code, as filed (e.g. FB2, FXO)."New value: +"ULS class-of-station code, as filed (e.g. FB2, FXO); decode with fcc_spectrum_list_reference, topic \"station_classes\", filter set to this code. Unknown filed codes remain unchanged."Output schema / properties / locations / items / properties / antennas / items / requiredPrevious value: -[
- "antennaNumber",
- "frequencies"
-]New value: +[
+ "frequencies"
+]Output schema / properties / locations / items / properties / locationClassLabelAdded value: +{
+ "description": "FCC label of the filed location class; absent for an unknown code. This is authorization metadata, not actual on-air activity.",
+ "type": "string"
+}Output schema / properties / locations / items / properties / sites / items / properties / locationClassLabelAdded value: +{
+ "description": "FCC label of the filed location class; absent for an unknown code. This is authorization metadata, not actual on-air activity.",
+ "type": "string"
+}fcc_spectrum_list_reference7 fields changedInput schema / properties / filter / descriptionPrevious value: -"Radio services only: keep entries whose code and label contain every word given, in any order (e.g. \"700 public safety\"). Case- and accent-insensitive."New value: +"radio_services and station_classes only: keep entries whose code and label contain every token given, in any order (e.g. \"700 public safety\" or \"FB2\"). Case- and accent-insensitive; punctuation separates tokens. A nonblank filter must normalize to at least one ASCII letter or digit; blank means unset. Other topics disclose that filter was not applied."Input schema / properties / topic / descriptionPrevious value: -"What to list: a code vocabulary (radio_services, license_statuses, location_types, antenna_types, applicant_types, operator_classes) or coverage, the index build state and loaded service groups."New value: +"What to list: a code vocabulary (radio_services, station_classes, license_statuses, location_types, antenna_types, applicant_types, operator_classes) or coverage, the index build state and loaded service groups."Input schema / properties / topic / enumPrevious value: -[
- "radio_services",
- "license_statuses",
- "location_types",
- "antenna_types",
- "applicant_types",
- "operator_classes",
- "coverage"
-]New value: +[
+ "radio_services",
+ "station_classes",
+ "license_statuses",
+ "location_types",
+ "antenna_types",
+ "applicant_types",
+ "operator_classes",
+ "coverage"
+]Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_filter`: A nonblank filter on radio_services or station_classes normalizes to no searchable tokens. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesAdded value: +[
+ "invalid_filter"
+]Output schema / properties / index / properties / antennaCoverageIncompleteAdded value: +{
+ "description": "True when earlier decoding discarded unnumbered antenna records; searches remain available, but a complete weekly rebuild is needed.",
+ "type": "boolean"
+}Output schema / properties / topic / enumPrevious value: -[
- "radio_services",
- "license_statuses",
- "location_types",
- "antenna_types",
- "applicant_types",
- "operator_classes",
- "coverage"
-]New value: +[
+ "radio_services",
+ "station_classes",
+ "license_statuses",
+ "location_types",
+ "antenna_types",
+ "applicant_types",
+ "operator_classes",
+ "coverage"
+]fcc_spectrum_search_frequencies5 fields changedInput schema / properties / limit / descriptionPrevious value: -"Rows per page (1–200)."New value: +"Positive integer rows per page; values above 200 are clamped to 200 with a notice."Input schema / properties / limit / maximumPrevious value: -200New value: +9007199254740991Output schema / properties / assignments / items / properties / locationClassCodeAdded value: +{
+ "description": "Filed FCC location class, only on a single-site assignment; absent on shared-number assignments and market rows.",
+ "type": "string"
+}Output schema / properties / assignments / items / properties / locationClassLabelAdded value: +{
+ "description": "FCC label of the filed class, only when known on a single-site assignment. Authorization metadata does not establish actual on-air activity.",
+ "type": "string"
+}Output schema / properties / assignments / items / properties / stationClasses / descriptionPrevious value: -"Distinct station classes filed for this frequency at the site (site rows)."New value: +"Distinct station classes filed for this frequency at the site (site rows); decode each with fcc_spectrum_list_reference, topic \"station_classes\", filter set to the code. Unknown filed codes remain unchanged."fcc_spectrum_search_licenses2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Records per page (1–100)."New value: +"Positive integer records per page; values above 100 are clamped to 100 with a notice."Input schema / properties / limit / maximumPrevious value: -100New value: +9007199254740991fcc_spectrum_find_transmittersfcc_spectrum_get_licensefcc_spectrum_list_referencefcc_spectrum_search_frequenciesfcc_spectrum_search_licensesExplore FCC ULS licenses, ASR antenna structures, and microwave path elevation profiles.
Search FCC radio licenses by company, call sign, or FRN; monitor status changes and snapshots.
FCC Open Data (opendata.fcc.gov) Socrata MCP.
FCC Electronic Comment Filing System public search and retrieval.
Add one secure layer between your agents and this server.