Federal Register

Search Documents

search_documents

Read-onlyIdempotent

Search the US Federal Register by topic / keyword for proposed rules, final rules, notices, and presidential documents. Use this whenever the question mentions a SUBJECT ("EV tax credits", "AI export controls", "PFAS regulations", "clean energy", "ozempic labeling", etc.) — recent_rules takes no topic filter and would return random unrelated rules. For a STRUCTURED count/list ("how many executive orders in 2026", "list 2026 proclamations"), pass type:"presidential_document" plus presidential_document_type rather than relying on free-text query — a free-text search for "executive order" also matches documents that merely MENTION one, over- or under-counting the real set. To find or confirm ONE specific executive order by its number, pass executive_order_number instead — it scopes and filters for you, no type/presidential_document_type needed. Returns title, abstract, agency, publication date, links, and for presidential documents also executive_order_number, signing_date, and citation. The response always echoes filters_applied: a genuine zero still says exactly what was searched, so it is never a bare empty result. Examples: search_documents({query: "EV tax credit", type: "rule"}), search_documents({type: "presidential_document", presidential_document_type: "executive_order", since: "2026-01-01"}), search_documents({executive_order_number: "14435"}), search_documents({query: "Strait of Hormuz", since: "365d"}). Pass since to constrain to recent documents — without it the relevance ranker can return decade-old docs for sparse-term queries.

Input Schema

Name	Required	Description
`type`	No	Document type filter: "rule", "proposed_rule", "notice", "presidential_document" — mapped internally to the Federal Register API's own codes (RULE/PRORULE/NOTICE/PRESDOCU); an unrecognized value is refused rather than silently matching nothing.
`query`	No	Search keywords (e.g., "clean energy tax credit"). Optional if type/agency/since/presidential_document_type/executive_order_number already scope the search — forcing a free-text term onto a structured count/list question (e.g. "executive order") distorts it, since the term index matches MENTIONS of a thing as well as the thing itself.
`since`	No	Publication date floor. Accepts ISO date ("2025-01-01") or shorthand ("30d", "12m", "365d", "1y"). Recommended for any topical search to avoid stale results — the relevance ranker can surface 2004-2008 documents for queries with sparse hits.
`agency`	No	Agency slug filter (e.g., "environmental-protection-agency", "securities-and-exchange-commission")
`executive_order_number`	No	Look up ONE executive order by its number, e.g. "14435" or "EO 14435" — automatically scopes to type:"presidential_document" + presidential_document_type:"executive_order" and filters the result to an exact number match, so neither needs to be passed separately. Conflicts with an explicit type/presidential_document_type that names something other than presidential documents / executive orders.
`presidential_document_type`	No	Only with type:"presidential_document" — narrows to one sub-type: "executive_order", "proclamation", "memorandum", "determination", "notice", or "other". This is the STRUCTURED way to count/list executive orders etc.; prefer it over a free-text query for "how many X" questions.

Output Schema

Name	Required	Description
`query`	Yes	The search query string
`total`	Yes	Total count of matching documents
`returned`	Yes	Number of documents returned in this response
`documents`	Yes	Array of formatted Federal Register documents

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 3, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "query": "clean energy tax credit"
-  },
-  {
-    "agency": "environmental-protection-agency",
-    "query": "artificial intelligence",
-    "type": "proposed_rule"
-  }
-]New value: +[
+  {
+    "query": "clean energy tax credit"
+  },
+  {
+    "agency": "environmental-protection-agency",
+    "query": "artificial intelligence",
+    "type": "proposed_rule"
+  },
+  {
+    "executive_order_number": "14435"
+  }
+]

addedInput schema / properties / executive_order_number

Added value: +{
+  "description": "Look up ONE executive order by its number, e.g. \"14435\" or \"EO 14435\" — automatically scopes to type:\"presidential_document\" + presidential_document_type:\"executive_order\" and filters the result to an exact number match, so neither needs to be passed separately. Conflicts with an explicit type/presidential_document_type that names something other than presidential documents / executive orders.",
+  "type": "string"
+}

addedInput schema / properties / presidential_document_type

Added value: +{
+  "description": "Only with type:\"presidential_document\" — narrows to one sub-type: \"executive_order\", \"proclamation\", \"memorandum\", \"determination\", \"notice\", or \"other\". This is the STRUCTURED way to count/list executive orders etc.; prefer it over a free-text query for \"how many X\" questions.",
+  "type": "string"
+}

changedInput schema / properties / query / description

Previous value: -"Search keywords (e.g., \"clean energy tax credit\")"New value: +"Search keywords (e.g., \"clean energy tax credit\"). Optional if type/agency/since/presidential_document_type/executive_order_number already scope the search — forcing a free-text term onto a structured count/list question (e.g. \"executive order\") distorts it, since the term index matches MENTIONS of a thing as well as the thing itself."

changedInput schema / properties / type / description

Previous value: -"Document type filter: \"rule\", \"proposed_rule\", \"notice\", \"presidential_document\""New value: +"Document type filter: \"rule\", \"proposed_rule\", \"notice\", \"presidential_document\" — mapped internally to the Federal Register API's own codes (RULE/PRORULE/NOTICE/PRESDOCU); an unrecognized value is refused rather than silently matching nothing."

removedInput schema / required
```
Removed value: -[
-  "query"
-]
```

First observedJun 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover safety (readOnly/idempotent/openWorld); the description adds real behavioral context the annotations cannot convey: the relevance ranker can return decade-old documents unless `since` is set, unrecognized type values are refused rather than silently empty, and filters_applied is always echoed so a zero result is distinguishable from a bad query. That is substantive disclosure beyond structured fields.

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, then usage, then returns, then examples — a sensible order, and the examples are genuinely useful call shapes. It is dense and a bit long, and a couple of points (query vs. structured counting, `since` staleness) are restated in both the prose and the schema, which is slight 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?

Despite an output schema existing, the description still sketches what comes back (title, abstract, agency, date, links, EO-specific fields) and, more importantly, covers the non-obvious gaps: ranking staleness, filter echoing, and enum refusal. For a 6-parameter, all-optional, open-world search tool, nothing an agent needs to pick the right call mode is missing.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, and the description earns above that by explaining the tradeoff between `query` and `presidential_document_type` and why `since` should be passed. It stops short of a 5 because most parameter mechanics (enum-like values, slug formats, auto-scoping) are already spelled out in the schema, so much of the description's parameter text is reinforcement rather than new meaning.

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 ("Search the US Federal Register") and enumerates the document classes covered. It explicitly contrasts itself with the sibling recent_rules ("takes no topic filter and would return random unrelated rules"), so an agent can route without opening a 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?

Gives three explicit routing rules with conditions: use free-text whenever the question mentions a SUBJECT, use type:"presidential_document" + presidential_document_type for structured counts/lists, and use executive_order_number to confirm one specific EO. It also names the failure mode of the alternative (free-text "executive order" matches mere mentions), which is exactly the disambiguation an agent needs.

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.