A
licenseNot graded
qualityB
maintenanceEnables querying and exploring FCC Open Data datasets via Socrata SoQL, including dataset search, metadata retrieval, and data querying.
31 npm
MIT
fcc-broadband-mcp-server
Server Details
FCC broadband availability, coverage analysis, and digital divide data for US geographies.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.9% over 68 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/fcc-broadband-mcp-server
- GitHub Stars
- 1
- Server Listing
- fcc-broadband-mcp-server
TDQS
A4.2/5.0
Scored across 9 tools
Disambiguation4/5
Most tools have clearly distinct purposes, but fcc_find_underserved, fcc_compare_areas, and fcc_get_coverage_summary all return coverage metrics for areas, so an agent must read carefully to avoid misselection. The descriptions do clarify the differences (discovery vs. comparison vs. summary), keeping ambiguity limited.
Naming Consistency5/5
All tools follow a consistent fcc_verb_noun or fcc_verb_noun_noun pattern with snake_case throughout. Verbs like get, search, compare, find, list, and geocode accurately reflect each tool's action.
Tool Count5/5
Nine tools is well-scoped for an FCC broadband data analysis server, covering geocoding, availability, provider lookup, area comparison, and metadata without excessive redundancy.
Completeness3/5
The core analysis workflow is largely covered, but fcc_list_downloads is referenced in fcc_list_filing_periods yet missing, and there are no tools to resolve county, state, or tribal geography IDs needed by fcc_get_coverage_summary and fcc_compare_areas. BDC data access also appears incomplete beyond listing filing periods.
Available Tools
9 toolsfcc_compare_areasCompare Broadband Coverage Across AreasARead-onlyIdempotentInspect
Compares broadband coverage metrics across multiple geographies of the same type and returns a ranked table sorted by unserved or underserved population. Answers "which counties in this state have the worst broadband access?" and drives BEAD funding prioritization. Provide up to 50 geography IDs, or set compare_all_states=true for all 50 states + DC. Data is from FCC Form 477 (as of June 2021).
| Name | Required | Description | Default |
|---|---|---|---|
| sort_by | No | "unserved_pct" = share of population with no broadband (default). "unserved_pop" = raw headcount for BEAD funding. "coverage_pct" = share with any coverage. "competitive_pct" = share with 2+ providers. Every option ranks worst-first, so rank 1 is the highest unserved share or headcount, or the lowest coverage or competitive share. | unserved_pct |
| speed_down | No | Download speed threshold in Mbps. 25 = FCC legacy standard. 100 = BEAD program standard. | 25 |
| tech_filter | No | Technology filter, one value: "acfosw" = every technology (default). "f" = fiber, "c" = cable, "a" = ADSL/DSL, "o" = other (symmetric DSL, other copper, power line), "s" = satellite, "w" = fixed wireless. | acfosw |
| geography_ids | No | Array of FIPS GEOIDs to compare (up to 50). For all 50 states, omit and set compare_all_states=true. | |
| geography_type | Yes | Geographic level to compare. Must be uniform across all geographies in the comparison. | |
| compare_all_states | No | When true, compares all 50 states + DC. Overrides geography_ids. Requires geography_type="state". |
Output Schema
| Name | Required | Description |
|---|---|---|
| areas | No | Ranked comparison of geographies by the selected sort field. |
| error | No | Present when the call failed. Absent on success. |
| sortBy | No | Ranking field used. |
| techFilter | No | Technology filter applied. |
| totalAreas | No | Total number of areas compared. |
| dataVintage | No | Data vintage — Form 477 data as of June 2021. |
| geographyType | No | Geography type compared. |
| speedDownMbps | No | Speed threshold in Mbps. |
| appliedFilters | No | Filters and parameters applied to this comparison. |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's contribution is the data vintage and provenance: 'FCC Form 477 (as of June 2021)' tells the agent results are historical and not real-time. It also discloses the 50-geography cap and that the result is a ranked table rather than raw records. It does not discuss pagination or how ties/absent geographies are handled.
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?
Four sentences, front-loaded with the core action and output, then the driving use case, then the input modes, then provenance. No filler, though the geography_ids/compare_all_states sentence is largely duplicative of the schema and could be trimmed.
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?
With an output schema present the description needn't explain return fields, and annotations plus the rich schema cover parameters and safety. What it adds, data vintage and the comparison scope, is the right residual information; only minor operational details (rate limits, behavior when a FIPS GEOID is invalid) are unaddressed.
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%: sort_by rankings direction, speed thresholds (25 legacy vs 100 BEAD), tech_filter codes, and the compare_all_states override are all exhaustively documented in the schema. The description only restates the 50-ID cap and the compare_all_states rule, adding no new syntax or default information, so the baseline 3 applies.
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 (compares) and resource (broadband coverage metrics) plus the output shape (a ranked table) and the scope constraint (multiple geographies of the same type). The phrase 'across multiple geographies' distinguishes it from single-geography siblings like fcc_get_coverage_summary, and the sample question 'which counties in this state have the worst broadband access?' pins the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: it answers a worst-access ranking question and drives BEAD funding prioritization, and it states the two mutually exclusive input modes (list up to 50 IDs, or compare_all_states=true for all 50 states + DC). It never explicitly says when NOT to use it or names a sibling as an alternative, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_find_underservedFind Underserved AreasARead-onlyIdempotentInspect
Finds geographic areas with limited or no broadband coverage at a given speed threshold, ranked by unserved population. The core tool for BEAD program analysis and broadband equity research. Accepts a state abbreviation to narrow scope or runs nationwide. Defaults to rural areas where underservice is most concentrated. Data is from FCC Form 477 (as of June 2021).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of areas to return, ranked by unserved population (descending). | |
| state | No | 2-letter USPS state or territory code (e.g., "WY", "MS", "PR") to limit scope. An unrecognized code is rejected, not ignored. Omit for nationwide search — returns top areas only. | |
| speed_down | No | Download speed threshold in Mbps for defining "underserved." 25 = FCC legacy standard. 100 = BEAD program standard. | 25 |
| tech_filter | No | Technology filter, one value: "acfosw" = every technology (default). "f" = fiber, "c" = cable, "a" = ADSL/DSL, "o" = other (symmetric DSL, other copper, power line), "s" = satellite, "w" = fixed wireless. | acfosw |
| geography_type | No | Geographic granularity for results. "county" is most useful for policy analysis and BEAD eligibility. "cd" = congressional district. "place" = census-designated place. "cbsa" = metro area. | county |
| min_unserved_pop | No | Minimum population with no coverage to include. Defaults to 1, which keeps fully covered areas out of a ranking of underserved ones. Set to 0 to rank every area regardless of unserved population, or higher to drop small gaps (e.g., 500 keeps only areas with at least 500 unserved residents). | |
| urban_rural_filter | No | Defaults to rural ("R") — where underservice is most concentrated. Use "U" to find underserved urban areas (digital redlining research). Set to "all" for both. | R |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. Present when truncated. |
| areas | No | Ranked list of underserved areas. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of areas returned after applying the limit. Present when truncated. |
| notice | No | Guidance about the result set — how to broaden the filters when nothing matched, and how to narrow the query when the upstream scan hit its row ceiling. Absent when neither applies. |
| truncated | No | True when more areas matched than the limit returned. Absent when not truncated. |
| scanRowCap | No | Raw upstream row ceiling that bound the scan. Present only when scanTruncated is true. |
| totalFound | No | Total number of areas found before applying the limit filter. |
| dataVintage | No | Data vintage — Form 477 data as of June 2021. |
| geographyType | No | Geography type returned. |
| scanTruncated | No | True when the upstream row scan stopped at its ceiling before reaching the end of the matching data, so totalFound and the ranking cover only the portion that was scanned. Absent when the scan read every matching row. |
| speedDownMbps | No | Speed threshold used in Mbps. |
| appliedFilters | No | Filters applied to this query. |
| urbanRuralFilter | No | Urban/rural filter applied. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered and the bar is lower. The description usefully adds the data provenance and vintage ('FCC Form 477 as of June 2021'), which tells the agent the results are historical rather than live, but it says nothing about result size, ordering ties, or pagination behavior.
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?
Four sentences, front-loaded with the core action and scope, then defaults and provenance. Every sentence carries information, though the 'broadband equity research' clause is slightly promotional rather than operational.
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?
With an output schema present and annotations covering the safety profile, the description supplies exactly the missing pieces an agent needs: what defines 'underserved', the default scoping (nationwide vs state, rural vs urban), and the data vintage. Nothing required for correct invocation is absent.
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% and the parameter docs are unusually rich (enum meanings, defaults, the 25 vs 100 Mbps standard, the min_unserved_pop=0 edge case), so the schema does the heavy lifting. The description only loosely gestures at the speed threshold and geographic scope, adding essentially no parameter meaning beyond the schema.
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 ('Finds geographic areas with limited or no broadband coverage') plus the ranking rule ('ranked by unserved population'), which separates it from fcc_get_coverage_summary and fcc_compare_areas without opening their schemas. Naming it 'the core tool for BEAD program analysis' further anchors its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: state abbreviation narrows scope, omission runs nationwide, and the default is rural because that is where underservice concentrates. It stops short of explicit when-not guidance or naming an alternative sibling for the cases this tool does not cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_geocode_blockGeocode Census BlockARead-onlyIdempotentInspect
Converts a latitude/longitude coordinate to a 15-digit census block FIPS code, plus county FIPS, county name, state FIPS, state code, and state name. This is the required prerequisite for fcc_search_availability since the broadband dataset is indexed by census block, not address. The block is resolved against 2010 census boundaries, the vintage the Form 477 deployment dataset is keyed by, so the returned blockFips can be passed straight to fcc_search_availability; a 2020-vintage block ID from another source will not match. Uses the FCC public Geo API — no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude of the location in decimal degrees (e.g., 47.6062 for Seattle, WA). Must be within the continental US, Alaska, Hawaii, or US territories. | |
| longitude | Yes | Longitude of the location in decimal degrees (e.g., -122.3321 for Seattle, WA). Negative for western hemisphere. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| blockFips | No | 15-digit census block FIPS code on 2010 census boundaries (e.g., "530330081002024"). Pass this to fcc_search_availability to look up broadband providers. |
| stateCode | No | 2-letter state abbreviation (e.g., "WA"). |
| stateFips | No | 2-digit state FIPS code (e.g., "53" for Washington). |
| stateName | No | Full state name (e.g., "Washington"). |
| countyFips | No | 5-digit county FIPS code (e.g., "53033" for King County, WA). |
| countyName | No | Human-readable county name (e.g., "King"). |
| censusVintage | No | Decennial census whose block boundaries blockFips belongs to. Always "2010" — the vintage the Form 477 deployment dataset behind fcc_search_availability is keyed by. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, but the description adds genuinely new operational context: no authentication is required, the lookup runs against 2010 census boundaries, and the vintage constraint is exactly what determines whether downstream calls will succeed. This is the kind of behavioral caveat annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each load-bearing: the conversion and its outputs, the prerequisite relationship, and the vintage/auth caveat. The core purpose is front-loaded and nothing is repeated from the schema or annotations.
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-value structure need not be explained, yet the description still names the key output (blockFips) needed to chain into fcc_search_availability. Combined with the vintage constraint and no-auth note, an agent has everything required to call this correctly and use the result.
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%, and the schema already documents latitude/longitude ranges, hemisphere sign convention, and the US-territory constraint, so the baseline is 3. The description adds no per-parameter syntax or format detail beyond the schema, merely restating that a coordinate pair is the input.
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 ('Converts a latitude/longitude coordinate to a 15-digit census block FIPS code') and enumerates the returned fields, so the transformation is unambiguous. It also distinguishes itself from siblings by naming fcc_search_availability as the downstream consumer rather than a substitute.
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 this is 'the required prerequisite for fcc_search_availability since the broadband dataset is indexed by census block, not address' — a clear when-to-use rule tied to a named sibling. It further constrains usage with the 2010-vintage requirement, warning that a 2020 block ID from another source will not match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_get_coverage_summaryGet Broadband Coverage SummaryARead-onlyIdempotentInspect
Returns a broadband coverage summary for a geography — population with zero, one, two, or three-plus providers at a given speed threshold, split by urban/rural and tribal/non-tribal segments. The primary tool for digital divide and equity analysis. Supports state, county, congressional district, census place, CBSA (metro area), tribal area, and national level. Data is from FCC Form 477 (as of June 2021). Use 100 Mbps as the speed threshold for BEAD program policy analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| speed_down | No | Minimum download speed threshold in Mbps. 25 = FCC legacy broadband definition. 100 = BEAD program standard (use this for current policy analysis). "0.2" = any service above 200 Kbps. | 25 |
| tech_filter | No | Technology filter, one value: "acfosw" = every technology (default, the recommended baseline). "f" = fiber, "c" = cable, "a" = ADSL/DSL, "o" = other (symmetric DSL, other copper, power line), "s" = satellite, "w" = fixed wireless. | acfosw |
| geography_id | No | FIPS GEOID for the geography. State: 2-digit (e.g., "06" for California). County: 5-digit (e.g., "06037" for LA County). Congressional district: 4-digit state+district (e.g., "0601"). CBSA: 5-digit code. Place: 7-digit state+place (e.g., "0644000"). Omit for nation-level queries. | |
| tribal_filter | No | Filter to tribal ("T") or non-tribal ("N") areas. Use "T" to assess Native American connectivity gaps. | all |
| geography_type | Yes | Geographic aggregation level. "nation" = US-wide totals (geography_id not needed). "cd" = congressional district. "place" = census-designated place. "cbsa" = core-based statistical area (metro area). "tribal" = tribal land area. | |
| urban_rural_filter | No | Filter to urban ("U") or rural ("R") areas only, or "all" for both combined. Rural breakdown is key for BEAD program analysis. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| breakdown | No | Per-segment breakdown by urban/rural and tribal/non-tribal. |
| geography | No | The queried geography. |
| population | No | Population counts by provider availability tier. |
| techFilter | No | Technology filter applied. |
| coveragePct | No | Percentage of population with at least one provider at the given speed. |
| dataVintage | No | Data vintage — Form 477 data as of June 2021. |
| unservedPct | No | Percentage with zero providers — FCC "unserved" definition. |
| speedDownMbps | No | Download speed threshold used in Mbps. |
| appliedFilters | No | Filters applied to this query. |
| competitivePct | No | Percentage with two or more providers. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds genuinely useful non-annotation context: the data provenance and vintage ('FCC Form 477, as of June 2021'), which tells an agent the numbers may be stale relative to current policy questions. It stops short of describing aggregation caveats or pagination, but the output schema presumably carries the return shape.
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?
Three sentences, front-loaded with the output definition, then supported geographies, then provenance and the BEAD speed tip. Every sentence carries information and nothing is padding. Slightly dense but well structured rather than bloated.
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 read-only analytical tool with an output schema and full parameter documentation, the description supplies everything else an agent needs: what the summary contains, the supported geography levels, the urban/rural and tribal segmentations, and the data vintage. Nothing material is missing for correct invocation or interpretation.
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% with 5 enum-constrained parameters, so the schema already documents every field's meaning and defaults. The description's speed-threshold advice largely duplicates the schema's own 'speed_down' description, adding little beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
The description states a specific verb and resource ('Returns a broadband coverage summary') and precisely defines the output grain: population buckets of 0/1/2/3+ providers at a speed threshold, segmented by urban/rural and tribal status. It self-identifies as 'the primary tool for digital divide and equity analysis,' which distinguishes it from siblings like fcc_find_underserved and fcc_search_availability without needing to open another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use context ('primary tool for digital divide and equity analysis') and actionable guidance for a specific policy case ('Use 100 Mbps as the speed threshold for BEAD program policy analysis'). It does not, however, explicitly name a competing sibling or state when *not* to use this tool (e.g., versus fcc_find_underserved), so routing is clear but not fully closed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_get_providerGet Provider ProfileARead-onlyIdempotentInspect
Returns a national-level coverage profile for a specific holding company (by hoconum): technologies deployed and the population covered at each download speed tier. Population figures come from the FCC provider summary table and count each person once, regardless of how many technologies the provider uses to reach them. Use fcc_search_providers to find valid hoconum values. Data is from FCC Form 477 (as of June 2021).
| Name | Required | Description | Default |
|---|---|---|---|
| hoconum | Yes | Holding company number from fcc_search_providers — digits only, e.g. "130317" for Comcast Corporation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| hoconum | No | Holding company number. |
| techCodes | No | Technology codes this provider reports nationally. Empty when the provider reports no population coverage (e.g. business-only carriers). |
| techLabels | No | Human-readable technology descriptions. |
| dataVintage | No | Data vintage — Form 477 data as of June 2021. |
| holdingCompanyName | No | Holding company name. |
| speedTierPopulation | No | National covered population by download speed tier, from the FCC all-technology rollup. Tiers with no coverage are omitted; empty when the provider reports no population coverage. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety and repeatability. The description adds valuable behavioral context: the population deduplication rule ('count each person once, regardless of technologies') and data vintage ('as of June 2021'). These are beyond what annotations provide, enhancing the agent's understanding of the data's meaning without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly packed with information. The core purpose (what it returns) is front-loaded, followed by critical behavioral notes and a parameter source hint. There is no filler or redundancy, making every sentence earn its place.
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 simple one-parameter read-only tool with an output schema, the description is complete. It explains the return content (technologies, population per tier), the data source and date, deduplication logic, and how to obtain the required hoconum. Combined with the existing output schema and annotations, nothing essential is missing for an agent to correctly invoke and interpret the tool.
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?
The input schema already provides a full description for the hoconum parameter, including an example and guidance to use fcc_search_providers. With 100% schema coverage, the baseline is 3. The description repeats the advice to use fcc_search_providers but does not add new semantic detail beyond what the schema already states, so it does not exceed the baseline.
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?
The description states a specific verb ('Returns'), a concrete resource ('national-level coverage profile for a specific holding company'), and the exact deliverables (technologies, population per speed tier). It clearly distinguishes from siblings by tying to hoconum and mentioning that fcc_search_providers is used to find valid hoconum values, making its purpose unique among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to use fcc_search_providers to find valid hoconum values, providing a clear prerequisite and routing to the correct source for inputs. It does not explicitly state when not to use this tool versus other alternatives like fcc_get_coverage_summary, but the context (provider-specific vs. summary) is implied. This is clear but lacks explicit exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_list_filing_periodsList Filing PeriodsARead-onlyIdempotentInspect
Returns available data vintages: Form 477 filing periods (hardcoded Jun 2015 – Jun 2021, always available) and BDC as-of dates from the authenticated API (Jun 2022 onward, requires credentials). When hasBdcCredentials is true, call this before fcc_list_downloads to determine valid as_of_date values. Note: there is a data gap between June 2021 (last Form 477) and June 2022 (first BDC filing period).
| Name | Required | Description | Default |
|---|---|---|---|
| include_bdc | No | When true, also fetches BDC as-of dates from the authenticated API (requires FCC_BDC_USERNAME and FCC_BDC_HASH_VALUE). When false (default), returns only hardcoded Form 477 periods. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| periods | No | Available filing periods sorted newest first. |
| bdcCount | No | Number of BDC periods returned (0 when credentials not configured or include_bdc=false). |
| dataNote | No | Note on data availability and the Form 477 vs. BDC gap. |
| form477Count | No | Number of Form 477 periods returned (always available). |
| hasBdcCredentials | No | Whether BDC API credentials are configured in this deployment. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the bar is lower; the description adds real context beyond them — the Form 477 set is hardcoded and always available, the BDC set requires credentials, and there is a known data gap between June 2021 and June 2022. It stops short of describing output shape, but the output schema covers that.
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?
Three sentences, zero filler, with the core return content front-loaded before the usage rule and the caveat. The first sentence is dense and the trailing 'Note' could arguably be folded into the credential sentence, but nothing is wasted.
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 zero-required-parameter listing tool with a full output schema and read-only annotations, everything an agent needs is present: what is returned, credential requirements, call ordering relative to fcc_list_downloads, and the known data discontinuity it will observe.
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 coverage is 100% and the single parameter's description already documents the credential env vars and the true/false behavior. The description's discussion of BDC vs hardcoded periods adds context but no syntax or format detail beyond 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ('Returns available data vintages') and immediately enumerates the two contents: hardcoded Form 477 filing periods and BDC as-of dates. An agent can tell exactly what this tool yields 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?
Explicitly routes the agent: 'When hasBdcCredentials is true, call this before fcc_list_downloads to determine valid as_of_date values' — naming the downstream tool, the ordering, and the condition. Credential prerequisites for each data source are also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_search_availabilitySearch Broadband AvailabilityARead-onlyIdempotentInspect
Queries broadband providers and advertised speeds at a census block from FCC Form 477 data (as of June 2021). Answers "which ISPs serve this location and what speeds do they offer?" — the core tool for address-level broadband lookup. Requires a 15-digit census block FIPS code; use fcc_geocode_block to convert coordinates first. Data reflects ISP-reported availability at the block level, which may overstate actual coverage for some addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| consumer | No | Filter to consumer service (true) or business service (false). Omit to return both consumer and business offerings. | |
| block_fips | Yes | 15-digit census block FIPS code on 2010 census boundaries, the vintage this Form 477 dataset is keyed by (e.g., "530330081002024"). Obtain from fcc_geocode_block using address coordinates — a 2020-vintage block ID matches no deployment row. | |
| tech_filter | No | Technology codes to filter, from the complete Form 477 taxonomy: 0=All other, 10=Asymmetric xDSL, 11=ADSL2, 12=VDSL, 20=Symmetric xDSL, 30=Other copper wireline, 40=Cable modem, 41=Cable modem DOCSIS 1/1.1/2.0, 42=Cable modem DOCSIS 3.0, 43=Cable modem DOCSIS 3.1, 50=Fiber to the end user, 60=Satellite, 70=Terrestrial fixed wireless, 90=Electric power line. Omit to return all technologies. | |
| min_speed_down | No | Minimum advertised download speed in Mbps to include in results. Omit to return all providers regardless of speed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery hint when no providers are found — suggests how to broaden the query. Absent on successful results. |
| blockFips | No | The queried census block FIPS code. |
| providers | No | ISP offerings reported for this census block. |
| dataVintage | No | Data vintage — all Form 477 data on FCC Open Data is as of June 2021. BDC bulk-file manifests for newer data require a deployment with BDC credentials. |
| appliedFilters | No | Filters applied to this query. |
| totalProviders | No | Total number of distinct holding companies offering service at this block. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: the data vintage (June 2021) and the caveat that ISP-reported block-level availability 'may overstate actual coverage for some addresses.' It does not discuss pagination or result volume, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what the tool does, then the required input and routing, then the important data caveat. Every sentence earns its place with no repetition of schema or annotation content.
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 values need no explanation, and annotations cover the safety profile. The description supplies the remaining agent-critical context: the vintage limitation, the block-level overstatement caveat, and the geocoding prerequisite.
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 four parameters, including the 15-digit pattern, the 2010-vintage constraint, and the full tech code taxonomy. The description reinforces only the block_fips requirement, adding no syntax beyond the schema — the baseline 3 is appropriate.
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 ('Queries broadband providers and advertised speeds at a census block'), names the underlying dataset and vintage, and even frames the natural-language question it answers. It clearly distinguishes itself from siblings like fcc_get_coverage_summary by scoping to address-level lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly labels itself 'the core tool for address-level broadband lookup' and states the prerequisite (15-digit census block FIPS) plus the alternative (use fcc_geocode_block to convert coordinates first). No explicit when-not guidance, but the routing context is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_search_geographiesSearch GeographiesARead-onlyIdempotentInspect
Find census places and CBSAs (metro areas) by case-insensitive literal name substring in the 2021 FCC geography lookup. Keep ambiguous matches distinct and choose the geography_type and geography_id to pass to fcc_get_coverage_summary. Include a location qualifier in name to narrow results; CBSA codes do not encode state membership. Always queries live FCC Open Data, even with the Form 477 mirror enabled, and needs no BDC credentials. Follow nextOffset until absent; no total match count is computed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nonblank literal name fragment, such as "Casper, WY". Apostrophes, percent signs and underscores are literal characters. | |
| limit | No | Maximum matches per page (1–100), default 20. | |
| offset | No | Zero-based match offset; start at 0, then use nextOffset. | |
| geography_type | No | Limit to place or cbsa; omit or leave blank to search both. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Page limit applied. |
| count | No | Number of matches on this page, not a total. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Matches shown on this page. |
| notice | No | Empty-page guidance or notice that more matches remain. |
| offset | No | Zero-based match offset applied. |
| truncated | No | More matches remain after this page. |
| nextOffset | No | Offset for the next page; absent on a final or empty page. |
| dataVintage | No | Geography lookup year. |
| geographies | No | Distinct named matches ordered by name, type, and GEOID. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent/closed-world, but the description adds substantial non-structured behavior: it always hits live FCC Open Data even when the Form 477 mirror is enabled, requires no BDC credentials, must be paged via nextOffset until absent, and computes no total match count. None of this is derivable from annotations.
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?
Front-loaded with the core action and resource, then dense behavioral and linkage notes. Every sentence carries real information (disambiguation, downstream linkage, freshness, pagination), though the block is fairly long and could be slightly tighter.
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 values need no explanation, and the description still covers the critical non-obvious facts: live-data behavior, credential requirements, the absence of a total count, and how to choose the values for the downstream coverage tool. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaning beyond it: name should carry a location qualifier (e.g., state) to disambiguate, CBSA codes do not encode state membership, and offset should be advanced via nextOffset until absent. These are genuine usage semantics layered on top of the schema.
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 (Find) and resource (census places and CBSAs / metro areas) scoped to the 2021 FCC geography lookup. An agent can immediately distinguish it from siblings like fcc_geocode_block or fcc_search_providers 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: it names the downstream tool (fcc_get_coverage_summary) that consumes the returned geography_type/geography_id and advises adding a location qualifier to name to narrow results. It lacks explicit when-not-to-use guidance or alternatives among the other search siblings, but the operational context is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fcc_search_providersSearch Broadband ProvidersARead-onlyIdempotentInspect
Searches for ISPs by holding company name, filtered by state and technology type. Returns a deduplicated list of matching providers with hoconum identifiers for follow-up calls to fcc_get_provider. Answers "which ISPs serve Washington with fiber?" and "find all Comcast entities." Geographic filtering is state-level; sub-state granularity requires cross-referencing block data. Against the live FCC API the search reads a bounded window of deployment rows to find which holding companies match, so when scanTruncated comes back true the providers are a sample of the matches rather than every one of them and no true match count is available; a narrower filter raises the share of matches the sample surfaces but cannot make it complete, and only a deployment running the local Form 477 mirror returns every match. The sample is of which companies come back — every company that does carries its complete national footprint, since statesServed and techCodes are resolved per company rather than read off the window, at the cost of one lookup per provider returned. Data is from FCC Form 477 (as of June 2021).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of distinct providers to return. | |
| state | No | 2-letter state abbreviation (e.g., "WA") to limit results to providers serving that state. Matches individual deployment filings, so every filter given must hold on one filing together — a provider is returned for state="WA" with tech_filter=["50"] only if it filed fiber in Washington, not if it filed fiber elsewhere and something else in Washington. | |
| name_search | No | Partial holding company name to search (case-insensitive). e.g., "Comcast", "T-Mobile", "Frontier". Omit to list all providers in a state. | |
| tech_filter | No | Technology codes to filter, from the complete Form 477 taxonomy: 0=All other, 10=Asymmetric xDSL, 11=ADSL2, 12=VDSL, 20=Symmetric xDSL, 30=Other copper wireline, 40=Cable modem, 41=Cable modem DOCSIS 1/1.1/2.0, 42=Cable modem DOCSIS 3.0, 43=Cable modem DOCSIS 3.1, 50=Fiber to the end user, 60=Satellite, 70=Terrestrial fixed wireless, 90=Electric power line. Omit for all technologies. Matches individual deployment filings like state does, so pairing this with name_search narrows to filings made under the matched name — a holding company that files some technologies under an acquired brand name can come back empty here while its techCodes list the technology. To ask what one company deploys, search the name alone and read techCodes off the result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. Present when capped. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of providers returned. Present when capped. |
| notice | No | Guidance about the result set — that the list was capped at the limit, that the upstream scan returned a sample rather than every match, and how to broaden the search when nothing matched. Absent when none applies. |
| providers | No | Matching providers, deduplicated by holding company. |
| truncated | No | True when results were capped at the limit and more providers may exist. Absent when not capped. |
| scanRowCap | No | Raw upstream row ceiling that bound the scan. Present only when scanTruncated is true. |
| totalCount | No | Distinct providers matching the query, before the limit. Present only when the scan read every matching row — absent when scanTruncated is true, because the true match count is then unknown. |
| totalFound | No | Providers in this response. Not the number matching the query — that is totalCount, and it is only knowable when the scan read every matching row. |
| dataVintage | No | Data vintage — Form 477 data as of June 2021. |
| scanTruncated | No | True when the upstream row scan stopped at its ceiling before reaching the end of the matching data, so the providers returned are a sample of the matches rather than the complete set. Bounds which companies came back, not what each one reports — statesServed and techCodes are resolved per company and stay complete. Absent when the scan read every matching row. |
| appliedFilters | No | Filters applied to this query. |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint and idempotentHint annotations. It discloses the bounded-window read behavior, the sampling caveat when scanTruncated is true, the absence of a true match count, and that each returned provider carries a complete national footprint due to per-company resolution. It also states the data source and vintage (Form 477 as of June 2021). This is rich behavioral disclosure that an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with many caveats. While every sentence adds value, it lacks visual structure (e.g., bullet points) and is longer than ideal for quick scanning. The core purpose is front-loaded, but the behavioral caveats are packed into a lengthy middle section. It is not as concise as it could be, though the complexity warrants some length.
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?
Given the tool's complexity (bounded window, sampling, per-company resolution) and the presence of an output schema, the description is remarkably complete. It covers the critical caveat about scanTruncated and the sample nature of results, the fact that per-company lookups inflate cost, and the data vintage. Nothing essential for correct invocation or result interpretation is missing.
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?
The input schema already covers all parameters with detailed descriptions (100% coverage). The tool description adds little parameter-specific meaning beyond what the schema provides; it reinforces that name_search is partial and case-insensitive, but that is already in the schema. The description does explain how state and tech_filter interact (must hold on one filing), which is also present in the schema descriptions. Thus, the description adds marginal value, so a baseline 3 is appropriate.
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?
The description opens with a clear statement: 'Searches for ISPs by holding company name, filtered by state and technology type. Returns a deduplicated list of matching providers with hoconum identifiers.' This names the verb, resource, and outcome. It also gives example queries ('which ISPs serve Washington with fiber?') and explicitly ties to the sibling fcc_get_provider for follow-up, distinguishing it from the other search tool fcc_search_availability by clarifying that this one searches providers (not availability).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context: it answers specific question types and states that state-level filtering is the granularity ('sub-state granularity requires cross-referencing block data'). It also implies when not to rely on it (when scanTruncated is true, results are a sample). However, it does not explicitly name alternative tools for other scenarios (e.g., fcc_search_availability for address-based searches), so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
- Changed
fcc_geocode_block2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `block_not_found`: No census block found at the given coordinates — may be over water or outside US coverage. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `geo_backend_unavailable`: The FCC Geo API reports a structured backend fault with HTTP 400. `block_not_found`: No census block found at the given coordinates — may be over water or outside US coverage. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "block_not_found" -]New value: +[ + "geo_backend_unavailable", + "block_not_found" +]
- Changed
fcc_get_coverage_summary1 field changed- changed
Output schema / properties / geography / properties / id / descriptionPrevious value: -"FIPS GEOID (e.g., \"06\")."New value: +"FIPS GEOID (e.g., \"06\"), or \"0\" for United States national coverage."
- Removed
fcc_list_downloads - Changed
fcc_search_availability1 field changed- changed
Output schema / properties / dataVintage / descriptionPrevious value: -"Data vintage — all Form 477 data on FCC Open Data is as of June 2021. For newer BDC data, use fcc_list_downloads."New value: +"Data vintage — all Form 477 data on FCC Open Data is as of June 2021. BDC bulk-file manifests for newer data require a deployment with BDC credentials."
- Added
fcc_search_geographies
3 tool updates
- Changed
fcc_compare_areas1 field changed- changed
Input schema / properties / tech_filter / descriptionPrevious value: -"Technology filter. \"acfosw\" = any wired or fixed wireless. \"f\" = fiber only. \"c\" = cable only. \"a\" = DSL. \"s\" = satellite. \"w\" = fixed wireless."New value: +"Technology filter, one value: \"acfosw\" = every technology (default). \"f\" = fiber, \"c\" = cable, \"a\" = ADSL/DSL, \"o\" = other (symmetric DSL, other copper, power line), \"s\" = satellite, \"w\" = fixed wireless."
- Changed
fcc_find_underserved1 field changed- changed
Input schema / properties / tech_filter / descriptionPrevious value: -"Technology filter. \"acfosw\" = any wired or fixed wireless. \"f\" = fiber only. \"c\" = cable only."New value: +"Technology filter, one value: \"acfosw\" = every technology (default). \"f\" = fiber, \"c\" = cable, \"a\" = ADSL/DSL, \"o\" = other (symmetric DSL, other copper, power line), \"s\" = satellite, \"w\" = fixed wireless."
- Changed
fcc_get_coverage_summary1 field changed- changed
Input schema / properties / tech_filter / descriptionPrevious value: -"Technology filter. \"acfosw\" = any wired or fixed wireless (recommended baseline). \"f\" = fiber only. \"c\" = cable only. \"a\" = ADSL/DSL only. \"s\" = satellite only. \"w\" = fixed wireless only. Mix letters for combinations, e.g., \"fc\" = fiber or cable."New value: +"Technology filter, one value: \"acfosw\" = every technology (default, the recommended baseline). \"f\" = fiber, \"c\" = cable, \"a\" = ADSL/DSL, \"o\" = other (symmetric DSL, other copper, power line), \"s\" = satellite, \"w\" = fixed wireless."
2 tool updates
- Changed
fcc_find_underserved2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_areas_found`: No areas found matching the criteria after applying filters. `unknown_state`: The state input is two uppercase letters but is not a USPS state or territory abbreviation. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `unknown_state`: The state input is two uppercase letters but is not a USPS state or territory abbreviation. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_areas_found", - "unknown_state" -]New value: +[ + "unknown_state" +]
- Changed
fcc_search_providers2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_providers_found`: No providers matched the search criteria. `live_search_timeout`: A live FCC Open Data provider search exceeded its 30-second budget, on either the bounded windowed read or one of the per-provider footprint lookups; both are shapes that answer in seconds or not at all, so a retry reaches the same result. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `live_search_timeout`: A live FCC Open Data provider search exceeded its 30-second budget, on either the bounded windowed read or one of the per-provider footprint lookups; both are shapes that answer in seconds or not at all, so a retry reaches the same result. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_providers_found", - "live_search_timeout" -]New value: +[ + "live_search_timeout" +]
9 tool updates
- Changed
fcc_compare_areas6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "geographyType", + "techFilter", + "speedDownMbps", + "sortBy", + "areas", + "totalAreas", + "dataVintage", + "appliedFilters" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_data_found`: No area table data found for any of the requested geography IDs. `invalid_all_states_combo`: compare_all_states=true used with geography_type other than \"state\". `missing_geography_ids`: No geography_ids provided and compare_all_states is false. `invalid_geography_id_shape`: A geography_ids entry has a digit count that does not match the geography_type (state=2, county=5, cd=4, cbsa=5, place=7). Other values are possible when a failure originates below the handler.", + "examples": [ + "no_data_found", + "invalid_all_states_combo", + "missing_geography_ids", + "invalid_geography_id_shape" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "geographyType", - "techFilter", - "speedDownMbps", - "sortBy", - "areas", - "totalAreas", - "dataVintage", - "appliedFilters" -]
- Changed
fcc_find_underserved6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "areas", + "geographyType", + "speedDownMbps", + "urbanRuralFilter", + "dataVintage", + "totalFound", + "appliedFilters" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_areas_found`: No areas found matching the criteria after applying filters. `unknown_state`: The state input is two uppercase letters but is not a USPS state or territory abbreviation. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_areas_found", + "unknown_state" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "areas", - "geographyType", - "speedDownMbps", - "urbanRuralFilter", - "dataVintage", - "totalFound", - "appliedFilters" -]
- Changed
fcc_geocode_block6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "blockFips", + "censusVintage", + "countyFips", + "countyName", + "stateFips", + "stateCode", + "stateName" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `block_not_found`: No census block found at the given coordinates — may be over water or outside US coverage. Other values are possible when a failure originates below the handler.", + "examples": [ + "block_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "blockFips", - "censusVintage", - "countyFips", - "countyName", - "stateFips", - "stateCode", - "stateName" -]
- Changed
fcc_get_coverage_summary6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "geography", + "techFilter", + "speedDownMbps", + "population", + "coveragePct", + "unservedPct", + "competitivePct", + "breakdown", + "dataVintage", + "appliedFilters" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `geography_not_found`: No area data found for the given geography ID and type. `invalid_geography_combo`: geography_id is omitted for a non-nation type, or geography_type is \"nation\" but geography_id is provided. `invalid_geography_id_shape`: geography_id digit count does not match the geography_type (state=2, county=5, cd=4, cbsa=5, place=7). Other values are possible when a failure originates below the handler.", + "examples": [ + "geography_not_found", + "invalid_geography_combo", + "invalid_geography_id_shape" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "geography", - "techFilter", - "speedDownMbps", - "population", - "coveragePct", - "unservedPct", - "competitivePct", - "breakdown", - "dataVintage", - "appliedFilters" -]
- Changed
fcc_get_provider6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "hoconum", + "holdingCompanyName", + "techCodes", + "techLabels", + "speedTierPopulation", + "dataVintage" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `provider_not_found`: No provider found with the given hoconum. `live_provider_timeout`: A live FCC Open Data lookup exceeded its 30-second budget; the queries are point lookups, so a retry reaches the same result. Other values are possible when a failure originates below the handler.", + "examples": [ + "provider_not_found", + "live_provider_timeout" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "hoconum", - "holdingCompanyName", - "techCodes", - "techLabels", - "speedTierPopulation", - "dataVintage" -]
- Changed
fcc_list_downloads6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "files", + "totalFiles", + "asOfDate", + "dataType", + "offset", + "pageSize", + "count", + "truncated", + "appliedFilters", + "notice" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `credentials_required`: FCC_BDC_USERNAME or FCC_BDC_HASH_VALUE environment variables are not set. `invalid_as_of_date`: The as_of_date is not a date on the calendar, falls before the first BDC filing period, or is not among the as-of dates the BDC API publishes. The first two are caught without credentials; the third needs them, since only the credentialed endpoint knows the published set. Other values are possible when a failure originates below the handler.", + "examples": [ + "credentials_required", + "invalid_as_of_date" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "files", - "totalFiles", - "asOfDate", - "dataType", - "offset", - "pageSize", - "count", - "truncated", - "appliedFilters", - "notice" -]
- Changed
fcc_list_filing_periods6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "periods", + "form477Count", + "bdcCount", + "hasBdcCredentials", + "dataNote" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "periods", - "form477Count", - "bdcCount", - "hasBdcCredentials", - "dataNote" -]
- Changed
fcc_search_availability6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "blockFips", + "providers", + "totalProviders", + "dataVintage", + "appliedFilters" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `block_not_found`: No providers in the FCC dataset for this census block. Other values are possible when a failure originates below the handler.", + "examples": [ + "block_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "blockFips", - "providers", - "totalProviders", - "dataVintage", - "appliedFilters" -]
- Changed
fcc_search_providers6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "providers", + "totalFound", + "dataVintage", + "appliedFilters" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_providers_found`: No providers matched the search criteria. `live_search_timeout`: A live FCC Open Data provider search exceeded its 30-second budget, on either the bounded windowed read or one of the per-provider footprint lookups; both are shapes that answer in seconds or not at all, so a retry reaches the same result. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_providers_found", + "live_search_timeout" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "providers", - "totalFound", - "dataVintage", - "appliedFilters" -]
4 tool updates
- Changed
fcc_geocode_block3 fields changed- changed
Output schema / properties / blockFips / descriptionPrevious value: -"15-digit census block FIPS code (e.g., \"530330081021016\"). Pass this to fcc_search_availability to look up broadband providers."New value: +"15-digit census block FIPS code on 2010 census boundaries (e.g., \"530330081002024\"). Pass this to fcc_search_availability to look up broadband providers." - added
Output schema / properties / censusVintageAdded value: +{ + "description": "Decennial census whose block boundaries blockFips belongs to. Always \"2010\" — the vintage the Form 477 deployment dataset behind fcc_search_availability is keyed by.", + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "blockFips", - "countyFips", - "countyName", - "stateFips", - "stateCode", - "stateName" -]New value: +[ + "blockFips", + "censusVintage", + "countyFips", + "countyName", + "stateFips", + "stateCode", + "stateName" +]
- Changed
fcc_list_downloads11 fields changed- added
Input schema / properties / limitAdded value: +{ + "default": 50, + "description": "Maximum number of files to return on one page.", + "maximum": 200, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-based index of the first file to return, within the files matching the filters. Start at 0 and follow the nextOffset each response carries.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / countAdded value: +{ + "description": "Files actually returned on this page. Zero both when nothing matched and when the offset is past the end; the notice says which.", + "type": "number" +} - changed
Output schema / properties / files / descriptionPrevious value: -"Downloadable BDC files matching the filters."New value: +"Downloadable BDC files on this page, in the order the BDC API lists them." - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset to pass back for the next page. Omitted on the last page and when the offset is past the end.", + "type": "number" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no files are found — suggests how to broaden the search. Absent on successful results."New value: +"Where this page sits in the matching set and how to continue — or, when the page is empty, whether nothing matched the filters or the offset ran past the end." - added
Output schema / properties / offsetAdded value: +{ + "description": "Zero-based index of the first file on this page.", + "type": "number" +} - added
Output schema / properties / pageSizeAdded value: +{ + "description": "Maximum files one page returns — the limit that was applied.", + "type": "number" +} - changed
Output schema / properties / totalFiles / descriptionPrevious value: -"Total number of files returned after filtering."New value: +"Files matching the filters across every page, not just this one. Compare against the count enrichment field to see how much of the set this page holds." - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when this page holds fewer files than totalFiles, so more pages exist.", + "type": "boolean" +} - changed
Output schema / requiredPrevious value: -[ - "files", - "totalFiles", - "asOfDate", - "dataType", - "appliedFilters" -]New value: +[ + "files", + "totalFiles", + "asOfDate", + "dataType", + "offset", + "pageSize", + "count", + "truncated", + "appliedFilters", + "notice" +]
- Changed
fcc_search_availability4 fields changed- changed
Input schema / properties / block_fips / descriptionPrevious value: -"15-digit census block FIPS code (e.g., \"530330081021016\"). Obtain from fcc_geocode_block using address coordinates."New value: +"15-digit census block FIPS code on 2010 census boundaries, the vintage this Form 477 dataset is keyed by (e.g., \"530330081002024\"). Obtain from fcc_geocode_block using address coordinates — a 2020-vintage block ID matches no deployment row." - changed
Input schema / properties / tech_filter / descriptionPrevious value: -"Technology codes to filter. 50=Fiber to premises, 40–43=Cable modem, 10–12=DSL variants, 60=Satellite, 70=Fixed wireless. Omit to return all technologies."New value: +"Technology codes to filter, from the complete Form 477 taxonomy: 0=All other, 10=Asymmetric xDSL, 11=ADSL2, 12=VDSL, 20=Symmetric xDSL, 30=Other copper wireline, 40=Cable modem, 41=Cable modem DOCSIS 1/1.1/2.0, 42=Cable modem DOCSIS 3.0, 43=Cable modem DOCSIS 3.1, 50=Fiber to the end user, 60=Satellite, 70=Terrestrial fixed wireless, 90=Electric power line. Omit to return all technologies." - changed
Input schema / properties / tech_filter / items / enumPrevious value: -[ - "10", - "11", - "12", - "40", - "41", - "42", - "43", - "50", - "60", - "70" -]New value: +[ + "0", + "10", + "11", + "12", + "20", + "30", + "40", + "41", + "42", + "43", + "50", + "60", + "70", + "90" +] - changed
Output schema / properties / providers / items / properties / techCode / descriptionPrevious value: -"Technology code (e.g., \"50\" = fiber, \"40\" = cable, \"60\" = satellite)."New value: +"FCC Form 477 technology code (e.g., \"50\" = fiber, \"43\" = cable DOCSIS 3.1, \"60\" = satellite)."
- Changed
fcc_search_providers2 fields changed- changed
Input schema / properties / tech_filter / descriptionPrevious value: -"Technology codes to filter. 50=Fiber, 40–43=Cable, 10–12=DSL, 60=Satellite, 70=Fixed wireless. Omit for all technologies. Matches individual deployment filings like state does, so pairing this with name_search narrows to filings made under the matched name — a holding company that files some technologies under an acquired brand name can come back empty here while its techCodes list the technology. To ask what one company deploys, search the name alone and read techCodes off the result."New value: +"Technology codes to filter, from the complete Form 477 taxonomy: 0=All other, 10=Asymmetric xDSL, 11=ADSL2, 12=VDSL, 20=Symmetric xDSL, 30=Other copper wireline, 40=Cable modem, 41=Cable modem DOCSIS 1/1.1/2.0, 42=Cable modem DOCSIS 3.0, 43=Cable modem DOCSIS 3.1, 50=Fiber to the end user, 60=Satellite, 70=Terrestrial fixed wireless, 90=Electric power line. Omit for all technologies. Matches individual deployment filings like state does, so pairing this with name_search narrows to filings made under the matched name — a holding company that files some technologies under an acquired brand name can come back empty here while its techCodes list the technology. To ask what one company deploys, search the name alone and read techCodes off the result." - changed
Input schema / properties / tech_filter / items / enumPrevious value: -[ - "10", - "11", - "12", - "40", - "41", - "42", - "43", - "50", - "60", - "70" -]New value: +[ + "0", + "10", + "11", + "12", + "20", + "30", + "40", + "41", + "42", + "43", + "50", + "60", + "70", + "90" +]
2 tool updates
- Changed
fcc_get_provider6 fields changed- changed
Input schema / properties / hoconum / descriptionPrevious value: -"Holding company number from fcc_search_providers (e.g., \"130152\" for Comcast). Required identifier for the provider."New value: +"Holding company number from fcc_search_providers — digits only, e.g. \"130317\" for Comcast Corporation." - added
Input schema / properties / hoconum / patternAdded value: +"^\\d+$" - removed
Output schema / properties / speedTierLocationsRemoved value: -{ - "description": "Download speed tier location counts (national totals).", - "items": { - "additionalProperties": false, - "description": "A speed tier with location count.", - "properties": { - "locationCount": { - "description": "Number of locations with service at this tier.", - "type": "number" - }, - "tier": { - "description": "Speed tier label (e.g., \"25 Mbps\").", - "type": "string" - } - }, - "required": [ - "tier", - "locationCount" - ], - "type": "object" - }, - "type": "array" -} - added
Output schema / properties / speedTierPopulationAdded value: +{ + "description": "National covered population by download speed tier, from the FCC all-technology rollup. Tiers with no coverage are omitted; empty when the provider reports no population coverage.", + "items": { + "additionalProperties": false, + "description": "A speed tier with its covered population.", + "properties": { + "population": { + "description": "People covered at or above this download speed, counted once each.", + "type": "number" + }, + "tier": { + "description": "Download speed threshold (e.g., \"25 Mbps\").", + "type": "string" + } + }, + "required": [ + "tier", + "population" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / techCodes / descriptionPrevious value: -"Technology codes this provider deploys nationally."New value: +"Technology codes this provider reports nationally. Empty when the provider reports no population coverage (e.g. business-only carriers)." - changed
Output schema / requiredPrevious value: -[ - "hoconum", - "holdingCompanyName", - "techCodes", - "techLabels", - "speedTierLocations", - "dataVintage" -]New value: +[ + "hoconum", + "holdingCompanyName", + "techCodes", + "techLabels", + "speedTierPopulation", + "dataVintage" +]
- Changed
fcc_search_providers10 fields changed- changed
Input schema / properties / state / descriptionPrevious value: -"2-letter state abbreviation (e.g., \"WA\") to limit results to providers serving that state."New value: +"2-letter state abbreviation (e.g., \"WA\") to limit results to providers serving that state. Matches individual deployment filings, so every filter given must hold on one filing together — a provider is returned for state=\"WA\" with tech_filter=[\"50\"] only if it filed fiber in Washington, not if it filed fiber elsewhere and something else in Washington." - changed
Input schema / properties / tech_filter / descriptionPrevious value: -"Technology codes to filter. 50=Fiber, 40–43=Cable, 10–12=DSL, 60=Satellite, 70=Fixed wireless. Omit for all technologies."New value: +"Technology codes to filter. 50=Fiber, 40–43=Cable, 10–12=DSL, 60=Satellite, 70=Fixed wireless. Omit for all technologies. Matches individual deployment filings like state does, so pairing this with name_search narrows to filings made under the matched name — a holding company that files some technologies under an acquired brand name can come back empty here while its techCodes list the technology. To ask what one company deploys, search the name alone and read techCodes off the result." - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no providers are found — suggests how to broaden the search. Absent on successful results."New value: +"Guidance about the result set — that the list was capped at the limit, that the upstream scan returned a sample rather than every match, and how to broaden the search when nothing matched. Absent when none applies." - changed
Output schema / properties / providers / items / properties / holdingCompanyName / descriptionPrevious value: -"Holding company name."New value: +"Holding company name as filed on the deployment rows this search matched. One holding company number can carry more than one name in Form 477 — an acquired brand still filing under the parent number — and this is the name the matched rows carry, not necessarily every name filed under the number." - changed
Output schema / properties / providers / items / properties / statesServed / descriptionPrevious value: -"State abbreviations where this provider has reported filings."New value: +"Every state, district, and territory this holding company filed deployments in nationally — its complete footprint, resolved per company. Not narrowed by the state filter, and complete even when the provider list is a sample." - changed
Output schema / properties / providers / items / properties / techCodes / descriptionPrevious value: -"Technology codes reported by this provider."New value: +"Every technology code this holding company deployed nationally — its complete set, resolved per company. Not narrowed by tech_filter, and complete even when the provider list is a sample. Drawn from block-level deployment filings, so it can exceed the technologies fcc_get_provider reports, which counts only those with reported covered population." - added
Output schema / properties / scanRowCapAdded value: +{ + "description": "Raw upstream row ceiling that bound the scan. Present only when scanTruncated is true.", + "type": "number" +} - added
Output schema / properties / scanTruncatedAdded value: +{ + "description": "True when the upstream row scan stopped at its ceiling before reaching the end of the matching data, so the providers returned are a sample of the matches rather than the complete set. Bounds which companies came back, not what each one reports — statesServed and techCodes are resolved per company and stay complete. Absent when the scan read every matching row.", + "type": "boolean" +} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Distinct providers matching the query, before the limit. Present only when the scan read every matching row — absent when scanTruncated is true, because the true match count is then unknown.", + "type": "number" +} - changed
Output schema / properties / totalFound / descriptionPrevious value: -"Number of distinct providers returned."New value: +"Providers in this response. Not the number matching the query — that is totalCount, and it is only knowable when the scan read every matching row."
2 tool updates
- Changed
fcc_compare_areas1 field changed- changed
Input schema / properties / sort_by / descriptionPrevious value: -"\"unserved_pct\" = share of population with no broadband (default). \"unserved_pop\" = raw headcount for BEAD funding. \"coverage_pct\" = share with any coverage. \"competitive_pct\" = share with 2+ providers."New value: +"\"unserved_pct\" = share of population with no broadband (default). \"unserved_pop\" = raw headcount for BEAD funding. \"coverage_pct\" = share with any coverage. \"competitive_pct\" = share with 2+ providers. Every option ranks worst-first, so rank 1 is the highest unserved share or headcount, or the lowest coverage or competitive share."
- Changed
fcc_find_underserved6 fields changed- changed
Input schema / properties / min_unserved_pop / defaultPrevious value: -0New value: +1 - changed
Input schema / properties / min_unserved_pop / descriptionPrevious value: -"Minimum population with no coverage to include. Use to filter out very small areas (e.g., 500 filters areas with fewer than 500 unserved residents)."New value: +"Minimum population with no coverage to include. Defaults to 1, which keeps fully covered areas out of a ranking of underserved ones. Set to 0 to rank every area regardless of unserved population, or higher to drop small gaps (e.g., 500 keeps only areas with at least 500 unserved residents)." - changed
Input schema / properties / state / descriptionPrevious value: -"2-letter state code (e.g., \"WY\", \"MS\") to limit scope. Omit for nationwide search — returns top areas only."New value: +"2-letter USPS state or territory code (e.g., \"WY\", \"MS\", \"PR\") to limit scope. An unrecognized code is rejected, not ignored. Omit for nationwide search — returns top areas only." - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no areas are found — suggests how to broaden the filters. Absent on successful results."New value: +"Guidance about the result set — how to broaden the filters when nothing matched, and how to narrow the query when the upstream scan hit its row ceiling. Absent when neither applies." - added
Output schema / properties / scanRowCapAdded value: +{ + "description": "Raw upstream row ceiling that bound the scan. Present only when scanTruncated is true.", + "type": "number" +} - added
Output schema / properties / scanTruncatedAdded value: +{ + "description": "True when the upstream row scan stopped at its ceiling before reaching the end of the matching data, so totalFound and the ranking cover only the portion that was scanned. Absent when the scan read every matching row.", + "type": "boolean" +}
3 tool updates
- Changed
fcc_compare_areas1 field changed- added
Output schema / properties / areas / items / properties / nameAdded value: +{ + "description": "Human-readable geography name if resolved (e.g., \"Pontotoc County, MS\").", + "type": "string" +}
- Changed
fcc_find_underserved1 field changed- added
Output schema / properties / areas / items / properties / nameAdded value: +{ + "description": "Human-readable geography name if resolved (e.g., \"Pontotoc County, MS\").", + "type": "string" +}
- Changed
fcc_get_coverage_summary1 field changed- changed
Input schema / properties / geography_id / descriptionPrevious value: -"FIPS GEOID for the geography. State: 2-digit (e.g., \"06\" for California). County: 5-digit (e.g., \"06037\" for LA County). Congressional district: 4-digit state+district (e.g., \"0601\"). CBSA: 5-digit code. Omit for nation-level queries."New value: +"FIPS GEOID for the geography. State: 2-digit (e.g., \"06\" for California). County: 5-digit (e.g., \"06037\" for LA County). Congressional district: 4-digit state+district (e.g., \"0601\"). CBSA: 5-digit code. Place: 7-digit state+place (e.g., \"0644000\"). Omit for nation-level queries."
2 tool updates
- Changed
fcc_find_underserved3 fields changed- added
Output schema / properties / capAdded value: +{ + "description": "The limit that was applied. Present when truncated.", + "type": "number" +} - added
Output schema / properties / shownAdded value: +{ + "description": "Number of areas returned after applying the limit. Present when truncated.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when more areas matched than the limit returned. Absent when not truncated.", + "type": "boolean" +}
- Changed
fcc_search_providers3 fields changed- added
Output schema / properties / capAdded value: +{ + "description": "The limit that was applied. Present when capped.", + "type": "number" +} - added
Output schema / properties / shownAdded value: +{ + "description": "Number of providers returned. Present when capped.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when results were capped at the limit and more providers may exist. Absent when not capped.", + "type": "boolean" +}
6 tool updates
- Changed
fcc_compare_areas2 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "Filters and parameters applied to this comparison.", + "properties": { + "areasCompared": { + "description": "Total number of geographies compared.", + "type": "number" + }, + "geographyType": { + "description": "Geographic level compared.", + "type": "string" + }, + "sortBy": { + "description": "Field used for ranking.", + "type": "string" + }, + "speedDownMbps": { + "description": "Download speed threshold in Mbps.", + "type": "number" + }, + "techFilter": { + "description": "Technology filter applied.", + "type": "string" + } + }, + "required": [ + "geographyType", + "techFilter", + "speedDownMbps", + "sortBy", + "areasCompared" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "geographyType", - "techFilter", - "speedDownMbps", - "sortBy", - "areas", - "totalAreas", - "dataVintage" -]New value: +[ + "geographyType", + "techFilter", + "speedDownMbps", + "sortBy", + "areas", + "totalAreas", + "dataVintage", + "appliedFilters" +]
- Changed
fcc_find_underserved3 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "Filters applied to this query.", + "properties": { + "geographyType": { + "description": "Geographic granularity queried.", + "type": "string" + }, + "minUnservedPop": { + "description": "Minimum unserved population filter applied.", + "type": "number" + }, + "speedDownMbps": { + "description": "Download speed threshold in Mbps.", + "type": "number" + }, + "state": { + "description": "State abbreviation filter applied. Absent for nationwide searches.", + "type": "string" + }, + "techFilter": { + "description": "Technology filter applied.", + "type": "string" + }, + "urbanRuralFilter": { + "description": "Urban/rural filter applied.", + "type": "string" + } + }, + "required": [ + "geographyType", + "speedDownMbps", + "techFilter", + "urbanRuralFilter", + "minUnservedPop" + ], + "type": "object" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no areas are found."New value: +"Recovery hint when no areas are found — suggests how to broaden the filters. Absent on successful results." - changed
Output schema / requiredPrevious value: -[ - "areas", - "totalFound", - "geographyType", - "speedDownMbps", - "urbanRuralFilter", - "dataVintage" -]New value: +[ + "areas", + "geographyType", + "speedDownMbps", + "urbanRuralFilter", + "dataVintage", + "totalFound", + "appliedFilters" +]
- Changed
fcc_get_coverage_summary2 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "Filters applied to this query.", + "properties": { + "geographyId": { + "description": "FIPS GEOID queried. Absent for nation-level.", + "type": "string" + }, + "geographyType": { + "description": "Geographic aggregation level queried.", + "type": "string" + }, + "speedDownMbps": { + "description": "Download speed threshold in Mbps.", + "type": "number" + }, + "techFilter": { + "description": "Technology filter applied.", + "type": "string" + }, + "tribalFilter": { + "description": "Tribal/non-tribal filter applied.", + "type": "string" + }, + "urbanRuralFilter": { + "description": "Urban/rural filter applied.", + "type": "string" + } + }, + "required": [ + "geographyType", + "techFilter", + "speedDownMbps", + "urbanRuralFilter", + "tribalFilter" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "geography", - "techFilter", - "speedDownMbps", - "population", - "coveragePct", - "unservedPct", - "competitivePct", - "breakdown", - "dataVintage" -]New value: +[ + "geography", + "techFilter", + "speedDownMbps", + "population", + "coveragePct", + "unservedPct", + "competitivePct", + "breakdown", + "dataVintage", + "appliedFilters" +]
- Changed
fcc_list_downloads3 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "Filters applied to this query.", + "properties": { + "asOfDate": { + "description": "As-of date queried.", + "type": "string" + }, + "category": { + "description": "Category filter applied. Absent when not filtered.", + "type": "string" + }, + "dataType": { + "description": "Data type queried.", + "type": "string" + }, + "providerName": { + "description": "Provider name filter applied. Absent when not filtered.", + "type": "string" + }, + "state": { + "description": "State filter applied. Absent for all-state results.", + "type": "string" + }, + "technologyType": { + "description": "Technology type filter applied. Absent when not filtered.", + "type": "string" + } + }, + "required": [ + "asOfDate", + "dataType" + ], + "type": "object" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when no files are found — suggests how to broaden the search. Absent on successful results.", + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "files", - "totalFiles", - "asOfDate", - "dataType" -]New value: +[ + "files", + "totalFiles", + "asOfDate", + "dataType", + "appliedFilters" +]
- Changed
fcc_search_availability3 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "Filters applied to this query.", + "properties": { + "consumerFilter": { + "description": "Consumer/business filter applied. true = consumer only, false = business only. Absent when both were returned.", + "type": "boolean" + }, + "minSpeedDown": { + "description": "Minimum advertised download speed filter in Mbps. Absent when no speed filter was used.", + "type": "number" + }, + "techFilter": { + "description": "Technology codes applied as a filter. Absent when no tech filter was used.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when no providers are found — suggests how to broaden the query. Absent on successful results.", + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "blockFips", - "providers", - "totalProviders", - "dataVintage" -]New value: +[ + "blockFips", + "providers", + "totalProviders", + "dataVintage", + "appliedFilters" +]
- Changed
fcc_search_providers3 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "Filters applied to this query.", + "properties": { + "nameSearch": { + "description": "Name fragment searched. Absent when no name search was used.", + "type": "string" + }, + "state": { + "description": "State filter applied. Absent for nationwide searches.", + "type": "string" + }, + "techFilter": { + "description": "Technology code filter applied. Absent when no tech filter was used.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty — suggests how to broaden the search."New value: +"Recovery hint when no providers are found — suggests how to broaden the search. Absent on successful results." - changed
Output schema / requiredPrevious value: -[ - "providers", - "totalFound", - "dataVintage" -]New value: +[ + "providers", + "totalFound", + "dataVintage", + "appliedFilters" +]
9 tool updates
- First observed
fcc_compare_areas - First observed
fcc_find_underserved - First observed
fcc_geocode_block - First observed
fcc_get_coverage_summary - First observed
fcc_get_provider - First observed
fcc_list_downloads - First observed
fcc_list_filing_periods - First observed
fcc_search_availability - First observed
fcc_search_providers
Related MCP Connectors
Broadband availability, providers, speeds, and BEAD classification from the FCC
US telecom availability and intelligence by address, with FCC provenance. Fiber-first.
FCC Open Data (opendata.fcc.gov) Socrata MCP.
FCC public geo/census APIs (geo.fcc.gov) MCP.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides access to official U.S. Census Bureau data, including decennial census, American Community Survey, economic census, population estimates, and housing characteristics, across geographic levels from nation to block group. Enables natural-language queries and direct tool calls for demographic and housing analysis.12 npmMIT
- FlicenseNot gradedqualityAmaintenanceEnables AI assistants to discover official datasets, resolve geographic identifiers, and retrieve demographic and statistical data from official U.S. census sources.-
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to discover, query, and analyze official Census Bureau datasets and statistics, including geography lookup and aggregate data retrieval.MIT
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.