fcc-broadband-mcp-server

List Filing Periods

fcc_list_filing_periods

Read-onlyIdempotent

Returns available data vintages: Form 477 filing periods (hardcoded Jun 2015 – Jun 2021, always available) and BDC as-of dates from the authenticated API (Jun 2022 onward, requires credentials). When hasBdcCredentials is true, call this before fcc_list_downloads to determine valid as_of_date values. Note: there is a data gap between June 2021 (last Form 477) and June 2022 (first BDC filing period).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fcc_list_filing_periods"
  }
}

Input 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

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.

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

First observedMay 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the bar is lower; the description adds real context beyond them — the Form 477 set is hardcoded and always available, the BDC set requires credentials, and there is a known data gap between June 2021 and June 2022. It stops short of describing output shape, but the output schema covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, zero filler, with the core return content front-loaded before the usage rule and the caveat. The first sentence is dense and the trailing 'Note' could arguably be folded into the credential sentence, but nothing is wasted.

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

Completeness5/5

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

For a zero-required-parameter listing tool with a full output schema and read-only annotations, everything an agent needs is present: what is returned, credential requirements, call ordering relative to fcc_list_downloads, and the known data discontinuity it will observe.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter's description already documents the credential env vars and the true/false behavior. The description's discussion of BDC vs hardcoded periods adds context but no syntax or format detail beyond the schema, so the baseline 3 applies.

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

Purpose5/5

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

States a concrete verb and resource ('Returns available data vintages') and immediately enumerates the two contents: hardcoded Form 477 filing periods and BDC as-of dates. An agent can tell exactly what this tool yields without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'When hasBdcCredentials is true, call this before fcc_list_downloads to determine valid as_of_date values' — naming the downstream tool, the ordering, and the condition. Credential prerequisites for each data source are also spelled out.

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

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.