A
license-
qualityC
maintenanceEnables querying the US Federal Register API for federal register documents and data through natural language.
7
MIT
federal-regulations-mcp-server
Server Details
Search and trace US federal rules across the Federal Register, eCFR, and Regulations.gov.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/federal-regulations-mcp-server
- GitHub Stars
- 1
- Server Listing
- federal-regulations-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.7/5.0
Tool DescriptionsA
Average 4.7/5 across 7 of 7 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct resource or phase: CFR browsing/reading, FR document search/fetch, docket retrieval, comment fetching, and open-comment listing. Overlaps like browse_cfr's search mode versus search_rules are clearly differentiated by corpus (codified CFR vs. Federal Register journal).
Naming Consistency5/5
All tools share the 'regulations_' prefix with snake_case verb_noun names (browse_cfr, find_comments, get_cfr_section, get_docket, get_document, list_open_comments, search_rules). The pattern is uniform and predictable.
Tool Count5/5
Seven tools cover a federal-regulations workflow without bloat: discovery (search_rules, browse_cfr, list_open_comments), retrieval (get_document, get_docket, get_cfr_section), and the comments sub-domain (find_comments). This is a well-scoped set for the domain.
Completeness5/5
The tool surface covers the full research lifecycle: find rules and browse CFR, fetch full text and metadata, trace dockets, read comments, and see what's open for comment. Cross-references (document number, docket ID, CFR parts) chain seamlessly between tools, leaving no critical dead ends.
Available Tools
7 toolsregulations_browse_cfrregulations_browse_cfrARead-onlyInspect
Explore the codified Code of Federal Regulations via eCFR in two modes. "structure" walks the CFR hierarchy (all 50 titles, or one title's chapters → parts → sections) to discover a cite when the exact citation is unknown. "search" runs a full-text query across the codified CFR and returns matching sections with their hierarchy path and a snippet. Both modes accept title and part to narrow the scope, so a part surfaced by structure mode can be searched directly instead of filtering a whole title's hits by eye. Both feed regulations_get_cfr_section. Every search result reports which corpus answered it — the synced local mirror or the live eCFR index — and what that corpus covers, in source and sourceScope.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Point-in-time date, ISO 8601 (YYYY-MM-DD). Defaults to current. Structure mode uses it for the historical hierarchy. Search mode matches only the section text in effect on that day, so a past date searches the CFR as it read then; eCFR indexes 2017-01-03 onward and rejects a date past its current index date. | |
| mode | Yes | "structure": browse the CFR tree (titles, or one title's chapters/parts/sections) to find a cite. "search": full-text search the codified CFR for sections matching a phrase. | |
| part | No | CFR part within the title, in both modes — structure mode narrows the returned tree to that part's sections, search mode restricts matches to text inside that part. Requires title; a part on its own is rejected. Parts can be alphanumeric ("1203a", "16A") and are matched exactly, so pass the identifier as eCFR writes it — "58", not "Part 58" or "058". | |
| query | No | Full-text search phrase (search mode, required in that mode). Ignored in structure mode. | |
| title | No | CFR title number (1–50). Structure mode: omit to list all 50 titles, or provide to expand one title. Search mode: optional filter restricting matches to that title — e.g. 40 for environmental rules, 21 for food and drugs. | |
| per_page | No | Results per page in search mode (1–50, default 20). Ignored in structure mode. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| date | No | Resolved point-in-time date — the hierarchy snapshot (structure mode), or the day whose section text was searched (search mode, live source only). |
| mode | Yes | Which mode produced this result. |
| nodes | No | Hierarchy nodes at the requested level (structure mode). |
| shown | No | Results returned on this page (search mode). |
| notice | No | Guidance when nothing matched. |
| source | No | Provenance: the synced mirror index, or the live eCFR search API (search mode). |
| results | No | Matching CFR sections, this page (search mode). |
| truncated | No | True when search results were capped at per_page. |
| totalCount | No | Total search matches before pagination (search mode). |
| sourceScope | No | What the answering corpus covers — the mirror's title coverage, or the live index and the date it was read at — narrowed by whichever of title and part the call supplied (search mode). Read it before concluding a query found nothing. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds meaningful behavioral context: search results report the source corpus and scope via `source` and `sourceScope`, date handling is explained (search matches text in effect on that day, eCFR indexes from 2017-01-03), and constraints like part requiring title are disclosed. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but every sentence earns its place. It front-loads the core purpose, then explains modes, narrowing, output source, and downstream usage without redundancy. No unnecessary filler.
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 tool with two modes, six parameters, and an output schema, the description is comprehensive. It covers mode-specific behavior, date semantics, narrowing strategies, source reporting, and integration with get_cfr_section. Return value details are omitted appropriately since an output schema exists.
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 100%, so the baseline is 3. The description adds value by synthesizing parameter relationships (title and part narrow both modes, part requires title and matches exactly) and exposing a date limitation not in the schema (eCFR index range). This is helpful beyond the schema, but not exhaustive, so a 4 is appropriate.
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 clearly states the tool explores the CFR via eCFR in two specific modes: "structure" for navigating the hierarchy and "search" for full-text queries. It uses precise verbs like "walks" and "runs a full-text query," and explicitly notes that both modes feed into regulations_get_cfr_section, distinguishing it from siblings.
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?
The description provides explicit when-to-use guidance: structure mode for discovering a cite when the exact citation is unknown, search mode for full-text queries. It also explains how the modes interrelate (a part from structure can be used in search) and points to the downstream tool, giving clear context versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regulations_find_commentsregulations_find_commentsARead-onlyInspect
Fetch public comments on a Federal Register document or a Regulations.gov docket — the unique corpus of what citizens and organizations actually submitted. Provide exactly one targeting parameter: docket_id (all comments in a docket, broadest), document_object_id (comments on one document, from regulations_get_docket), fr_document_number (convenience — resolves the FR number to its Regulations.gov document internally), or comment_id (one comment's full detail and attachments). The list endpoint returns no body text or attachment info — call with comment_id to read a comment's body. When a comment's real content is a PDF/DOCX attachment, the body is a stub and attachmentOnly is true; the attachment download URLs are returned. Requires REGULATIONS_GOV_API_KEY (free at https://api.data.gov/signup/).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Regulations.gov caps a query at 20 pages (5,000 records); for a high-volume docket this surfaces a sample — narrow by document_object_id. | |
| per_page | No | Comments per page (5–250, default 25). Regulations.gov requires a minimum page size of 5. | |
| docket_id | No | Fetch all comments in a docket by docket ID (e.g. "EPA-HQ-OAR-2025-0194"). Broadest scope. Exactly one of docket_id / document_object_id / fr_document_number / comment_id is required — supplying two is rejected, not resolved by precedence. | |
| comment_id | No | Fetch one comment's full detail and attachments by its Regulations.gov comment ID (e.g. "EPA-HQ-OAR-2025-0194-31102"). Use to read a single comment's body after finding it in a list. Mutually exclusive with the other three targeting parameters — pass it alone, not alongside the docket it came from. | |
| document_object_id | No | Fetch comments on one specific document by its Regulations.gov object ID (the objectId from regulations_get_docket's documents). Comments usually attach to the docket's primary (proposed-rule) document. Mutually exclusive with the other three targeting parameters. | |
| fr_document_number | No | Convenience: fetch comments for a Federal Register document by its FR number (e.g. "2025-14555"). Resolves to the Regulations.gov document internally. Saves a get_document → get_docket hop. Mutually exclusive with the other three targeting parameters. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | Which mode produced this result. |
| shown | No | Comments returned on this page (list mode). |
| title | No | Comment title (detail mode). |
| notice | No | Guidance — empty results, or that bodies need comment_id detail mode. |
| target | No | What was queried — docket / document / FR doc (list mode). |
| bodyText | No | Comment body, HTML-stripped. A stub ("See Attached") when content is in attachments; null when empty (detail mode). |
| comments | No | Comments matching the target, this page (list mode). Bodies/attachments require comment_id detail mode. |
| docketId | No | Docket ID, or null (detail mode). |
| commentId | No | Comment ID (detail mode). |
| truncated | No | True when comments exceed the 5,000-record ceiling (list mode). |
| withdrawn | No | True when the comment was withdrawn (detail mode). |
| postedDate | No | Posted date (detail mode). |
| totalCount | No | Total comments matching the target (list mode). |
| attachments | No | Attachment files — substance lives here when attachmentOnly is true (detail mode). |
| organization | No | Submitter organization, or null (detail mode). |
| receivedDate | No | Received date, or null (detail mode). |
| submitterName | No | Submitter name when public, or null (detail mode). |
| attachmentOnly | No | True when attachments exist and the body is a stub/empty — the substance is in the attachment files (detail mode). |
| restrictReason | No | Reason the comment is restricted, or null (detail mode). |
| commentOnDocumentId | No | Document the comment was filed on, or null (detail mode). |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint and openWorldHint. The description adds critical behavioral context not available from annotations: the list endpoint omits body text/attachments, comment_id returns full detail and attachments, attachmentOnly stub behavior for PDF/DOCX, and the REGULATIONS_GOV_API_KEY requirement. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each dense with unique value: purpose, targeting modes, list behavior, attachment handling, and API key. No filler or redundancy. The structure is front-loaded with the core purpose, followed by targeting specifics and behavioral caveats.
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 tool's complexity (6 params, no required, pagination caps, multiple targeting modes, attachment nuances), the description covers all necessary decision points. The output schema exists so return values are handled, and the description provides enough context about when to use each parameter, including the 'narrow by document_object_id' performance hint.
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?
Although schema coverage is 100%, the description adds essential semantics beyond the schema: 'exactly one of docket_id / document_object_id / fr_document_number / comment_id is required — supplying two is rejected, not resolved by precedence.' This is not in the schema (required is 0, no mutually exclusive constraint). It also clarifies fr_document_number resolves internally, and page semantics explain the 5,000-record cap and sampling behavior.
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 and resource: 'Fetch public comments on a Federal Register document or a Regulations.gov docket.' It distinguishes itself from siblings by emphasizing the 'unique corpus of what citizens and organizations actually submitted' and by listing four targeting modes that clearly relate to comments, not CFR browsing or rule search.
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?
Explicitly says 'Provide exactly one targeting parameter' and explains when to use each: docket_id for broadest, document_object_id for one document, fr_document_number as convenience, comment_id for full detail. It also gives a when-not scenario: 'The list endpoint returns no body text or attachment info — call with comment_id to read a comment's body,' and warns that high-volume dockets cap at 20 pages so 'narrow by document_object_id.' This is strong actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regulations_get_cfr_sectionregulations_get_cfr_sectionARead-onlyIdempotentInspect
Read the codified text at a CFR location via eCFR — current or as of a past date. Answers "what does 40 CFR 50.1 say today?" and "...as of 2019-01-01?". Three locations: title + part + section for one section; title + part alone for the whole part (large parts can be very long, and their appendices are named rather than inlined; prefer a specific section when you know it); title + appendix for one appendix, passing the identifier exactly as regulations_browse_cfr emits it. eCFR retains historical versions back to roughly 2017; a date before coverage is rejected with guidance. Current single-section reads are served from a synced local mirror when available; the source is reported.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Point-in-time date, ISO 8601 (YYYY-MM-DD). Default current. eCFR retains historical versions back to ~2017; a date before coverage is rejected. | |
| part | No | CFR part within the title (e.g. "50"). Parts can be alphanumeric. Required unless appendix is given, where it is optional but recommended: an appendix identifier is unique within a part, not within a title, so without a part eCFR picks one of the matches. Obtain from regulations_browse_cfr or a Federal Register document's cfrReferences. | |
| title | Yes | CFR title number (1–50). E.g. 40 for "Protection of Environment". | |
| section | No | Section identifier within the part (e.g. "50.1"). Omit to fetch the entire part — large parts can be very long; prefer a specific section when you know it. Cannot be combined with appendix. | |
| appendix | No | Appendix identifier, verbatim as eCFR writes it — the `appendix` field or the leading phrase of the `cfrCite` on a regulations_browse_cfr appendix node or search hit. It is free-form prose, not a letter: "Appendix A-1 to Part 50", "Appendix A to Subpart C of Part 4", "Schedule I to Part 789", "Special Federal Aviation Regulation No. 88". Pass the whole phrase; a short form such as "A-1" matches nothing. Cannot be combined with section. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | The issue/point-in-time date the text reflects (ISO 8601). |
| part | Yes | CFR part; null only for an appendix that hangs off a chapter, subchapter, or subtitle rather than a part. |
| title | Yes | CFR title number. |
| source | Yes | Provenance: the synced mirror, or the live eCFR API. |
| cfrCite | Yes | Assembled cite — "40 CFR 50.1" for a section, "40 CFR 50" for a part, "Appendix A-1 to Part 50, Title 40" for an appendix (eCFR's own form, leading with the identifier this tool takes back as `appendix`). |
| heading | Yes | Section, part, or appendix heading. |
| section | Yes | Section identifier; null when a whole part or an appendix was fetched. |
| appendix | Yes | Appendix identifier; null when a section or whole part was fetched. |
| bodyText | Yes | Text of the section, part, or appendix, XML stripped to plain text. Paragraphs, subheadings, editorial notes, tables (one pipe-delimited line per row), figure references ("[Figure: /graphics/…]"), and the trailing source citation are kept in document order. The source citation is the bracketed Federal Register history the text ends in ("[36 FR 22384, Nov. 25, 1971, as amended at 81 FR 68276, Oct. 3, 2016]") — pass one of its FR cites to regulations_search_rules to reach the rulemaking that produced this text. Empty only where the location is a placeholder carrying nothing but its heading — "[Reserved]", or an agency variant of it. |
| sections | No | Present only when a whole part was fetched — each section in the part. |
| appendices | No | Present on a whole-part fetch when the part has appendices — their identifiers and headings, without their text. A part's appendices routinely run several times the length of its sections, so they are not inlined; call this tool again with `appendix` set to one of these identifiers to read it. Absent means the part has no appendices; a single-section or appendix fetch never carries this field. |
| hierarchyPath | Yes | Human-readable hierarchy path. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful behavioral context beyond those: eCFR historical depth (~2017), rejection with guidance for pre-coverage dates, the local mirror for current single-section reads, and source reporting. It also discloses that appendices are named rather than inlined for whole-part reads. This fully informs an agent of safety and performance traits.
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 a single dense paragraph with no filler. Each sentence earns its place: first sentence states the core function, second gives example questions, third enumerates the three modes with caveats, fourth covers historical coverage, fifth notes performance/source behavior. The semicolon-separated structure improves readability.
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?
The tool has 5 parameters, an output schema, and annotations; the description fully covers the essential usage aspects: available location modes, parameter combinations, historical date handling, source reporting, and cross-reference to browse for identifiers. With an output schema available, the description does not need to explain return values. It is complete for a read-only tool of this complexity.
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 100%, so the baseline is 3. The description adds value by grouping the three location modes (title+part+section, title+part, title+appendix) and by explaining the relationship between part and appendix (uniqueness within part). It also reiterates the 'exact identifier' requirement for appendix. This outperforms the baseline by providing combination semantics, though the schema already captures individual parameter meaning well.
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 and resource: 'Read the codified text at a CFR location via eCFR'. It also includes example questions ('what does 40 CFR 50.1 say today?') that make the purpose unambiguous. The reference to regulations_browse_cfr as a source of identifiers helps distinguish this reading tool from the browsing sibling.
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?
The description explicitly lays out three usage modes (section, part, appendix), each with clear guidance, including when to prefer a specific section over the whole part and how to obtain the exact appendix identifier. It also warns about historical coverage limits and states what happens when a date is too early. This is strong, actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regulations_get_docketregulations_get_docketARead-onlyIdempotentInspect
Pull a rulemaking docket from Regulations.gov by docket ID (e.g. "EPA-HQ-OAR-2025-0194") — the docket's metadata (title, agency, RIN, abstract) and the documents filed in it (NPRM, final rule, supporting materials). The docket is the folder holding a rule's whole paper trail; each returned document's objectId feeds regulations_find_comments. A docket often contains hundreds of supporting materials — filter document_types to "Proposed Rule"/"Rule" to find the rule documents themselves. Requires REGULATIONS_GOV_API_KEY (free at https://api.data.gov/signup/); the Federal Register and eCFR tools work without it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based). Regulations.gov caps a query at 20 pages (5,000 records); beyond that, narrow with document_types. | |
| per_page | No | Documents per page (5–250, default 25). Regulations.gov requires a minimum page size of 5. | |
| docket_id | Yes | Regulations.gov docket ID (e.g. "EPA-HQ-OAR-2025-0194"). Obtain from a Federal Register document's docketId (regulations_get_document) or an agency rulemaking reference. | |
| document_types | No | Filter the docket's documents to these types. Omit for all. A docket often contains hundreds of "Supporting & Related Material" items — filter to "Proposed Rule"/"Rule" to find the rule documents. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rin | Yes | Regulation Identifier Number ("Not Assigned" when none), or null. |
| shown | No | Documents returned on this page. |
| title | Yes | Docket title. |
| notice | No | Guidance when the docket has no documents. |
| abstract | Yes | Docket abstract, or null. |
| agencyId | Yes | Agency ID (e.g. "EPA"), or null. |
| docketId | Yes | Regulations.gov docket ID. |
| objectId | Yes | Docket object ID, or null. |
| documents | Yes | Documents filed in the docket (this page). |
| truncated | No | True when documentCount exceeds the returned set / 5,000 ceiling. |
| docketType | Yes | Docket type (e.g. "Rulemaking"), or null. |
| modifyDate | Yes | Last-modified date, or null. |
| documentCount | Yes | Total documents in the docket (before pagination). |
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true. The description adds valuable context beyond annotations: requires API key, pagination limits (20 pages, 5,000 records), and that dockets often contain hundreds of supporting materials.
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?
Four concise sentences, each carrying essential information. Front-loaded with purpose, then usage guidance, and finally prerequisite. No redundant or unnecessary text.
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 tool's complexity (4 parameters, output schema exists), the description is complete. It explains the docket concept, return contents, filtering strategies, and even provides a real-world example docket ID.
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 100% but description adds significant meaning: explains docket_id format, clarifies that document_types filter helps find rule documents, and mentions pagination behavior. This goes beyond schema descriptions.
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 clearly states it pulls a rulemaking docket by docket ID, including metadata and documents. It specifies the exact resource (docket) and action (pull), and distinguishes from siblings like regulations_find_comments and Federal Register tools.
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 to use the tool (to get a docket's metadata and documents) and prerequisites (requires API key). It also offers guidance on filtering document types to find rule documents, but does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regulations_get_documentregulations_get_documentARead-onlyIdempotentInspect
Fetch one Federal Register document by its FR document number — full metadata (title, type, agencies, abstract, action, effective/comment dates, RINs) plus the cross-source handles that make this a workflow server. The output carries the docket ID (chain into regulations_get_docket or regulations_find_comments) and the affected CFR parts (chain into regulations_get_cfr_section). Set include_full_text only when the rule body itself is needed — final rules can run tens of thousands of words.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| document_number | Yes | Federal Register document number (e.g. "2025-14555"). Obtain from regulations_search_rules results (the documentNumber field). | |
| include_full_text | No | When true, fetch and inline the document body as plain text (can be large). Default false returns the body URLs only; fetch full text only when you need to read the rule itself, not just its metadata and cross-links. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| type | Yes | Document type. |
| dates | Yes | Free-text dates summary from the rule, or null. |
| title | Yes | Document title. |
| action | Yes | Action line (e.g. "Final rule."), or null. |
| htmlUrl | Yes | Federal Register web URL for the document. |
| abstract | Yes | Abstract summary, or null. |
| agencies | Yes | Issuing agency names. |
| docketId | Yes | Regulations.gov docket ID — chain into regulations_get_docket / find_comments. Null when not on Regulations.gov. |
| fullText | No | Inlined plain-text body — present only when include_full_text=true. |
| rawTextUrl | Yes | URL of the plain-text body. |
| bodyHtmlUrl | Yes | URL of the rendered HTML body. |
| effectiveOn | Yes | Effective date (ISO 8601), or null. |
| commentCount | Yes | FR-reported comment count from Regulations.gov; null when not on Regulations.gov. |
| cfrReferences | Yes | Affected CFR parts — chain into regulations_get_cfr_section. |
| documentNumber | Yes | Federal Register document number. |
| commentsCloseOn | Yes | Comment-period close date (ISO 8601); when set, still open for comment. |
| publicationDate | Yes | Publication date (ISO 8601). |
| regulationIdNumbers | Yes | Regulation Identifier Number(s) (RIN). |
| supportingDocuments | Yes | Related Regulations.gov supporting documents. |
| regulationsGovDocumentId | Yes | Regulations.gov document ID — chain into regulations_find_comments (document-scoped). Null when absent. |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by noting that full text can be large (final rules tens of thousands of words) and that the output carries cross-source handles and chaining info. No contradiction 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?
Two sentences, front-loaded with primary purpose, then details. Each sentence earns its place. Could be slightly more concise but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values. It explains cross-links, chaining, and large-text warning, which is sufficient for a simple fetch-by-id tool. No gaps identified.
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 100%, and the description adds meaningful usage guidance: document_number's format and source, and include_full_text's trade-off. This goes beyond the schema descriptions.
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 clearly states it fetches a single Federal Register document by FR document number, listing full metadata and cross-source handles. It distinguishes from siblings like regulations_search_rules (which returns multiple) and regulations_get_docket (which gets a docket). The verb 'fetch' and resource 'Federal Register document' are specific.
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 advises when to set include_full_text (only when rule body is needed), and explicitly chains to other tools (regulations_get_docket, regulations_find_comments, regulations_get_cfr_section). However, it does not explicitly state when to not use this tool in favor of siblings, though the context of sibling names helps infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regulations_list_open_commentsregulations_list_open_commentsARead-onlyInspect
List rules currently open for public comment, filterable by agency slug and topic, sorted by closing date (soonest first). "What can I still weigh in on?" Runs on the Federal Register's open-comment window and is fully functional without a key. When REGULATIONS_GOV_API_KEY is configured, each row is enriched with the comment count from the Federal Register document's embedded Regulations.gov info (no extra rate-limited call). Open one row with regulations_get_document for the full proposal, or pull the comments with regulations_find_comments.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1–50). The FR caps total_pages at 50; with per_page=100 this covers up to 5,000 open rules. | |
| query | No | Full-text filter across open rules. Omit to list all rules currently open for comment. | |
| agencies | No | Filter to one or more agencies by Federal Register agency slug (e.g. "environmental-protection-agency"). | |
| per_page | No | Results per page (1–100, default 20). | |
| closing_before | No | Only rules whose comment period closes on or before this date, ISO 8601 (YYYY-MM-DD). Use to find deadlines you need to act on soon. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| asOf | Yes | The "today" the open-window filter used (ISO 8601). |
| keyed | Yes | Whether comment counts were enriched (REGULATIONS_GOV_API_KEY present). |
| shown | No | Results returned on this page. |
| notice | No | Guidance when nothing matched, or that comment counts are unavailable without a key. |
| results | Yes | Rules open for comment (this page), closing soonest first. |
| truncated | No | True when matches exceed the FR 5,000-record navigation ceiling. |
| totalCount | Yes | Total rules open for comment matching the filters. |
Tool Definition Quality
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it is fully functional without a key, enriches rows with comment count when the key is set, and advises using sibling tools for more details. No contradictions with readOnlyHint and openWorldHint.
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?
Three concise sentences, front-loaded with the main purpose, and every sentence provides essential information without 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?
With an output schema present, return format explanation is unnecessary. The description covers use cases, behavior, parameter nuances, and integration with sibling tools, making it fully informative for agent selection.
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?
Input schema covers 100% of parameters with clear descriptions. The description adds value by noting the sort order and page limit implications, but the schema already does the heavy lifting, so baseline 3 is appropriate.
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 explicitly states the tool lists rules open for public comment, with filtering and sorting by closing date. It clearly identifies the resource and action, distinguishing it from siblings like regulations_search_rules and regulations_get_document.
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 a use case ('What can I still weigh in on?'), mentions the data source (Federal Register), and explains behavior with/without an API key. It references sibling tools for next steps, but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regulations_search_rulesregulations_search_rulesARead-onlyInspect
Search the Federal Register — the daily journal of US proposed rules, final rules, notices, and presidential documents (1994–present) — filtering by full-text query, document type, agency slug, publication date range, and whether the rule is open for comment. The primary discovery entry point: results carry the document number (open with regulations_get_document), docket IDs, RINs, and affected CFR parts that chain into the comment and codified-text tools. The Federal Register caps navigation at 50 pages and the match count at 10,000; when a result set is larger, narrow with published_after/published_before rather than paging deeper.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1–50, default 1). The FR API caps total_pages at 50 — with per_page=100 this allows navigating up to 5,000 results. To reach beyond that window, narrow with published_after/published_before rather than paging deeper. | |
| type | No | Document types to include. PRORULE=Proposed Rule, RULE=Final Rule, NOTICE=Notice, PRESDOCU=Presidential Document. Omit for all types. | |
| query | No | Full-text search across document title and body. Omit to browse by filters alone (e.g. all EPA proposed rules in a date range). | |
| agencies | No | Filter to one or more agencies by Federal Register agency slug (e.g. "environmental-protection-agency", "securities-and-exchange-commission"). Slugs are the kebab-case agency name; if unsure, search by query and read the agency slugs off the results. | |
| per_page | No | Results per page (1–100, default 20). | |
| published_after | No | Earliest publication date, ISO 8601 (YYYY-MM-DD). Combine with published_before to window large result sets — the FR caps navigation at 50 pages. | |
| published_before | No | Latest publication date, ISO 8601 (YYYY-MM-DD). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| shown | No | Results returned on this page. |
| notice | No | Guidance when nothing matched or when results were truncated. |
| results | Yes | Matching Federal Register documents (this page). |
| truncated | No | True when matches exceed the FR 50-page (5,000-record) navigation ceiling. |
| totalCount | Yes | Total matches before pagination (FR count; capped at 10,000 by the API window). |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination limits (50 pages, 10,000 results) and suggests workarounds. Annotations confirm read-only (readOnlyHint=true), and no contradiction exists.
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?
Well-structured with front-loaded purpose. Slightly long but every sentence conveys essential information without 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?
Given output schema exists, description explains result context (document number, docket IDs, RINs, affected CFR parts) and links to other tools. Comprehensive for a search tool with good annotations.
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 100%, yet the description adds significant value by explaining page limits, per_page max, and the meaning of type enum values. Provides usage guidance for each parameter 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 clearly states the tool searches the Federal Register with specific filters and identifies it as the primary discovery entry point, distinguishing it from sibling tools like regulations_get_document.
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?
Explicitly advises when to use (primary discovery) and how to narrow results (use date filters, not deeper paging). Notes that results chain into other tools. Could add explicit when-not scenarios, but sufficient context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityBmaintenanceEnables AI agents to search and track US federal regulations, documents, and executive orders from the Federal Register, with no API keys required.MIT
- Alicense-quality-maintenanceEnables interaction with the Regulations.gov API to search federal rulemaking dockets, proposed and final rules, public comments, and comment periods. Supports tracking FAR/DFARS case histories and monitoring open comment periods across federal agencies with optional API key authentication for higher rate limits.
- AlicenseAqualityDmaintenanceEnables AI assistants to search and retrieve executive orders, presidential documents, rules, and agency information from the Federal Register API through natural language queries.1284MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.