Skip to main content
Glama

Search Broadband Providers

fcc_search_providers
Read-onlyIdempotent

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of distinct providers to return.
stateNo2-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_searchNoPartial holding company name to search (case-insensitive). e.g., "Comcast", "T-Mobile", "Frontier". Omit to list all providers in a state.
tech_filterNoTechnology 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

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit that was applied. Present when capped.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of providers returned. Present when capped.
noticeNoGuidance 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.
providersNoMatching providers, deduplicated by holding company.
truncatedNoTrue when results were capped at the limit and more providers may exist. Absent when not capped.
scanRowCapNoRaw upstream row ceiling that bound the scan. Present only when scanTruncated is true.
totalCountNoDistinct 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.
totalFoundNoProviders in this response. Not the number matching the query — that is totalCount, and it is only knowable when the scan read every matching row.
dataVintageNoData vintage — Form 477 data as of June 2021.
scanTruncatedNoTrue 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.
appliedFiltersNoFilters 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.

Try in Browser

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.