fcc-broadband-mcp-server

Name: fcc-broadband-mcp-server
Author: cyanheads

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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 07:33
Transport: Streamable HTTP
URL
Repository: cyanheads/fcc-broadband-mcp-server
GitHub Stars: 1
Server Listing: fcc-broadband-mcp-server

Available Tools

9 tools

fcc_compare_areasCompare Broadband Coverage Across AreasA

Read-onlyIdempotent

Inspect

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).

ParametersJSON Schema

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. "acfosw" = any wired or fixed wireless. "f" = fiber only. "c" = cable only. "a" = DSL. "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

ParametersJSON 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 declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds valuable behavioral context beyond that: the ranking behavior (sorted by unserved/underserved population), the data vintage (FCC Form 477 as of June 2021), and the limit of 50 geography IDs with the compare_all_states override. These are useful and non-contradictory.

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 front-loaded with the core purpose in the first sentence, then adds a use case, parameter notes, and data source in a logical order. Every sentence earns its place, with no filler or repetition. It is concise and well-structured.

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 that an output schema exists (as indicated by context signals) and all parameters have rich schema descriptions, the description covers all necessary operational details: what it does, how to use it (with limits), and the data source. Nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description repeats some parameter guidance (e.g., 'up to 50 geography IDs' and 'compare_all_states=true for all 50 states + DC'), but these are also present in the schema descriptions. It does not add meaning beyond what the schema already provides, so no bonus is warranted.

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

Purpose4/5

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

The description clearly states the tool 'compares broadband coverage metrics across multiple geographies of the same type' and returns a ranked table, which is a specific verb-resource pair. It also gives a concrete example question. However, it does not explicitly distinguish itself from sibling tools like fcc_get_coverage_summary or fcc_find_underserved, so it stops short of a 5.

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 clear context for when to use this tool: to answer 'which counties in this state have the worst broadband access?' and for BEAD funding prioritization. It does not mention when not to use it or name alternative tools, so it meets the bar for 'clear context, no exclusions' rather than explicit when/when-not guidance.

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

fcc_find_underservedFind Underserved AreasA

Read-onlyIdempotent

Inspect

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).

ParametersJSON Schema

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. "acfosw" = any wired or fixed wireless. "f" = fiber only. "c" = cable only.	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

ParametersJSON 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.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. The description adds valuable behavioral context beyond annotations: it discloses the data source (FCC Form 477 as of June 2021) and the default rural focus, which clarifies the scope of results. It also implies the ranking order. While it does not mention pagination or output structure, the presence of an output schema covers that. The description enriches the agent's understanding without contradicting annotations.

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 four sentences, tightly packed with actionable information. The purpose is front-loaded, followed by scope options, default behavior, and data provenance. Every sentence earns its place with no filler or redundancy. The structure leads with the core function, making it easy for an agent to quickly determine applicability.

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

Completeness4/5

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

For a tool with seven parameters (all optional), an output schema, and clear annotations, the description is quite complete. It covers the tool's role, scope control (state or nationwide), defaults (rural, speed threshold), and data source. It does not explicitly describe the result format or pagination, but the output schema presumably covers that. The missing piece is a mention of how results are ranked, though that is stated in the first sentence. Overall, it provides sufficient context for correct invocation.

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 baseline is 3. The description reinforces some defaults (e.g., rural areas) but does not add meaning beyond what the schema already provides. For example, the BEAD standard for speed_down is already documented in the schema's parameter description. The description does not clarify parameter relationships or provide new syntax. It adds marginal value, but insufficient to raise the score above 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 opens with a specific verb+resource: 'Finds geographic areas with limited or no broadband coverage at a given speed threshold, ranked by unserved population.' It explicitly identifies itself as 'The core tool for BEAD program analysis and broadband equity research,' which immediately distinguishes it from sibling tools like fcc_compare_areas or fcc_get_coverage_summary. The purpose is unambiguous and operational.

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 clear context on when to use: it is framed as the core tool for BEAD program analysis and equity research. It also states scope behavior: 'Accepts a state abbreviation to narrow scope or runs nationwide' and notes the rural default. However, it does not explicitly mention alternative tools for specific conditions, nor state when NOT to use this tool. This is slightly weaker than naming a sibling, but the guidance is sufficient for an agent to select it correctly in most scenarios.

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 BlockA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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

ParametersJSON 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.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat that. It adds behavioral context beyond annotations: the resolution against 2010 census boundaries and the use of the FCC public Geo API with no auth. This gives an agent insight into external dependencies and compatibility. It doesn't cover error handling or edge cases, but given annotation coverage that is acceptable.

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?

The description is somewhat long but every sentence earns its place: the primary function, the downstream dependency, the vintage caveat, and the auth note are all relevant. It is front-loaded with the core action and then layers context. A minor tightening could combine the vintage and dependency sentences, but it remains clear and well-structured.

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 presence of an output schema (so return values are self-documented), the description covers everything an agent needs: purpose, prerequisite relationship, coordinate scope, vintage alignment, and authentication. It is complete for a tool of this complexity and leaves no ambiguity about how to call it or what to expect in terms of use-case fit.

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 schema description coverage is 100%, with each parameter already including examples and geographic constraints (continental US, Alaska, etc.). The description adds no additional parameter-specific semantics beyond what the schema provides; it only mentions the required prerequisite context. 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 precise statement of the conversion (lat/long to 15-digit census block FIPS plus county/state identifiers) and immediately differentiates from siblings by noting it is the required prerequisite for fcc_search_availability because the broadband dataset is keyed by census block. This is a specific, unambiguous purpose that an agent can act on without inspecting 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?

The description explicitly states the usage context: it is the prerequisite for fcc_search_availability, and it explains why the returned blockFips is directly usable (2010 vintage matches the Form 477 dataset) while also warning against using 2020-vintage blocks. It also mentions no authentication is required, rounding out the when-to-use guidance. No alternatives are needed because it names the dependent tool.

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 SummaryA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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. "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.	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

ParametersJSON 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.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, establishing the operation is safe and deterministic. The description adds valuable non-annotation context: the data source and vintage ('Data is from FCC Form 477 (as of June 2021)') and the explicit purpose (digital divide analysis). It does not contradict annotations. No side effects or edge cases are discussed, but given the annotations, this is sufficient.

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 five sentences, each purposeful: the core function, its primary use case, supported geographies, data provenance, and a policy-specific recommendation. It is front-loaded with the most important information (what it returns) and contains no filler or redundant wording. Every sentence earns 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?

Given the tool's complexity (6 params, 5 enums, output schema present), the description covers the essentials: what it does, what data it uses, when to use it, and which geography levels it supports. The output schema exists, so the return format need not be described. An agent can safely select and invoke this tool without further information.

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 has 100% description coverage, with each parameter already explained in detail (e.g., speed_down enum meanings, tech filter codes, and geography ID formats). The description's parameter-related advice—'Use 100 Mbps as the speed threshold for BEAD program policy analysis'—duplicates the schema's own recommendation ('100 = BEAD program standard (use this for current policy analysis)'). It adds no meaning beyond the schema, so the baseline of 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 precise action and resource: 'Returns a broadband coverage summary for a geography' and specifies exactly what the summary contains (population with zero/one/two/three-plus providers, urban/rural, tribal/non-tribal). It declares itself 'The primary tool for digital divide and equity analysis,' which clearly positions it relative to siblings. No other sibling performs this exact aggregation, so distinguishing is unambiguous.

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 strong contextual guidance: 'primary tool for digital divide and equity analysis' and recommends the 100 Mbps threshold for BEAD policy analysis. It also lists the supported geography levels. However, it never explicitly says when NOT to use this tool or names alternatives (e.g., fcc_compare_areas for head-to-head area comparisons). The absence of explicit exclusion points to a score of 4 rather than 5.

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 ProfileA

Read-onlyIdempotent

Inspect

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).

ParametersJSON Schema

Name	Required	Description	Default
`hoconum`	Yes	Holding company number from fcc_search_providers — digits only, e.g. "130317" for Comcast Corporation.

Output Schema

ParametersJSON 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_downloadsList BDC DownloadsA

Read-onlyIdempotent

Inspect

Lists downloadable BDC data files for a specific as-of date — fixed availability by state and provider, mobile coverage, and challenge data — with file metadata (provider, state, technology, record count). Download URLs are included for each file. Requires FCC BDC API credentials (FCC_BDC_USERNAME and FCC_BDC_HASH_VALUE). Use fcc_list_filing_periods first to determine valid as_of_date values (BDC dates start June 2022); a date that is not on the calendar, or that falls before the first BDC period, is rejected without credentials, while a well-formed date the BDC API does not publish is rejected once credentials let the published set be read. One as-of date can carry thousands of per-provider files, so results come back a page at a time: totalFiles counts every file matching the filters, the response reports the offset and the count on this page, and it carries a nextOffset to pass back for the following page until the last one, which omits it.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of files to return on one page.
`state`	No	Filter to one state's files (2-letter abbreviation, e.g., "WA").
`offset`	No	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.
`category`	No	File category. "State" = per-state coverage files. "Provider" = per-provider files. "Summary" = aggregate coverage tables.
`data_type`	No	"availability" = ISP-reported coverage files (by state and provider). "challenge" = consumer and government dispute records.	availability
`as_of_date`	Yes	BDC as-of date in YYYY-MM-DD format (e.g., "2024-06-30"). Get valid dates from fcc_list_filing_periods with include_bdc=true.
`provider_name`	No	Partial provider holding company name to filter results (case-insensitive).
`technology_type`	No	Filter to a specific technology type of coverage data.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No	Files actually returned on this page. Zero both when nothing matched and when the offset is past the end; the notice says which.
`error`	No	Present when the call failed. Absent on success.
`files`	No	Downloadable BDC files on this page, in the order the BDC API lists them.
`notice`	No	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.
`offset`	No	Zero-based index of the first file on this page.
`asOfDate`	No	The queried as-of date.
`dataType`	No	Data type queried (availability or challenge).
`pageSize`	No	Maximum files one page returns — the limit that was applied.
`truncated`	No	True when this page holds fewer files than totalFiles, so more pages exist.
`nextOffset`	No	Offset to pass back for the next page. Omitted on the last page and when the offset is past the end.
`totalFiles`	No	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.
`appliedFilters`	No	Filters applied to this query.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already mark the operation as read-only and idempotent. The description adds meaningful behavior beyond that: the need for FCC_BDC_USERNAME/FCC_BDC_HASH_VALUE credentials, the specific error behavior for invalid dates (before credentials vs. after reading the published set), and the pagination structure (totalFiles, offset, count, nextOffset). No contradictions with annotations.

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 long but every sentence earns its place: purpose first, then credentials, then date validation, then pagination. It is front-loaded with the core action and avoids redundancy with the schema. The structure logically guides the agent from setup to execution.

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 an output schema exists (so return values are documented elsewhere) and annotations cover safety, the description covers all essential operational context: valid date sources, credential requirements, pagination mechanics, and file categories. Nothing an agent needs to call this tool correctly 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 description coverage is 100%, so the schema already documents each parameter. The description adds semantic value by explaining the pagination semantics (nextOffset, totalFiles) which clarifies how to use offset and limit, and by linking as_of_date to the filing periods tool. It does not repeat schema text but enriches context around the parameters.

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 specific verb and resource ('Lists downloadable BDC data files for a specific as-of date') and enumerates the types of files covered (availability, mobile coverage, challenge data) plus the metadata returned. It differentiates itself from siblings by mentioning a prerequisite (fcc_list_filing_periods) and focusing on file downloads, which is distinct from coverage summaries or searches.

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 explicitly instructs to call fcc_list_filing_periods first to obtain valid as_of_date values, and explains the credential requirement. It details pagination handling (offset, count, nextOffset) so the agent knows how to iterate. It does not name alternative tools to avoid, but the workflow guidance is clear and actionable.

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 PeriodsA

Read-onlyIdempotent

Inspect

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). 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).

ParametersJSON Schema

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

ParametersJSON 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 readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral details beyond those: Form 477 periods are hardcoded and always available, while BDC periods come from an authenticated API requiring credentials. It also notes a data gap between the two sources. These add context that enriches what the annotations already imply, without contradicting them.

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 a single sentence that packs all essential information: what is returned, the time ranges, authentication needs, and a reference to the sibling tool. It is front-loaded with the core purpose ('Returns available data vintages') and each clause earns its place. There is no redundant wording or filler.

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?

The tool has an output schema, so return format is already documented. The description covers the main use case (determining as_of_date values for fcc_list_downloads), the data sources, and the gap. It doesn't mention error handling or performance, but these are not critical given the constraints. It is sufficiently complete for an agent to call the tool correctly, though it could include a note about the impact of include_bdc on performance or authentication failures.

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 description's mention of 'requires credentials' overlaps directly with the schema's parameter description for include_bdc, which already names FCC_BDC_USERNAME and FCC_BDC_HASH_VALUE. The description adds no new meaning about the parameter beyond the schema, though it does contextualize the data gap. This meets the baseline for good schema coverage but doesn't exceed it.

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 precise resource ('available data vintages'), and enumerates the two types (Form 477 filing periods and BDC as-of dates). It explicitly names the sibling tool fcc_list_downloads, establishing clear differentiation and scope. There is no ambiguity about what this tool provides.

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?

It gives an explicit directive: 'Call this before fcc_list_downloads to determine valid as_of_date values.' This tells the agent exactly when to use the tool and why. It also notes the authentication requirement for BDC periods, which informs the caller about prerequisites. The mention of the data gap adds context about timing, though it doesn't list explicit exclusions for when not to use it, the guidance is strong enough for a 5.

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 AvailabilityA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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

ParametersJSON 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. For newer BDC data, use fcc_list_downloads.
`appliedFilters`	No	Filters applied to this query.
`totalProviders`	No	Total number of distinct holding companies offering service at this block.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only and idempotent behavior, so the description adds value by disclosing the data source vintage (June 2021), the requirement for 2010 census boundaries, and the caveat that ISP-reported availability may overstate actual coverage. This goes beyond the structured annotations with meaningful context.

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 a tight two-sentence summary that front-loads the core purpose, then adds the essential prerequisite and a caveat. Every sentence carries functional value with no filler.

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?

Given the tool's moderate complexity and the presence of a full output schema and thorough parameter descriptions, the overview covers purpose, usage, and data quality. It could mention potential empty results or error handling, but these are minor gaps; it's nearly complete for an agent to call correctly.

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?

With 100% schema coverage, the baseline is 3. The description adds a practical hint on obtaining the block_fips parameter (via fcc_geocode_block) and warns about vintage mismatches, which is useful beyond the schema. It doesn't elaborate on other parameters, so a 4 is warranted for the extra guidance.

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 ('queries') and resource ('broadband providers and advertised speeds at a census block'), and distinguishes itself as 'the core tool for address-level broadband lookup.' It clearly differentiates from siblings like fcc_compare_areas or fcc_get_provider by focusing on the block-level query scope.

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 explicitly instructs to 'use fcc_geocode_block to convert coordinates first,' providing a clear prerequisite. It also clarifies the data vintage and warns about potential overstatement. However, it does not explicitly list when not to use this tool versus alternatives like fcc_search_providers, so it lacks a full 'when-not' statement.

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 ProvidersA

Read-onlyIdempotent

Inspect

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).

ParametersJSON Schema

Name	Required	Description
`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

ParametersJSON 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.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's added value lies in explaining the sampling behavior: it reads a bounded window, returns a sample when scanTruncated is true, and that per-company fields like statesServed and techCodes are complete despite the sample. It also states data recency (June 2021). This goes well beyond annotations, providing critical caveats for correct interpretation.

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?

About five sentences, each earning its place: core purpose, examples, sampling behavior, per-company resolution detail, and data source. The structure is front-loaded with the primary function, then caveats and context. No filler or redundancy, despite the complexity.

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 output schema exists (though not shown here), the description still identifies key return fields (deduplicated list, hoconum, statesServed, techCodes, scanTruncated) and explains the sample-versus-complete behavior. It also covers data source and recency. For a read-only search tool with comprehensive schema descriptions, nothing critical for correct invocation 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?

Schema description coverage is 100%, so the schema already documents each parameter, including the per-filing matching logic for state and tech_filter. The description references parameters in examples but does not add meaning beyond what the schema states. The baseline of 3 is appropriate because the schema carries the burden, and the description adds marginal interpretive value (e.g., sample behavior relative to filters).

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: 'Searches for ISPs by holding company name, filtered by state and technology type.' It also gives concrete example questions ('which ISPs serve Washington with fiber?') and clarifies it returns identifiers for follow-up calls to fcc_get_provider, distinguishing it from sibling lookup tools. This exceeds a minimal purpose statement.

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 tells when to use this tool (to answer ISP queries) and directs follow-up to fcc_get_provider via 'hoconum identifiers.' It also warns about sub-state granularity requiring block data, guiding users away for that purpose. However, it does not explicitly mention when to prefer siblings like fcc_search_availability, so it lacks a complete when-not-alternatives matrix.

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. Dates show when Glama detected each change.

9 tool updatesAug 25, 2026

Changedfcc_compare_areas6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "geographyType",
+      "techFilter",
+      "speedDownMbps",
+      "sortBy",
+      "areas",
+      "totalAreas",
+      "dataVintage",
+      "appliedFilters"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "geographyType",
-  "techFilter",
-  "speedDownMbps",
-  "sortBy",
-  "areas",
-  "totalAreas",
-  "dataVintage",
-  "appliedFilters"
-]

Changedfcc_find_underserved6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "areas",
+      "geographyType",
+      "speedDownMbps",
+      "urbanRuralFilter",
+      "dataVintage",
+      "totalFound",
+      "appliedFilters"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "areas",
-  "geographyType",
-  "speedDownMbps",
-  "urbanRuralFilter",
-  "dataVintage",
-  "totalFound",
-  "appliedFilters"
-]

Changedfcc_geocode_block6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "blockFips",
+      "censusVintage",
+      "countyFips",
+      "countyName",
+      "stateFips",
+      "stateCode",
+      "stateName"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "blockFips",
-  "censusVintage",
-  "countyFips",
-  "countyName",
-  "stateFips",
-  "stateCode",
-  "stateName"
-]

Changedfcc_get_coverage_summary6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "geography",
+      "techFilter",
+      "speedDownMbps",
+      "population",
+      "coveragePct",
+      "unservedPct",
+      "competitivePct",
+      "breakdown",
+      "dataVintage",
+      "appliedFilters"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "geography",
-  "techFilter",
-  "speedDownMbps",
-  "population",
-  "coveragePct",
-  "unservedPct",
-  "competitivePct",
-  "breakdown",
-  "dataVintage",
-  "appliedFilters"
-]

Changedfcc_get_provider6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "hoconum",
+      "holdingCompanyName",
+      "techCodes",
+      "techLabels",
+      "speedTierPopulation",
+      "dataVintage"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "hoconum",
-  "holdingCompanyName",
-  "techCodes",
-  "techLabels",
-  "speedTierPopulation",
-  "dataVintage"
-]

Changedfcc_list_downloads6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "files",
+      "totalFiles",
+      "asOfDate",
+      "dataType",
+      "offset",
+      "pageSize",
+      "count",
+      "truncated",
+      "appliedFilters",
+      "notice"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "files",
-  "totalFiles",
-  "asOfDate",
-  "dataType",
-  "offset",
-  "pageSize",
-  "count",
-  "truncated",
-  "appliedFilters",
-  "notice"
-]

Changedfcc_list_filing_periods6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "periods",
+      "form477Count",
+      "bdcCount",
+      "hasBdcCredentials",
+      "dataNote"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "periods",
-  "form477Count",
-  "bdcCount",
-  "hasBdcCredentials",
-  "dataNote"
-]

Changedfcc_search_availability6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "blockFips",
+      "providers",
+      "totalProviders",
+      "dataVintage",
+      "appliedFilters"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "blockFips",
-  "providers",
-  "totalProviders",
-  "dataVintage",
-  "appliedFilters"
-]

Changedfcc_search_providers6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "providers",
+      "totalFound",
+      "dataVintage",
+      "appliedFilters"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required

Removed value: -[
-  "providers",
-  "totalFound",
-  "dataVintage",
-  "appliedFilters"
-]

4 tool updatesAug 13, 2026

Changedfcc_geocode_block3 fields changed

changedOutput schema / properties / blockFips / description

Previous 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."

addedOutput schema / properties / censusVintage

Added 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"
+}

changedOutput schema / required

Previous value: -[
-  "blockFips",
-  "countyFips",
-  "countyName",
-  "stateFips",
-  "stateCode",
-  "stateName"
-]New value: +[
+  "blockFips",
+  "censusVintage",
+  "countyFips",
+  "countyName",
+  "stateFips",
+  "stateCode",
+  "stateName"
+]

Changedfcc_list_downloads11 fields changed

addedInput schema / properties / limit

Added value: +{
+  "default": 50,
+  "description": "Maximum number of files to return on one page.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added 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"
+}

addedOutput schema / properties / count

Added 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"
+}

changedOutput schema / properties / files / description

Previous value: -"Downloadable BDC files matching the filters."New value: +"Downloadable BDC files on this page, in the order the BDC API lists them."

addedOutput schema / properties / nextOffset

Added 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"
+}

changedOutput schema / properties / notice / description

Previous 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."

addedOutput schema / properties / offset

Added value: +{
+  "description": "Zero-based index of the first file on this page.",
+  "type": "number"
+}

addedOutput schema / properties / pageSize

Added value: +{
+  "description": "Maximum files one page returns — the limit that was applied.",
+  "type": "number"
+}

changedOutput schema / properties / totalFiles / description

Previous 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."

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when this page holds fewer files than totalFiles, so more pages exist.",
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "files",
-  "totalFiles",
-  "asOfDate",
-  "dataType",
-  "appliedFilters"
-]New value: +[
+  "files",
+  "totalFiles",
+  "asOfDate",
+  "dataType",
+  "offset",
+  "pageSize",
+  "count",
+  "truncated",
+  "appliedFilters",
+  "notice"
+]

Changedfcc_search_availability4 fields changed

changedInput schema / properties / block_fips / description

Previous 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."

changedInput schema / properties / tech_filter / description

Previous 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."

changedInput schema / properties / tech_filter / items / enum

Previous 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"
+]

changedOutput schema / properties / providers / items / properties / techCode / description

Previous 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)."

Changedfcc_search_providers2 fields changed

changedInput schema / properties / tech_filter / description

Previous 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."

changedInput schema / properties / tech_filter / items / enum

Previous 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 updatesAug 13, 2026

Changedfcc_get_provider6 fields changed

changedInput schema / properties / hoconum / description

Previous 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."

addedInput schema / properties / hoconum / pattern
```
Added value: +"^\\d+$"
```

removedOutput schema / properties / speedTierLocations

Removed 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"
-}

addedOutput schema / properties / speedTierPopulation

Added 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"
+}

changedOutput schema / properties / techCodes / description

Previous 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)."

changedOutput schema / required

Previous value: -[
-  "hoconum",
-  "holdingCompanyName",
-  "techCodes",
-  "techLabels",
-  "speedTierLocations",
-  "dataVintage"
-]New value: +[
+  "hoconum",
+  "holdingCompanyName",
+  "techCodes",
+  "techLabels",
+  "speedTierPopulation",
+  "dataVintage"
+]

Changedfcc_search_providers10 fields changed

changedInput schema / properties / state / description

Previous 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."

changedInput schema / properties / tech_filter / description

Previous 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."

changedOutput schema / properties / notice / description

Previous 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."

changedOutput schema / properties / providers / items / properties / holdingCompanyName / description

Previous 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."

changedOutput schema / properties / providers / items / properties / statesServed / description

Previous 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."

changedOutput schema / properties / providers / items / properties / techCodes / description

Previous 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."

addedOutput schema / properties / scanRowCap

Added value: +{
+  "description": "Raw upstream row ceiling that bound the scan. Present only when scanTruncated is true.",
+  "type": "number"
+}

addedOutput schema / properties / scanTruncated

Added 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"
+}

addedOutput schema / properties / totalCount

Added 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"
+}

changedOutput schema / properties / totalFound / description

Previous 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 updatesAug 13, 2026

Changedfcc_compare_areas1 field changed

changedInput schema / properties / sort_by / description

Previous 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."

Changedfcc_find_underserved6 fields changed

changedInput schema / properties / min_unserved_pop / default
```
Previous value: -0New value: +1
```

changedInput schema / properties / min_unserved_pop / description

Previous 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)."

changedInput schema / properties / state / description

Previous 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."

changedOutput schema / properties / notice / description

Previous 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."

addedOutput schema / properties / scanRowCap

Added value: +{
+  "description": "Raw upstream row ceiling that bound the scan. Present only when scanTruncated is true.",
+  "type": "number"
+}

addedOutput schema / properties / scanTruncated

Added 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 updatesJul 2, 2026

Changedfcc_compare_areas1 field changed

addedOutput schema / properties / areas / items / properties / name

Added value: +{
+  "description": "Human-readable geography name if resolved (e.g., \"Pontotoc County, MS\").",
+  "type": "string"
+}

Changedfcc_find_underserved1 field changed

addedOutput schema / properties / areas / items / properties / name

Added value: +{
+  "description": "Human-readable geography name if resolved (e.g., \"Pontotoc County, MS\").",
+  "type": "string"
+}

Changedfcc_get_coverage_summary1 field changed

changedInput schema / properties / geography_id / description

Previous 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 updatesJun 12, 2026

Changedfcc_find_underserved3 fields changed

addedOutput schema / properties / cap

Added value: +{
+  "description": "The limit that was applied. Present when truncated.",
+  "type": "number"
+}

addedOutput schema / properties / shown

Added value: +{
+  "description": "Number of areas returned after applying the limit. Present when truncated.",
+  "type": "number"
+}

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when more areas matched than the limit returned. Absent when not truncated.",
+  "type": "boolean"
+}

Changedfcc_search_providers3 fields changed

addedOutput schema / properties / cap

Added value: +{
+  "description": "The limit that was applied. Present when capped.",
+  "type": "number"
+}

addedOutput schema / properties / shown

Added value: +{
+  "description": "Number of providers returned. Present when capped.",
+  "type": "number"
+}

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when results were capped at the limit and more providers may exist. Absent when not capped.",
+  "type": "boolean"
+}

6 tool updatesMay 30, 2026

Changedfcc_compare_areas2 fields changed

addedOutput schema / properties / appliedFilters

Added 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"
+}

changedOutput schema / required

Previous value: -[
-  "geographyType",
-  "techFilter",
-  "speedDownMbps",
-  "sortBy",
-  "areas",
-  "totalAreas",
-  "dataVintage"
-]New value: +[
+  "geographyType",
+  "techFilter",
+  "speedDownMbps",
+  "sortBy",
+  "areas",
+  "totalAreas",
+  "dataVintage",
+  "appliedFilters"
+]

Changedfcc_find_underserved3 fields changed

addedOutput schema / properties / appliedFilters

Added 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"
+}

changedOutput schema / properties / notice / description

Previous 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."

changedOutput schema / required

Previous value: -[
-  "areas",
-  "totalFound",
-  "geographyType",
-  "speedDownMbps",
-  "urbanRuralFilter",
-  "dataVintage"
-]New value: +[
+  "areas",
+  "geographyType",
+  "speedDownMbps",
+  "urbanRuralFilter",
+  "dataVintage",
+  "totalFound",
+  "appliedFilters"
+]

Changedfcc_get_coverage_summary2 fields changed

addedOutput schema / properties / appliedFilters

Added 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"
+}

changedOutput schema / required

Previous value: -[
-  "geography",
-  "techFilter",
-  "speedDownMbps",
-  "population",
-  "coveragePct",
-  "unservedPct",
-  "competitivePct",
-  "breakdown",
-  "dataVintage"
-]New value: +[
+  "geography",
+  "techFilter",
+  "speedDownMbps",
+  "population",
+  "coveragePct",
+  "unservedPct",
+  "competitivePct",
+  "breakdown",
+  "dataVintage",
+  "appliedFilters"
+]

Changedfcc_list_downloads3 fields changed

addedOutput schema / properties / appliedFilters

Added 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"
+}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Recovery hint when no files are found — suggests how to broaden the search. Absent on successful results.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "files",
-  "totalFiles",
-  "asOfDate",
-  "dataType"
-]New value: +[
+  "files",
+  "totalFiles",
+  "asOfDate",
+  "dataType",
+  "appliedFilters"
+]

Changedfcc_search_availability3 fields changed

addedOutput schema / properties / appliedFilters

Added 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"
+}

addedOutput schema / properties / notice

Added value: +{
+  "description": "Recovery hint when no providers are found — suggests how to broaden the query. Absent on successful results.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "blockFips",
-  "providers",
-  "totalProviders",
-  "dataVintage"
-]New value: +[
+  "blockFips",
+  "providers",
+  "totalProviders",
+  "dataVintage",
+  "appliedFilters"
+]

Changedfcc_search_providers3 fields changed

addedOutput schema / properties / appliedFilters

Added 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"
+}

changedOutput schema / properties / notice / description

Previous 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."

changedOutput schema / required

Previous value: -[
-  "providers",
-  "totalFound",
-  "dataVintage"
-]New value: +[
+  "providers",
+  "totalFound",
+  "dataVintage",
+  "appliedFilters"
+]

9 tool updatesMay 29, 2026
- First observedfcc_compare_areas
- First observedfcc_find_underserved
- First observedfcc_geocode_block
- First observedfcc_get_coverage_summary
- First observedfcc_get_provider
- First observedfcc_list_downloads
- First observedfcc_list_filing_periods
- First observedfcc_search_availability
- First observedfcc_search_providers

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

FCC Broadband Map A
com.olyport
Broadband availability, providers, speeds, and BEAD classification from the FCC
Government Data Open Data
42
telecom-truth A
io.github.fiberfinder
US telecom availability and intelligence by address, with FCC provenance. Fiber-first.
Location Services Government Data Open Data
51
Data Fcc A
io.github.pipeworx-io
FCC Open Data (opendata.fcc.gov) Socrata MCP.
Government Data Open Data
342
Fcc A
io.github.pipeworx-io
FCC public geo/census APIs (geo.fcc.gov) MCP.
Location Services Government Data
342

Related MCP Servers

mcp-data-fcc
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying and exploring FCC Open Data datasets via Socrata SoQL, including dataset search, metadata retrieval, and data querying.
Updated 11 days ago (2026-08-26 16:54 UTC)
16
MIT
census
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides 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.
Updated 11 days ago (2026-08-26 16:47 UTC)
12
MIT
tigerweb
Location Services Government Data Open Data
shawndrake2
F
license
Not graded
quality
D
maintenance
Enables access to US Census Bureau TIGERweb geographic boundary data, returning GeoJSON for states, counties, census tracts, places, ZCTAs, and congressional districts.
Updated 7 months ago (2026-01-29 21:12 UTC)
1
-
Census API MCP Server
Government Data Open Data Search
shawndrake2
F
license
Not graded
quality
D
maintenance
Enables access to U.S. Census Bureau data including demographics, population, income, and housing statistics. Users can query specific variables, search datasets, and retrieve geographic FIPS codes across various surveys like the American Community Survey and Decennial Census.
Updated 7 months ago (2026-01-28 01:20 UTC)
1
-

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: geocoding, availability lookup, provider search, provider details, coverage summaries, area comparisons, underserved analysis, data version listing, and file downloads. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow the `fcc_` prefix plus a clear verb_noun pattern (e.g., `fcc_geocode_block`, `fcc_search_availability`, `fcc_list_downloads`). Naming is consistent snake_case with a predictable structure.

Tool Count5/5

9 tools is well-scoped for a domain-specific data server. Each tool earns its place, covering the core workflow of geocoding, availability, provider lookup, coverage analysis, and data file access without redundancy.

Completeness4/5

The tool set covers the essential lifecycle: geocode → search availability, search providers → get provider, coverage summaries, comparisons, and data file discovery. Minor gaps exist (e.g., no direct address search, but geocoding prerequisites handle it), but the surface is comprehensive for FCC broadband analysis.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources