US Federal Regulations (CFR)

Search the Federal Register and rulemakings

search_federal_register

Read-onlyIdempotent

Use this when the user asks what federal agencies have published, proposed or announced, including a rulemaking, for example "what has the FDA proposed on food dyes?", "find final rules on noncompete agreements" or "which executive orders mention AI this year?". Pass the words to find and optionally the document type (rule, proposed_rule, notice, presidential_document) and a publication date range. Returns each document's title, type, agencies, publication date, abstract, effective date, comment deadline, the CFR parts it changes and a link. This is general information, not legal advice. Do not use it to read the current text of a regulation (use get_cfr_section), or for state law, bills, court decisions or non-US rules.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Most documents to return. Default 5.
`order`	No	Default relevance.
`query`	Yes	Words to find in Federal Register documents, for example 'noncompete' or 'PFAS drinking water'.
`publishedTo`	No	Latest publication date, as YYYY-MM-DD.
`documentType`	No	rule is a final rule, proposed_rule a proposal open to comment, notice an agency notice, presidential_document an executive order or proclamation.
`publishedFrom`	No	Earliest publication date, as YYYY-MM-DD.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes
`notice`	Yes
`source`	Yes
`documents`	Yes
`totalMatches`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the result content (title, agencies, effective date, comment deadline, CFR parts, link) and the 'general information, not legal advice' disclaimer. It does not discuss rate limits or result-count defaults, but those are minor against the annotation coverage.

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 the use case and examples before parameters and disclaimers, with no filler. It runs slightly long by restating return fields that the output schema already covers, which is the only minor inefficiency.

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 read-only search tool with a full output schema and complete annotations, everything an agent needs is present: intent examples, parameter guidance, exclusions, and the non-legal-advice caveat. Nothing material 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 all six parameters are already documented in the schema, including documentType enum meanings and the YYYY-MM-DD date format. The description restates the same parameter concepts (words, document type, date range) without adding syntax or constraints beyond the schema, so the baseline of 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?

The description opens with a specific verb+resource+scope ('what federal agencies have published, proposed or announced, including a rulemaking') and backs it with three concrete query examples. It clearly distinguishes itself from get_cfr_section, which it names explicitly.

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?

It gives explicit when-to-use triggers (user asking what agencies have published/proposed) and explicit exclusions: do not use to read current regulation text (route to get_cfr_section), nor for state law, bills, court decisions or non-US rules. Alternatives and boundaries are unambiguous.

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

All US Federal Regulations (CFR) tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.