Federal Register

open_comment_periods

Read-only

Find source-reported open comment periods, soonest indexed deadline first.

Covers proposed rules, notices, AND final/interim rules that accept
comments (dozens of RULE-type documents have open periods at any time).
Queries for comment close date >= today, scans up to 500 matching
documents oldest-published first (where the soonest deadlines live),
sorts by close date, and returns the first `limit`.

Source scope: total_open is the API's matching metadata count;
scanned is how many this call examined. When total_open exceeds
scanned, narrow with agencies/term for complete indexed coverage. A very
recently published document with an unusually short comment window
can fall outside the scan in that oversubscribed case.

complete means the matching indexed records were scanned, not that every
currently open opportunity or controlling deadline was verified. The API's
comments_close_on metadata can disagree with DATES after an extension or
reopening. Even a zero result needs docket/subject search_documents and
get_document DATES/linked publication checks before ruling out comments.

Default: searches all agencies. Pass agency slugs to narrow scope,
e.g. ['defense-acquisition-regulations-system'] for DFARS or
['general-services-administration'] for GSA and GSAR.

Parameters:
- far_council: True for open FAR proposed rules and FAR information
  collections (documents filed jointly by DoD, GSA and NASA; there is no
  single FAR agency slug and the OFPP tag only appears from about
  mid-2025). Cannot be combined with agencies.
- limit: max documents returned after sorting (default 50, max 100).
  Unfiltered dumps across all agencies can approach 200KB; several
  broad agencies together (e.g. DoD + GSA) can pass 100KB, so lower
  limit for those.

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": "open_comment_periods"
  }
}

Input Schema

Name	Required	Description	Default
`term`	No
`limit`	No
`agencies`	No
`far_council`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses the 500-document scan cap, the oldest-published-first scan order, the total_open vs scanned distinction, the oversubscription blind spot for short comment windows, and the caveat that metadata can disagree with DATES after extensions. This is unusually rich behavioral context for a read tool.

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

Conciseness4/5

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

Front-loaded with purpose and scope, then caveats, then parameter notes; every sentence carries real information. It is on the verbose side for a 4-param tool, but there is little true redundancy.

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

Completeness5/5

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

An output schema exists, and the description still clarifies its key fields (total_open, scanned, complete) so an agent can interpret results and know when coverage is incomplete. Given the readOnly tool's complexity and the oversubscription edge case, nothing essential is missing.

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

Parameters5/5

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

Schema coverage is 0%, but the description compensates for all four params: far_council (joint DoD/GSA/NASA filings, no single slug, mid-2025 tag caveat), limit (default 50, max 100, payload-size rationale), agencies (concrete slug examples for DFARS and GSA/GSAR), and term (as a narrowing filter).

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?

Opens with a specific verb+resource ('Find source-reported open comment periods') and a sort/scope qualifier ('soonest indexed deadline first'). It explicitly distinguishes itself from document-search siblings by covering RULE-type documents with open periods, and later names search_documents and get_document as complements.

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?

States when to narrow with agencies/term, that far_council cannot be combined with agencies, and that even a zero result must be cross-checked with search_documents and get_document DATES/linked publication. Alternatives and exclusions are spelled out rather than inferred.

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

All Federal Register 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.