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
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.6/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: browsing CFR hierarchy, fetching section text, finding comments, retrieving dockets, getting document metadata, listing open comments, and searching rules. No two tools overlap in functionality.
All tools follow a consistent 'regulations_' prefix followed by a verb_noun pattern (e.g., browse_cfr, find_comments, get_cfr_section). The naming convention is uniform and predictable across the entire set.
With 7 tools, the server is well-scoped for its purpose of accessing federal regulations. Each tool addresses a core operation without being excessive or insufficient.
The tool set covers the entire lifecycle of regulatory exploration: searching and browsing rules, retrieving documents and dockets, fetching comments, and reading codified text. There are no obvious gaps for a read-only regulations 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 feed regulations_get_cfr_section. The source (mirror or live) is reported on each search result.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 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. | |
| 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 (structure mode, optional) — narrows the returned tree to one part's sections. Parts can be alphanumeric. | |
| 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 to restrict to one title. | |
| per_page | No | Results per page in search mode (1–50, default 20). Ignored in structure mode. |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | No | Resolved point-in-time date (structure mode). |
| 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 fallback (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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so description correctly implies no destructive behavior. It adds that the source (mirror or live) is reported per search result, and explains date behavior per mode. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences well-structured: first introduces modes, then details each mode, then links to sibling tool, then notes source reporting. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 100% schema coverage, and an output schema existing, the description adequately covers mode behavior, parameter applicability, and tool chaining. The output schema handles return values, so no need to detail them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning beyond schema: explains mode-parameter interactions (e.g., query required in search, title optional in both modes, part narrows tree, per_page ignored in structure). The date parameter's dual role is also clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explores the Code of Federal Regulations in two modes: 'structure' (browse hierarchy) and 'search' (full-text query). It distinguishes from siblings by mentioning it feeds into regulations_get_cfr_section, providing a clear verb-resource-mode combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode: structure for discovering a cite when unknown, search for full-text query. It also explicitly says both modes feed regulations_get_cfr_section, guiding the agent to the next step. However, it lacks explicit when-not-to-use or comparison with sibling search tools like regulations_search_rules.
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/).
| 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. One of docket_id / document_object_id / fr_document_number / comment_id is required. | |
| 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. | |
| 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. | |
| 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. |
Output 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses that the list endpoint returns no body text or attachment info, that comment_id is needed for full detail, and that attachment-only comments have a stub body and attachmentOnly flag. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the main purpose front-loaded. It is slightly lengthy but each sentence adds necessary guidance. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, multiple targeting options), the description covers all necessary aspects: parameter selection, limitations (page cap, no body in list), and output behavior (attachment details). Output schema exists, so return value explanation is not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions). The description adds value by explaining the difference between the four targeting parameters, the page cap (20 pages, 5,000 records), and the minimum page size (5). This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch public comments on a Federal Register document or a Regulations.gov docket', using specific verbs and resource. It distinguishes from siblings like regulations_list_open_comments by mentioning the unique corpus of submitted comments and the targeting parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 explains the scope of each (docket_id broadest, comment_id for detail). It warns about high-volume dockets and suggests narrowing. It does not explicitly list alternatives but provides clear context for when to use each parameter.
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 of a specific CFR section (or a whole part) via eCFR — current or as of a past date. Answers "what does 40 CFR 50.1 say today?" and "...as of 2019-01-01?". Provide title + part + section for one section, or omit section to fetch the whole part (large parts can be very long; prefer a specific section when you know 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.
| 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 | Yes | CFR part within the title (e.g. "50"). Parts can be alphanumeric. 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | The issue/point-in-time date the text reflects (ISO 8601). |
| part | Yes | CFR part. |
| title | Yes | CFR title number. |
| source | Yes | Provenance: the synced mirror, or the live eCFR API. |
| cfrCite | Yes | Assembled cite, e.g. "40 CFR 50.1". |
| heading | Yes | Section/part heading. |
| section | Yes | Section identifier; null when a whole part was fetched. |
| bodyText | Yes | Section text, XML stripped to plain text (paragraph structure preserved). |
| sections | No | Present only when a whole part was fetched — each section in the part. |
| hierarchyPath | Yes | Human-readable hierarchy path. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral context beyond annotations: discloses caching via local mirror for current single-section reads, reports data source, and explains date rejection behavior. Annotations already indicate read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise, well-structured sentences. Front-loaded with purpose, followed by essential usage details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, behavior, constraints, and data source. Output schema exists to document return values, so the description is appropriately 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3, but the description adds significant value: explains date format, provides examples, warns about large parts when omitting section, and references regulations_browse_cfr for part numbers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads codified text of a specific CFR section or whole part via eCFR, with current or past date options. It distinguishes from siblings like regulations_browse_cfr by noting where to obtain parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: when to use (reading sections/parts), date range coverage, and preference for specific sections over whole parts. Doesn't explicitly list exclusions but gives practical 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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses API key requirement, pagination limits (20 pages, 5,000 records), and minimum page size (5), all beyond what annotations (readOnlyHint, idempotentHint) provide. Helps the agent understand constraints and necessary setup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise at ~150 words, front-loaded with the core action. Some redundancy ('the docket is the folder holding a rule's whole paper trail') but overall efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive: explains what the tool returns, how to use it, API requirements, pagination constraints, and links to related tools. Output schema exists, so return values are not needed in description. Covers all essential aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds no significant new parameter semantics beyond the schema, but the overall context (e.g., filtering recommendation) is useful for usage, not parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Pull a rulemaking docket by docket ID') and resource ('docket metadata and documents'), and implicitly distinguishes from siblings like regulations_get_document by emphasizing the docket as a folder containing multiple documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on use case (getting a docket's full paper trail) and practical tips (filter document_types to find rule documents). Could explicitly contrast with siblings like regulations_get_document or regulations_search_rules.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint and idempotentHint to true, so the system knows it's a safe read operation. The description adds valuable context: it discloses that the output contains cross-source handles and chaining keys, and warns about large full-text payload. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each dense with information. The first sentence front-loads the core action and content; the second provides critical parameter guidance. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately focuses on input purpose, parameter semantics, and chaining hints. It covers all essential aspects for a read-only tool with two well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description adds rich semantics: it gives a pattern example and source for document_number, and explains the trade-off of include_full_text with a size warning and usage criterion. This significantly aids the agent in parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is highly specific: 'Fetch one Federal Register document by its FR document number' – a clear verb+resource pair. It lists the metadata fields and explicitly names sibling tools for chaining, differentiating it from other tools in the family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to set include_full_text ('only when the rule body itself is needed') and warns about size. It also hints at chaining workflows, though it doesn't explicitly state when not to use this tool over others.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it uses the Federal Register's open-comment window, works without a key, and is enriched with comment count when key is configured (no extra rate-limited call). No contradiction with readOnlyHint/openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, then usage details, and alternative tool references. Slightly verbose but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use case, configuration behavior, and next steps. Output schema exists, so return values are documented. Could mention pagination limit but schema already covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline 3. Description adds value by stating default sort order (by closing date, soonest first) and clarifying filtering by agency slug and topic, though 'topic' may map to query parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists rules open for comment, with filtering by agency and topic, sorted by closing date. It distinguishes itself by mentioning related tools (regulations_get_document, regulations_find_comments) for different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to find rules to weigh in on) and when to use alternatives (regulations_get_document for full proposal, regulations_find_comments for comments). Also notes it works without an API key.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral context: pagination caps (50 pages, 10,000 results), that results include document numbers, docket IDs, RINs, and CFR parts, and that it chains into other tools. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph that front-loads the main purpose, then adds key details about data range, results, and pagination limits. Every sentence adds value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, an output schema, and relationships to 6 sibling tools), the description covers its functionality, limitations, and integration points comprehensively. Annotations provide safety profile, and the description adds missing context about pagination and result fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter's description in the schema is detailed (e.g., page cap, type enum, agencies slug advice, date filter strategy). The tool description reinforces the pagination strategy, but overall the parameter semantics are already well-covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as searching the Federal Register, specifies the resource (proposed rules, final rules, etc.), and distinguishes it from sibling tools by calling it the primary discovery entry point. The title and name are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool (primary discovery entry point) and how to handle pagination limits (narrow with date filters instead of paging). However, it does not explicitly state when NOT to use it, such as when a specific document number is already known.
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!