Regulations.gov

search_documents

Read-only

Search Regulations.gov documents (proposed rules, final rules, notices).

Filter values are CASE-SENSITIVE. Use exact casing:
- document_type: 'Proposed Rule', 'Rule', 'Notice', 'Supporting & Related Material', 'Other'
- Lowercase values silently return 0 results (no error)

Key parameters:
- search_term: full-text match, including attachment text. Results
  follow sort (newest first by default), not relevance, so an unquoted
  multi-word term puts loosely matching recent documents first; quote
  a phrase ('"Pay Equity and Transparency"') to match it exactly.
- agency_id: FAR, DARS, GSA, SBA, OFPP, DOD, NASA, VA, etc.
  Comma-separate for multiple agencies ('FAR,GSA'). Empty string is rejected.
- docket_id: e.g., 'FAR-2023-0008' for a specific FAR case
- within_comment_period: True to find documents currently accepting
  comments. False is NOT supported by the API (it 400s); omit the
  parameter instead to search regardless of comment status.
- posted_date_ge/le: YYYY-MM-DD format (calendar-checked)
- comment_end_date_ge/le: YYYY-MM-DD format

Response meta.facets gives the top counts by document type, agency,
and comment period status; a facet the query filtered on is left out,
because the API counts it site-wide. meta.totalElements is the full
match count.

Comment deadlines: attributes.commentDeadlineEastern is the date reported
by Regulations.gov metadata in Eastern time (e.g. 'Oct 22, 2026 11:59 PM ET'). The raw
commentEndDateUtc is the provider UTC instant. commentDeadlineVerification
links to the notice/docket: read DATES, eligibility, and later extensions
before treating this metadata date as controlling. If unavailable, the
controlling deadline cannot be established.

Page size: 5-100. page_number: 1-40. The API serves 40 pages; when more
records match, page_limit_note (and truncated=true on page 40) says how
many are out of reach. Split the query into posted_date_ge/le windows.

sort: '-postedDate' (newest first, default), 'postedDate', '-commentEndDate',
'lastModifiedDate', 'title', 'documentId'. Comma-separate for
multi-field sorts ('lastModifiedDate,documentId').

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

Input Schema

Name	Required	Default
`sort`	No	-postedDate
`agency_id`	No
`docket_id`	No
`page_size`	No
`page_number`	No
`search_term`	No
`document_type`	No
`posted_date_ge`	No
`posted_date_le`	No
`comment_end_date_ge`	No
`comment_end_date_le`	No
`within_comment_period`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it discloses important behavioral quirks: case-sensitive filters silently return zero results when lowercase, within_comment_period=false causes an API 400, facets omit filtered dimensions, and pagination is capped at 40 pages. It also explains the comment-deadline metadata caveat, which materially affects interpretation of results.

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 appropriately sized for a 12-parameter search tool with several API quirks. It is front-loaded with purpose and critical filtering constraints, and every section adds operational value without repetition.

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 parameter count, annotation profile, and presence of an output schema, the description is complete enough to call the tool correctly. It covers filter semantics, pagination limits, sort behavior, and response metadata without needing to re-explain return values owned by the output schema.

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?

With schema description coverage at 0%, the description carries the full burden and does so thoroughly: it documents every parameter with examples, casing rules, date formats, pagination limits, sort syntax, and unsupported values. This is far more than the schema provides.

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 gives a specific verb and resource: search Regulations.gov documents, explicitly scoped to proposed rules, final rules, and notices. That scope distinguishes it from siblings such as search_dockets and search_comments without needing to name them.

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 and how to search documents, including exact-case filtering, quoting phrases for exact matches, and omitting within_comment_period instead of passing false. It does not explicitly route the agent away from sibling tools such as search_comments or get_document_detail, so it falls short of full 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.

All Regulations.gov 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.