fcc-broadband-mcp-server

Get Provider Profile

fcc_get_provider

Read-onlyIdempotent

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hoconum": "<hoconum>"
    },
    "name": "fcc_get_provider"
  }
}

Input Schema

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

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`hoconum`	No	Holding company number.
`techCodes`	No	Technology codes this provider reports nationally. Empty when the provider reports no population coverage (e.g. business-only carriers).
`techLabels`	No	Human-readable technology descriptions.
`dataVintage`	No	Data vintage — Form 477 data as of June 2021.
`holdingCompanyName`	No	Holding company name.
`speedTierPopulation`	No	National covered population by download speed tier, from the FCC all-technology rollup. Tiers with no coverage are omitted; empty when the provider reports no population coverage.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedAug 25, 2026

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

Changed6 schema fields changedAug 13, 2026

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

First observedMay 29, 2026

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.

All fcc-broadband-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.