A
licenseNot graded
qualityC
maintenanceEnables querying the US Federal Register API for federal register documents and data through natural language.
16
MIT
federal-regulations-mcp-server
Server Details
Search and trace US federal rules across the Federal Register, eCFR, and Regulations.gov.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/federal-regulations-mcp-server
- GitHub Stars
- 1
- Server Listing
- federal-regulations-mcp-server
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 | No | Which mode produced this result. |
| error | No | Present when the call failed. Absent on success. |
| 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. |
TDQS
A3.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description covers the 'read' nature (no mutation) and explicitly mentions the `source` and `sourceScope` fields reporting which corpus answered the query. But for a read tool with readOnlyHint=true and no destructive field, the bar is lower; the description still doesn't mention potential errors, rate limits, or the impact of date on a search across corpora. It does disclose that search interprets date as text-match day, which is a useful behavioral detail. However, the readOnlyHint annotation already signals safety, so a 3 would be appropriate. I'll settle on 3.
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 one comprehensive paragraph covering purpose, modes, parameters, and output. It's front-loaded with the main purpose, but the paragraph is long. It's not overly verbose given the two modes, but it could be more scannable. Still, each sentence adds value, no fluff. I'll give 4.
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?
The description covers the two modes, the parameters that vary between them, the output (snippets, section references), and the sourceScope result field. It mentions the relationship to regulations_get_cfr_section. Given there's no output schema, it explains return values reasonably. Missing: error conditions (e.g., part without title) are only in the schema. Still, quite complete for the tool's 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?
The schema covers most parameters (date, mode, title, part, per_page) with descriptions/clarity. The description adds valuable context that the schema lacks — e.g., that query is required in search mode but ignored in structure mode, part can be alphanumeric and matched exactly, and date in structure mode uses historical hierarchy while search matches text on that day. That's meaningful semantic enrichment beyond the schema, worth a 4 rather than baseline 3.
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 what the tool does: it explores the codified CFR via eCFR in two modes ('structure' to browse the title tree and find a cite, 'search' to run a full-text query). It names the resource (the codified CFR), the two behavioral modes, and explicitly links to the follow-up tool (regulations_get_cfr_section). The purpose is unambiguous and distinguishes the two operations well.
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 explains when to use each mode and how they interrelate — structure mode discovers a cite, search mode queries full text, and a part from structure mode can be fed into search. It stops short of explicitly stating when NOT to use this tool or naming sibling alternatives, so it doesn't hit the top of the scale, but the mode guidance is clear operational direction.
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 | No | Which mode produced this result. |
| error | No | Present when the call failed. Absent on success. |
| 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). |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint and openWorldHint, leaving behavioral details to the description. The description discloses that the list endpoint omits body text and attachment info, that comment_id retrieves full detail, and that attachment-only comments include a stub with attachmentOnly=true plus download URLs. It also mentions the API key requirement. These are material behaviors beyond the annotations, adding real transparency.
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 two sentences with a moderate length, front-loading the core purpose before diving into targeting options and behavioral caveats. It is efficient and free of fluff, though it could tighten the listing of parameters, but the structure is clear and each sentence earns its place.
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 complexity (six parameters, four targeting modes, list vs detail behavior), the description covers the main decision points: how to choose a target, the difference between list and comment detail, attachment handling, API key requirement, and pagination hints (though pagination is in schema). The output schema exists (indicated by has_output_schema: true) so return formatting is covered elsewhere; the description fills all gaps not in structured fields.
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?
The input schema already provides 100% coverage with detailed descriptions for each parameter (including mutual exclusivity and examples). The description adds extra context like 'broadest scope' for docket_id, 'convenience' for fr_document_number, and the general rule of exactly one targeting parameter. This enriches the semantics beyond the schema without repeating it verbatim, justifying a score above the baseline of 3.
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 'Fetch public comments on a Federal Register document or a Regulations.gov docket', clearly stating the verb (Fetch), resource type (comments), and the two scopes (FR document or docket). It also notes the unique corpus, and the differentiation from siblings like regulations_get_docket/regulations_get_document is implicit in the focus on comments. This leaves no ambiguity about what the tool does.
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 instructs to 'Provide exactly one targeting parameter' and enumerates each option with its context (broadest for docket, per-document for object ID, convenience for FR number, detail for comment_id). It adds exclusion guidance: 'supplying two is rejected, not resolved by precedence' and warns that the list endpoint returns no body, steering users to comment_id for full content. This fully covers when to use which variant and the prerequisite of the API key.
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 | No | The issue/point-in-time date the text reflects (ISO 8601). |
| part | No | CFR part; null only for an appendix that hangs off a chapter, subchapter, or subtitle rather than a part. |
| error | No | Present when the call failed. Absent on success. |
| title | No | CFR title number. |
| source | No | Provenance: the synced mirror, or the live eCFR API. |
| cfrCite | No | 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 | No | Section, part, or appendix heading. |
| section | No | Section identifier; null when a whole part or an appendix was fetched. |
| appendix | No | Appendix identifier; null when a section or whole part was fetched. |
| bodyText | No | 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 | No | Human-readable hierarchy path. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds genuine behavioral disclosures beyond that: historical coverage back to roughly 2017 with rejection-guidance behavior, and the local-mirror serving for current single-section reads with 'the source is reported.' The note that appendices are 'named rather than inlined' sets expectations about part output structure. No contradiction with the read-only annotation.
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?
A single dense paragraph front-loaded with purpose in the first sentence. Every clause carries information — examples, three modes, size caveat, date coverage, mirror behavior — though the middle 'Three locations' sentence is long with embedded parentheticals. The date-coverage detail is slightly redundant with the schema's date description but is important enough to justify 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?
For a 5-parameter, three-mode tool, the description covers all invocation-relevant behavior: valid parameter combinations, size caveats, appendix identifier requirements, date coverage limits and rejection behavior, and source/mirror provenance. The output schema documents return values, so the description need not explain them. The only unaddressed edge case is behavior for nonexistent CFR locations, which is a minor gap against the overall completeness.
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 per the rubric. The description adds combinatorial meaning the schema does not explicitly express: the three valid parameter groupings (title+part+section, title+part, title+appendix) and the strategic guidance to prefer a section over a part and to pass appendix identifiers 'exactly as regulations_browse_cfr emits it.' That framing meaningfully helps an agent choose a parameter combination.
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?
States a precise verb+resource: 'Read the codified text at a CFR location via eCFR.' Concrete example questions ('what does 40 CFR 50.1 say today?') anchor the intent. The three-location framing distinguishes it from the browsing sibling, regulations_browse_cfr, which is referenced only as the source of identifiers rather than the reader.
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?
Provides clear context: the three location modes, the explicit size caveat and preference ('large parts can be very long... prefer a specific section when you know it'), and the historical-date behavior with pre-2017 dates 'rejected with guidance.' It also points to regulations_browse_cfr as the identifier source, establishing a workflow. However, it never explicitly states when not to use this tool versus an alternative, so it stops short of full when/when-not routing.
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 | No | Regulation Identifier Number ("Not Assigned" when none), or null. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Documents returned on this page. |
| title | No | Docket title. |
| notice | No | Guidance when the docket has no documents. |
| abstract | No | Docket abstract, or null. |
| agencyId | No | Agency ID (e.g. "EPA"), or null. |
| docketId | No | Regulations.gov docket ID. |
| objectId | No | Docket object ID, or null. |
| documents | No | Documents filed in the docket (this page). |
| truncated | No | True when documentCount exceeds the returned set / 5,000 ceiling. |
| docketType | No | Docket type (e.g. "Rulemaking"), or null. |
| modifyDate | No | Last-modified date, or null. |
| documentCount | No | Total documents in the docket (before pagination). |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly and idempotent behavior, which the description does not contradict. The description adds transparency about the API key requirement and the pagination constraints (max 20 pages, min page size 5), which are behavioral details not covered by annotations. It does not describe side effects (none exist) or the exact response structure, but that is covered by the output schema.
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 compact (three sentences) and front-loaded with the primary purpose. It efficiently conveys the key usage details (API key, filtering hint, relationship with other tools) without redundancy or unnecessary elaboration.
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 complexity (4 parameters, filtering, pagination, API key), the description covers all essential aspects: what the tool does, how to supply the ID, how to filter results, and a note on the API key. The output schema exists, so return values need not be described. It also situates the tool within the broader suite of sibling tools, enabling correct selection and usage.
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?
All four parameters have detailed descriptions in the schema, and the main description adds extra context: it explains how to obtain a docket_id, clarifies the purpose of the document_types filter, and provides a concrete example. This goes beyond the schema's parameter descriptions, fully conveying each parameter's meaning and use.
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 states a specific verb (Pull), resource (rulemaking docket from Regulations.gov), and scope (by docket ID). It also enumerates what is returned (metadata and documents) and clarifies how to identify the desired rule documents within the docket, making the tool's purpose unambiguous.
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 explains when to use the tool (to fetch a docket with a valid ID) and provides guidance on filtering document types. It also notes the API key requirement and points to related tools (e.g., regulations_find_comments) via the objectId linkage, though it does not explicitly name alternative tools for when this one should not be used.
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 | No | Document type. |
| dates | No | Free-text dates summary from the rule, or null. |
| error | No | Present when the call failed. Absent on success. |
| title | No | Document title. |
| action | No | Action line (e.g. "Final rule."), or null. |
| htmlUrl | No | Federal Register web URL for the document. |
| abstract | No | Abstract summary, or null. |
| agencies | No | Issuing agency names. |
| docketId | No | 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 | No | URL of the plain-text body. |
| bodyHtmlUrl | No | URL of the rendered HTML body. |
| effectiveOn | No | Effective date (ISO 8601), or null. |
| commentCount | No | FR-reported comment count from Regulations.gov; null when not on Regulations.gov. |
| cfrReferences | No | Affected CFR parts — chain into regulations_get_cfr_section. |
| documentNumber | No | Federal Register document number. |
| commentsCloseOn | No | Comment-period close date (ISO 8601); when set, still open for comment. |
| publicationDate | No | Publication date (ISO 8601). |
| regulationIdNumbers | No | Regulation Identifier Number(s) (RIN). |
| supportingDocuments | No | Related Regulations.gov supporting documents. |
| regulationsGovDocumentId | No | Regulations.gov document ID — chain into regulations_find_comments (document-scoped). Null when absent. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, and the description adds concrete behavioral detail: default returns body URLs only, include_full_text fetches the body which 'can run tens of thousands of words', and the output carries docket ID and CFR parts. This goes beyond the annotations and helps the agent anticipate payload size and output structure.
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?
Two sentences with each serving a distinct purpose: core fetch, workflow chaining, and the include_full_text caveat. The information is front-loaded and there is no redundant wording.
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 two-parameter, read-only tool with a rich output schema, the description supplies the operational essentials: what the metadata covers, what cross-links are available, and when to request full text. Nothing an agent needs to invoke it correctly is omitted.
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?
Both parameters are fully documented in the schema (100% coverage) with examples and guidance, so the description is not required to carry the load. It does add context around include_full_text (size warning, metadata-only default) and document_number sourcing via search_rules, but these are also present in the schema. 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 opens with a specific verb and resource ('Fetch one Federal Register document by its FR document number') and enumerates the returned metadata. It differentiates from siblings by describing the cross-source handles and chaining targets (regulations_get_docket, regulations_find_comments, regulations_get_cfr_section), making clear this is the document-level entry point.
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 gives usage context by telling the agent to chain into regulations_get_docket, regulations_find_comments, or regulations_get_cfr_section when those are the downstream need, and advises to set include_full_text only when the rule body is needed. It does not explicitly state when not to use this tool versus alternatives, but the chaining instructions and full-text warning provide clear context.
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 (2–100, default 20). The Federal Register API treats exactly 1 as its default page size instead of returning one result. | |
| 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 | No | The "today" the open-window filter used (ISO 8601). |
| error | No | Present when the call failed. Absent on success. |
| keyed | No | 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 | No | Rules open for comment (this page), closing soonest first. |
| truncated | No | True when matches exceed the FR 5,000-record navigation ceiling. |
| totalCount | No | Total rules open for comment matching the filters. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds substantial behavioral detail: it uses the Federal Register open-comment window, is fully functional without an API key, and enriches results with embedded Regulations.gov comment counts only when the key is configured, without an extra rate-limited call. This is genuinely useful context about dependencies, auth, and performance.
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 compact, front-loaded with the core behavior, and then adds essential operational and follow-up context in a few short sentences. Every sentence serves a purpose: behavior, user question, key behavior, and related tools.
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?
Together with a fully documented input schema, an output schema, and annotations, the description supplies enough context: data source, sorting, filtering, key-dependent enrichment, no-added-rate-limit behavior, and clear next steps. There are no meaningful gaps an agent would have to guess.
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?
The input schema already documents all parameters at 100% coverage, so the description does not need to compensate. The phrase 'filterable by agency slug and topic' adds a high-level mapping to parameters and the sorting by closing date is helpful context, but the schema already carries most of the parameter 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?
The description begins with a specific verb and resource: 'List rules currently open for public comment,' with clear filtering and sorting behavior. It immediately distinguishes the tool from siblings by centering on the open-comment window and posing the natural use-case question, 'What can I still weigh in on?'
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 gives clear context for when to use the tool: when the user asks about rules open for comment and actionable deadlines. It also points to the right follow-up tools, regulations_get_document and regulations_find_comments. It does not explicitly contrast it with regulations_search_rules or other sibling search tools, so explicit when-not-to-use guidance is missing.
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 (2–100, default 20). The Federal Register API treats exactly 1 as its default page size instead of returning one result. | |
| 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 |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| shown | No | Results returned on this page. |
| notice | No | Guidance when nothing matched or when results were truncated. |
| results | No | Matching Federal Register documents (this page). |
| truncated | No | True when matches exceed the FR 50-page (5,000-record) navigation ceiling. |
| totalCount | No | Total matches before pagination (FR count; capped at 10,000 by the API window). |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a read-only, open-world tool, and the description adds valuable behavioral detail beyond that: the Federal Register caps navigation at 50 pages and match count at 10,000, and results chain into downstream tools. This gives agents the necessary context on pagination limits and result composition without waiting for a failure.
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 about 110 words, and every sentence earns its place: purpose, chaining value, and a concrete limitation. It is front-loaded with the core functionality, then adds behavioral and usage nuances without fluff.
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 moderate complexity and the presence of an output schema, the description covers the essentials: result fields (document number, docket IDs, RINs, affected CFR parts), how results connect to comments and codified-text tools, and how to handle large result sets. Nothing critical for an agent to invoke this correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema description coverage is 100%, the description falsely claims a filter 'whether the rule is open for comment' that is not present in the schema, misleading agents into thinking such a filter exists. This outweighs the baseline benefit of high schema coverage and actually harms parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('Search') and resource (the Federal Register), and differentiates itself as 'the primary discovery entry point' with chains to sibling tools. However, it incorrectly claims filtering by 'whether the rule is open for comment,' a filter that does not exist in the schema, slightly muddying the otherwise precise scope.
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—as the primary discovery endpoint—and points to the related tool 'regulations_get_document' for following document numbers. It does not explicitly exclude alternatives or give when-not-to-use guidance, but the mention of chaining and pagination guidance gives agents a clear sense of when to use this versus the rest of the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
- Changed
regulations_browse_cfr6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mode" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `query_required`: mode=\"search\" with no query phrase. `title_not_found`: Structure mode where eCFR publishes no tree for the title at that date (a reserved title, or a date outside its coverage), or where the part is absent from the tree it does publish. `title_required_for_part`: A part was given with no title. Part identifiers repeat across titles, and eCFR rejects a part filter that names no title. `date_out_of_range`: Search mode with a date outside eCFR's indexed window (before 2017-01-03, or past its current index date). `upstream_unavailable`: eCFR returned a 5xx, timed out, or served an HTML error page (live path). Other values are possible when a failure originates below the handler.", + "examples": [ + "query_required", + "title_not_found", + "title_required_for_part", + "date_out_of_range", + "upstream_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mode" -]
- Changed
regulations_find_comments6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mode" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `auth_required`: REGULATIONS_GOV_API_KEY is not configured, or Regulations.gov rejected the key that is. `target_required`: None of docket_id / document_object_id / fr_document_number / comment_id was given. `multiple_targets`: More than one of docket_id / document_object_id / fr_document_number / comment_id was given. `not_found`: The target docket/document/comment has no comments or does not exist. `rate_limited`: Regulations.gov returned 429. `upstream_unavailable`: Regulations.gov returned a 5xx, timed out, or could not be reached at all. Other values are possible when a failure originates below the handler.", + "examples": [ + "auth_required", + "target_required", + "multiple_targets", + "not_found", + "rate_limited", + "upstream_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mode" -]
- Changed
regulations_get_cfr_section6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "cfrCite", + "title", + "part", + "section", + "appendix", + "heading", + "hierarchyPath", + "date", + "source", + "bodyText" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No such title/part/section/appendix at that date. `location_required`: Neither part nor appendix was given, so the call names no location to read. `conflicting_target`: Both section and appendix were given. They name two different locations, and picking one silently would return text the call did not ask for. `date_out_of_range`: The requested date precedes eCFR historical coverage. `upstream_unavailable`: eCFR returned a 5xx, timed out, or served an HTML error page (live path). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "location_required", + "conflicting_target", + "date_out_of_range", + "upstream_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "cfrCite", - "title", - "part", - "section", - "appendix", - "heading", - "hierarchyPath", - "date", - "source", - "bodyText" -]
- Changed
regulations_get_docket6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "docketId", + "title", + "docketType", + "agencyId", + "rin", + "abstract", + "modifyDate", + "objectId", + "documentCount", + "documents" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `auth_required`: REGULATIONS_GOV_API_KEY is not configured, or Regulations.gov rejected the key that is. `not_found`: No docket exists with that ID. `rate_limited`: Regulations.gov returned 429 (1,000 requests/hour per key). `upstream_unavailable`: Regulations.gov returned a 5xx, timed out, or could not be reached at all. Other values are possible when a failure originates below the handler.", + "examples": [ + "auth_required", + "not_found", + "rate_limited", + "upstream_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "docketId", - "title", - "docketType", - "agencyId", - "rin", - "abstract", - "modifyDate", - "objectId", - "documentCount", - "documents" -]
- Changed
regulations_get_document6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "documentNumber", + "title", + "type", + "abstract", + "action", + "dates", + "publicationDate", + "effectiveOn", + "commentsCloseOn", + "agencies", + "regulationIdNumbers", + "cfrReferences", + "docketId", + "regulationsGovDocumentId", + "commentCount", + "supportingDocuments", + "bodyHtmlUrl", + "rawTextUrl", + "htmlUrl" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No Federal Register document exists with that number. `upstream_unavailable`: Federal Register returned a 5xx, timed out, served an HTML error page, or failed to serve the body URL it published (include_full_text only). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "upstream_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "documentNumber", - "title", - "type", - "abstract", - "action", - "dates", - "publicationDate", - "effectiveOn", - "commentsCloseOn", - "agencies", - "regulationIdNumbers", - "cfrReferences", - "docketId", - "regulationsGovDocumentId", - "commentCount", - "supportingDocuments", - "bodyHtmlUrl", - "rawTextUrl", - "htmlUrl" -]
- Changed
regulations_list_open_comments8 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / per_page / descriptionPrevious value: -"Results per page (1–100, default 20)."New value: +"Results per page (2–100, default 20). The Federal Register API treats exactly 1 as its default page size instead of returning one result." - changed
Input schema / properties / per_page / minimumPrevious value: -1New value: +2 - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "asOf", + "keyed", + "results", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `upstream_unavailable`: Federal Register returned a 5xx, timed out, or served an HTML error page. Other values are possible when a failure originates below the handler.", + "examples": [ + "upstream_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "asOf", - "keyed", - "results", - "totalCount" -]
- Changed
regulations_search_rules8 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / per_page / descriptionPrevious value: -"Results per page (1–100, default 20)."New value: +"Results per page (2–100, default 20). The Federal Register API treats exactly 1 as its default page size instead of returning one result." - changed
Input schema / properties / per_page / minimumPrevious value: -1New value: +2 - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "results", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `upstream_unavailable`: Federal Register returned a 5xx, timed out, or served an HTML error page. Other values are possible when a failure originates below the handler.", + "examples": [ + "upstream_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "results", - "totalCount" -]
1 tool update
- Changed
regulations_get_cfr_section1 field changed- changed
Output schema / properties / bodyText / descriptionPrevious value: -"Text of the section, part, or appendix, XML stripped to plain text. Paragraphs, subheadings, editorial notes, and tables (one pipe-delimited line per row) are kept in document order. Empty for a reserved appendix and for one whose whole content is a figure image."New value: +"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."
2 tool updates
- Changed
regulations_browse_cfr7 fields changed- added
Output schema / properties / nodes / items / properties / appendixAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "On an appendix node, the identifier to pass straight back as regulations_get_cfr_section's `appendix` input; null on every other node type. It is free-form prose, not a letter (\"Schedule I to Part 789\", \"Special Federal Aviation Regulation No. 88\"), so pass it verbatim rather than abbreviating it." +} - changed
Output schema / properties / nodes / items / properties / cfrCite / descriptionPrevious value: -"Assembled cite for a part/section → regulations_get_cfr_section; null otherwise."New value: +"Assembled cite → regulations_get_cfr_section: \"40 CFR 50\" / \"40 CFR 50.1\" for a part or section, \"Appendix A-1 to Part 50, Title 40\" for an appendix. Null on a level with no read path (chapter, subchapter, subpart, subject group)." - changed
Output schema / properties / nodes / items / requiredPrevious value: -[ - "type", - "identifier", - "label", - "description", - "reserved", - "cfrCite" -]New value: +[ + "type", + "identifier", + "label", + "description", + "reserved", + "cfrCite", + "appendix" +] - changed
Output schema / properties / results / items / descriptionPrevious value: -"One matching CFR section."New value: +"One matching CFR section or appendix." - added
Output schema / properties / results / items / properties / appendixAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "On an appendix hit, the identifier to pass straight back as regulations_get_cfr_section's `appendix` input; null on a section hit. Always null on a mirror hit — the index holds section text only, so mirror-sourced results never match an appendix." +} - changed
Output schema / properties / results / items / properties / cfrCite / descriptionPrevious value: -"Assembled cite → regulations_get_cfr_section."New value: +"Assembled cite → regulations_get_cfr_section. A section hit cites the section (\"40 CFR 51.190\"); an appendix hit cites the appendix in eCFR's own form (\"Appendix C to Part 58, Title 40\"), not the part around it, since the part's sections do not contain the matched text." - changed
Output schema / properties / results / items / requiredPrevious value: -[ - "title", - "part", - "section", - "heading", - "hierarchyPath", - "excerpt", - "cfrCite" -]New value: +[ + "title", + "part", + "section", + "appendix", + "heading", + "hierarchyPath", + "excerpt", + "cfrCite" +]
- Changed
regulations_get_cfr_section14 fields changed- added
Input schema / properties / appendixAdded value: +{ + "anyOf": [ + { + "const": "", + "type": "string" + }, + { + "description": "Appendix identifier (e.g. \"Appendix A-1 to Part 50\").", + "type": "string" + } + ], + "description": "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." +} - changed
Input schema / properties / part / descriptionPrevious value: -"CFR part within the title (e.g. \"50\"). Parts can be alphanumeric. Obtain from regulations_browse_cfr or a Federal Register document's cfrReferences."New value: +"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." - changed
Input schema / properties / section / descriptionPrevious value: -"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."New value: +"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." - changed
Input schema / requiredPrevious value: -[ - "title", - "part" -]New value: +[ + "title" +] - added
Output schema / properties / appendicesAdded value: +{ + "description": "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.", + "items": { + "additionalProperties": false, + "description": "One appendix in the part, named but not inlined.", + "properties": { + "appendix": { + "description": "Appendix identifier, for a follow-up read.", + "type": "string" + }, + "heading": { + "description": "Appendix heading.", + "type": "string" + } + }, + "required": [ + "appendix", + "heading" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / appendixAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Appendix identifier; null when a section or whole part was fetched." +} - changed
Output schema / properties / bodyText / descriptionPrevious value: -"Section text, XML stripped to plain text (paragraph structure preserved)."New value: +"Text of the section, part, or appendix, XML stripped to plain text. Paragraphs, subheadings, editorial notes, and tables (one pipe-delimited line per row) are kept in document order. Empty for a reserved appendix and for one whose whole content is a figure image." - changed
Output schema / properties / cfrCite / descriptionPrevious value: -"Assembled cite, e.g. \"40 CFR 50.1\"."New value: +"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`)." - changed
Output schema / properties / heading / descriptionPrevious value: -"Section/part heading."New value: +"Section, part, or appendix heading." - added
Output schema / properties / part / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - changed
Output schema / properties / part / descriptionPrevious value: -"CFR part."New value: +"CFR part; null only for an appendix that hangs off a chapter, subchapter, or subtitle rather than a part." - removed
Output schema / properties / part / typeRemoved value: -"string" - changed
Output schema / properties / section / descriptionPrevious value: -"Section identifier; null when a whole part was fetched."New value: +"Section identifier; null when a whole part or an appendix was fetched." - changed
Output schema / requiredPrevious value: -[ - "cfrCite", - "title", - "part", - "section", - "heading", - "hierarchyPath", - "date", - "source", - "bodyText" -]New value: +[ + "cfrCite", + "title", + "part", + "section", + "appendix", + "heading", + "hierarchyPath", + "date", + "source", + "bodyText" +]
2 tool updates
- Changed
regulations_browse_cfr3 fields changed- changed
Input schema / properties / part / descriptionPrevious value: -"CFR part within the title (structure mode, optional) — narrows the returned tree to one part's sections. Parts can be alphanumeric."New value: +"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\"." - changed
Output schema / properties / results / items / properties / hierarchyPath / descriptionPrevious value: -"Structural path down to the match, e.g. \"Title 40 › Chapter I › Part 51 › § 51.190\"."New value: +"Path down to the match. A live hit names the part it sits in — \"Title 40 › Chapter I › Subchapter C › Part 51 — Requirements for Preparation, Adoption, and Submittal of Implementation Plans › § 51.190\" — so the subject matter is readable without a second call. A mirror hit is structural only (\"Title 14 › Part 25 › § 25.1043\"): the index stores no level names. Check `source` before comparing paths across results." - changed
Output schema / properties / sourceScope / descriptionPrevious value: -"What the answering corpus covers — the mirror's title coverage, or the live index and the date it was read at (search mode). Read it before concluding a query found nothing."New value: +"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."
- Changed
regulations_find_comments4 fields changed- changed
Input schema / properties / comment_id / descriptionPrevious value: -"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."New value: +"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." - changed
Input schema / properties / docket_id / descriptionPrevious value: -"Fetch all comments in a docket by docket ID (e.g. \"EPA-HQ-OAR-2025-0194\"). Broadest scope. One of docket_id / document_object_id / fr_document_number / comment_id is required."New value: +"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." - changed
Input schema / properties / document_object_id / descriptionPrevious value: -"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."New value: +"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." - changed
Input schema / properties / fr_document_number / descriptionPrevious value: -"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."New value: +"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."
1 tool update
- Changed
regulations_browse_cfr8 fields changed- changed
Input schema / properties / date / descriptionPrevious value: -"Point-in-time date, ISO 8601 (YYYY-MM-DD). Defaults to current. Structure mode uses this date for historical hierarchy; in search mode, a past date enables point-in-time search."New value: +"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." - changed
Input schema / properties / title / descriptionPrevious value: -"CFR title number (1–50). Structure mode: omit to list all 50 titles, or provide to expand one title. Search mode: optional filter to restrict to one title."New value: +"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." - changed
Output schema / properties / date / descriptionPrevious value: -"Resolved point-in-time date (structure mode)."New value: +"Resolved point-in-time date — the hierarchy snapshot (structure mode), or the day whose section text was searched (search mode, live source only)." - changed
Output schema / properties / results / items / properties / heading / descriptionPrevious value: -"Section/part heading."New value: +"What the matched node is called — the section, appendix, or part heading. Distinct from cfrCite, which is where it lives." - changed
Output schema / properties / results / items / properties / hierarchyPath / descriptionPrevious value: -"Human-readable hierarchy path."New value: +"Structural path down to the match, e.g. \"Title 40 › Chapter I › Part 51 › § 51.190\"." - changed
Output schema / properties / results / items / properties / section / descriptionPrevious value: -"Section identifier, or null."New value: +"Section identifier, or null when the match is an appendix or a whole part." - changed
Output schema / properties / source / descriptionPrevious value: -"Provenance: the synced mirror index, or the live eCFR search fallback (search mode)."New value: +"Provenance: the synced mirror index, or the live eCFR search API (search mode)." - added
Output schema / properties / sourceScopeAdded value: +{ + "description": "What the answering corpus covers — the mirror's title coverage, or the live index and the date it was read at (search mode). Read it before concluding a query found nothing.", + "type": "string" +}
7 tool updates
- First observed
regulations_browse_cfr - First observed
regulations_find_comments - First observed
regulations_get_cfr_section - First observed
regulations_get_docket - First observed
regulations_get_document - First observed
regulations_list_open_comments - First observed
regulations_search_rules
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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 Connectors
Source-linked US federal regulations: CFR provision history, obligations, rules, comments.
US Federal Register for AI agents: rules, notices, executive orders, agency lookup. No keys.
51US Federal Register for AI agents: rules, notices, executive orders, agency lookup. No keys.
Federal Register monitoring and regulations.gov tracking. 4 MCP tools for regulatory compliance.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to search and track US federal regulations, documents, and executive orders from the Federal Register, with no API keys required.MIT
- AlicenseNot gradedqualityNot gradedmaintenanceEnables 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.-
- AlicenseAqualityAmaintenanceEnables AI assistants to retrieve, search, and track changes to US Code of Federal Regulations sections via the eCFR API, returning actual regulation text with citations and point-in-time date support.71MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.5/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: browsing vs searching, getting specific entities (CFR sections, dockets, documents) vs listing/finding comments. No overlap or ambiguity.
Naming Consistency5/5
All tools follow the consistent 'regulations_<verb>_<object>' pattern (e.g., browse_cfr, get_docket, list_open_comments), making it easy to predict functionality.
Tool Count5/5
Seven tools is well-scoped for a regulations domain, covering discovery (search, browse, list) and retrieval (get, find) without redundancy or bloat.
Completeness5/5
The set covers the core regulatory workflow: searching rules, browsing CFR structure, retrieving specific sections, dockets, documents, and comments. No obvious gaps for read-only access.