Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant

regulations_search_dockets

Read-only

Search for rulemaking and nonrulemaking dockets on Regulations.gov by keyword, agency, type, and date range. Returns docket ID, title, agency, and last modified date.

Instructions

Search Regulations.gov DOCKETS — the rulemaking/nonrulemaking CONTAINER that groups every document + comment under one regulatory action (api.data.gov keyed; DATA_GOV_API_KEY or the shared DEMO_KEY). Input searchTerm/query, filters (agencyId, docketType Rulemaking/Nonrulemaking, lastModifiedDateGe/Le YYYY-MM-DD), sort (def -lastModifiedDate), limit (1..250, def 20), pageNumber (1..40 HARD cap). Returns { dockets:[{ docketId, title, agencyId, docketType, lastModifiedDate, objectId, id }] } + honest _meta. HONESTY: totalAvailable = meta.totalElements (the EXACT real total, ~277k), NOT the capped totalPages (a 40 sentinel — deriving a total from totalPages lies); page[number] is hard-capped at 40 (10,000-record ceiling) — at the ceiling hasMore stays true but nextOffset is null + a note on how to reach the rest (narrow filters). The API's page[size] floor is 5, so a limit<5 fetches 5 and returns the first limit rows client-side (disclosed; totalAvailable stays exact). NOTE: rin is NULL in list rows — call regulations_get_docket for a docket's rin. DEMO_KEY ~10 req/hr (every call, incl. errors, decrements) — set DATA_GOV_API_KEY for 1000/hr. Genuine-empty ⇒ complete:true/total:0; outage/4xx/429 THROWS (never a fake empty).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort order (default '-lastModifiedDate'). Set: -lastModifiedDate/lastModifiedDate/title/-title (first two DEMO_KEY-verified).
limitNoRequested rows, 1..250, default 20. NOTE: the API's page[size] floor is 5 — a limit<5 fetches page[size]=5 upstream and returns the first `limit` rows client-side (disclosed in _meta.notes); totalAvailable stays the EXACT server total.
queryNoAlias for `searchTerm` (either is accepted; both feed filter[searchTerm]).
agencyIdNoFilter by owning agency acronym (filter[agencyId]), e.g. 'EPA', 'BLM', 'TREAS-FINCEN'.
docketTypeNoFilter by docket type: Rulemaking / Nonrulemaking (filter[docketType]).
pageNumberNo1-based page number, 1..40 (HARD cap — page[number] max is 40; the reachable window is 40×page[size] ≤ 10,000 records).
searchTermNoFull-text search term (filter[searchTerm]) over docket title/abstract, e.g. 'endangered species'.
lastModifiedDateGeNoDocket last modified on/after this date, YYYY-MM-DD (filter[lastModifiedDate][ge]).
lastModifiedDateLeNoDocket last modified on/before this date, YYYY-MM-DD (filter[lastModifiedDate][le]).
Behavior5/5

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

The description goes far beyond the annotations (readOnlyHint, openWorldHint) by detailing pagination caps (40 pages, 10,000 records), the honesty of totalAvailable vs totalPages sentinel, the page[size] floor of 5 behavior, rate limits for DEMO_KEY vs API_KEY, and error handling (genuine-empty vs throws). No contradictions with annotations.

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?

The description is a single paragraph but is front-loaded with purpose and logically organized by parameters, honesty, rate limits, and error handling. It is dense but each sentence contributes essential information. Could be slightly more structured, but it is appropriate for the complexity.

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 9 parameters, no output schema, and numerous siblings, the description is comprehensive: it covers how to use, edge cases (page cap, limit floor), behavior of meta fields, rate limits, and error conditions. It also describes the return shape sufficiently for an agent to interpret results.

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 100% schema description coverage, the baseline is 3, but the description adds significant meaning: explains that 'query' and 'searchTerm' are aliases, gives example values like 'endangered species', describes filter mappings (e.g., filter[agencyId]), explains sort verification, and details the limit floor behavior. This adds value beyond the schema.

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 starts with 'Search Regulations.gov DOCKETS' and explains that dockets are containers for documents and comments, clearly identifying the verb and resource. It distinguishes from siblings like regulations_search_documents and regulations_search_comments by specifying the object type.

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 specifies API key requirements (DEMO_KEY vs DATA_GOV_API_KEY) and explains the pagination cap and the need to narrow filters to reach beyond. It notes that 'rin' is null in list rows and suggests using regulations_get_docket for that field, providing guidance on when to use an alternative. However, it does not explicitly contrast with other search tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cliwant/mcp-sam-gov'

If you have feedback or need assistance with the MCP directory API, please join our Discord server