Federal Register
Server Details
Federal Register proposed and final rules, notices, executive orders, and FAR cases. 8 tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- 1102tools-dev/federal-contracting-mcps
- GitHub Stars
- 25
- Server Listing
- ecfr-mcp
TDQS
Score is being calculated.
Available Tools
8 toolsfar_case_historyRead-onlyInspect
Get all Federal Register documents for a FAR/DFARS case or FAC.
Pass a docket ID like 'FAR Case 2023-008' (or a FAC number like
'FAC 2025-06'). Runs BOTH a docket-id search and a quoted full-text
search, then merges the two result sets (deduped by document number)
in chronological order to show the full rulemaking progression:
ANPRM -> proposed rule -> final rule -> corrections. The dual query
matters: FAC introduction and companion documents often carry only
internal docket numbers, so a docket-only search returns a partial set.
Docket matching is token-based, not substring: 'FAR Case 2023' matches
all 2023 cases (token '2023' matches '2023-008'), but a partial token
like 'FAR Case 20' matches nothing. Be specific to avoid false positives.
Each document carries matched_by: 'docket' or 'docket+text' when its
docket ids name the case, 'text' when it only mentions the case in its
text (regulatory agendas, related or companion cases, FAC
introductions, public meetings). Read 'text' matches with care.
Each underlying search returns at most 100 documents. truncated=True
flags that one of the searches hit that cap (docket_matches and
term_matches carry the API's full counts); narrow the docket_id if so.
Minimum docket_id length is 3 characters to prevent token matches that
return unrelated documents (e.g. 'x' matched 65 random dockets in 0.1.x).
| Name | Required | Description | Default |
|---|---|---|---|
| docket_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
get_documentRead-onlyInspect
Get full details for a single Federal Register document by number.
Returns all available fields including full text URLs, docket info, RIN details, page views, topics, corrections, and CFR references.
Document numbers look like '2026-03065' (modern), 'E9-12940' or 'X94-70302' (legacy pre-2011 archive), or 'C1-2026-01234' (corrections).
| Name | Required | Description | Default |
|---|---|---|---|
| document_number | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
get_documents_batchRead-onlyInspect
Fetch multiple documents in one call (up to ~20).
Pass a list of document numbers. More efficient than individual calls.
Always returns {count, results, [errors]}; errors.not_found lists any
requested numbers the API could not locate. Results come back in the
order requested. Image metadata (images, images_metadata) is left out
to keep batches small; get_document returns it.
| Name | Required | Description | Default |
|---|---|---|---|
| document_numbers | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
get_facet_countsARead-onlyInspect
Get document counts grouped by type, agency, topic, or time period.
Accepts the same filter conditions as search_documents. Returns
aggregated counts without individual document results.
Facets: type, agency, topic (categorical) plus daily, weekly, monthly,
quarterly, yearly (publication-date buckets, useful for trend lines).
Useful for understanding the volume of rulemaking by agency, type, or
over time within a date range before drilling into specific documents.
presidential_document_type (executive_order, proclamation, memorandum,
determination, notice, presidential_order, other) narrows to one kind
of presidential document, e.g. executive orders per month.
At least one filter (agencies, doc_types, term, pub_date_gte/lte, or
cfr_title) is required. An unfiltered facet query returns the entire
all-time aggregate.
FAR Council counts: facets cannot express "filed by DoD AND GSA AND
NASA", and no single agency slug covers FAR documents (OFPP only from
about mid-2025; 'federal-acquisition-regulation-system' holds 2 documents
ever). Count FAR rules with search_documents(far_council=True,
doc_types=[...], pub_date_gte/lte=...) and read its count.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | ||
| facet | Yes | ||
| agencies | No | ||
| cfr_part | No | ||
| cfr_title | No | ||
| doc_types | No | ||
| pub_date_gte | No | ||
| pub_date_lte | No | ||
| presidential_document_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the basic safety hints (readOnlyHint: true). It specifies the nature of the returned data (aggregated counts vs. individual results), explains the functional difference between the various date buckets (e.g., 'useful for trend lines'), and warns about complex operational constraints like the FAR Council filtering limitations.
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 information is logically structured, moving from general purpose to specific usage rules and then to detailed constraints. However, its considerable length means some details are dense, making a perfect score challenging, though highly efficient overall.
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?
The definition is exceptionally complete. It outlines the required input filters, details the possible aggregation dimensions (facets), explains the output format (counts only), and provides critical system-level constraints (FAR Council limitations), leaving no ambiguity for the agent.
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 0% schema description coverage, the description must compensate fully. It excellently explains the functional meaning of the `facet` enum options (e.g., daily, weekly, monthly for trend lines) and defines complex parameter groups, such as the constraints surrounding `presidential_document_type` and the FAR Council limitations.
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 purpose: 'Get document counts grouped by type, agency, topic, or time period.' It immediately distinguishes itself by stating it 'Returns aggregated counts without individual document results,' differentiating it from tools like search_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?
The description provides explicit guidance on when to use the tool ('Useful for understanding the volume... before drilling into specific documents') and defines critical mandatory behavior ('At least one filter... is required. An unfiltered facet query returns the entire all-time aggregate').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_public_inspectionRead-onlyInspect
Get current public inspection documents (pre-publication).
Public inspection documents are FR documents filed for publication but
not yet published. Updated business days only.
The current-PI endpoint does NOT support server-side filtering. This
tool fetches all current PI documents and filters client-side by
agency and/or keyword in the title.
Useful for getting early notice of upcoming regulatory actions.
Parameters:
- agency_filter: case-insensitive substring match against agency slugs,
names, and short names. Sub-agencies are included: PI documents list
only the FILING sub-agency, so the filter is also matched against the
Federal Register agency list and every agency below a matching one
counts ('defense-department' or 'DOD' also returns Army, Navy, Air
Force, Corps of Engineers and Defense Logistics Agency filings).
filters_applied.includes_sub_agencies says whether that worked.
- keyword_filter: substring match against document titles
- limit: max documents returned after filtering (default 50, max 500).
Unfiltered dumps can exceed 170KB; narrow with filters or raise the cap.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| agency_filter | No | ||
| keyword_filter | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
list_agenciesARead-onlyInspect
List agencies with their IDs, names, slugs, and parent agencies.
Use the 'slug' values with search_documents() and other tools.
Common procurement slugs:
- defense-department (DoD)
- general-services-administration (GSA)
- national-aeronautics-and-space-administration (NASA)
- defense-acquisition-regulations-system (DARS/DFARS)
- federal-procurement-policy-office (OFPP and the CAS Board)
- small-business-administration (SBA)
- veterans-affairs-department (VA)
The FAR has no single slug. FAR rules and notices are filed jointly
under DoD, GSA and NASA; OFPP was added only from about mid-2025, so
the OFPP slug misses earlier FAR rules. The agency named 'Federal
Acquisition Regulation System' (federal-acquisition-regulation-system)
holds 2 documents ever; it carries a note in these results. For FAR
documents use search_documents(far_council=True) or
open_comment_periods(far_council=True).
Parameters:
- query: optional case-insensitive substring match against name, short_name,
and slug. Recommended: narrow results before pulling full detail.
- include_detail: if False (default), returns only id/name/short_name/slug/parent_id.
If True, returns all fields (description, urls, etc.). The full dump is ~700KB.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| include_detail | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only hint in annotations, the description provides critical behavioral details, such as the operational impact of `include_detail=True` ('The full dump is ~700KB') and essential data caveats (FAR slug issues, OFPP timeline).
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 detailed, which is necessary given the complexity and zero schema coverage. While lengthy, the information provided is highly valuable and non-redundant, justifying its size.
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?
The definition is exceptionally complete. It covers what the tool does, how to filter it, the operational costs (data dump size), and provides crucial domain knowledge (slug limitations) that ensures the agent makes an informed decision.
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?
Since schema coverage is 0%, the description must provide all meaning. It clearly explains the function, case-insensitivity, and recommendation for the 'query' parameter, and thoroughly details the data scope and size implications of 'include_detail'.
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's function: 'List agencies with their IDs, names, slugs, and parent agencies.' It clearly distinguishes itself from siblings by being an entity listing tool, not a document search tool.
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?
It provides explicit guidelines on when to use the returned data, stating, 'Use the 'slug' values with search_documents() and other tools.' Furthermore, it tells the agent when to use specific siblings for FAR-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_comment_periodsRead-onlyInspect
Find source-reported open comment periods, soonest indexed deadline first.
Covers proposed rules, notices, AND final/interim rules that accept
comments (dozens of RULE-type documents have open periods at any time).
Queries for comment close date >= today, scans up to 500 matching
documents oldest-published first (where the soonest deadlines live),
sorts by close date, and returns the first `limit`.
Source scope: total_open is the API's matching metadata count;
scanned is how many this call examined. When total_open exceeds
scanned, narrow with agencies/term for complete indexed coverage. A very
recently published document with an unusually short comment window
can fall outside the scan in that oversubscribed case.
complete means the matching indexed records were scanned, not that every
currently open opportunity or controlling deadline was verified. The API's
comments_close_on metadata can disagree with DATES after an extension or
reopening. Even a zero result needs docket/subject search_documents and
get_document DATES/linked publication checks before ruling out comments.
Default: searches all agencies. Pass agency slugs to narrow scope,
e.g. ['defense-acquisition-regulations-system'] for DFARS or
['general-services-administration'] for GSA and GSAR.
Parameters:
- far_council: True for open FAR proposed rules and FAR information
collections (documents filed jointly by DoD, GSA and NASA; there is no
single FAR agency slug and the OFPP tag only appears from about
mid-2025). Cannot be combined with agencies.
- limit: max documents returned after sorting (default 50, max 100).
Unfiltered dumps across all agencies can approach 200KB; several
broad agencies together (e.g. DoD + GSA) can pass 100KB, so lower
limit for those.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | ||
| limit | No | ||
| agencies | No | ||
| far_council | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
search_documentsRead-onlyInspect
Search Federal Register documents.
The primary tool for finding proposed rules, final rules, notices,
and presidential documents published in the Federal Register since 1994.
Key parameters:
- agencies: list of agency URL slugs (OR logic). Use list_agencies() to find slugs.
Common: 'defense-department', 'general-services-administration',
'small-business-administration', 'defense-acquisition-regulations-system'
(DFARS), 'federal-procurement-policy-office' (OFPP and the CAS Board)
- far_council: True for FAR rules, proposed rules and notices (the FAR
Council's output). There is no single FAR agency slug: FAR documents
are filed jointly under DoD, GSA and NASA, OFPP was added only from
about mid-2025 (so the OFPP slug misses earlier FAR rules and adds CAS
Board documents), and 'federal-acquisition-regulation-system' holds 2
documents ever. far_council=True keeps documents filed by all three of
DoD, GSA and NASA; count is exact when far_council.complete is true
(narrow by date if not). Cannot be combined with agencies. For FAR
clause changes only, cfr_title=48 + cfr_part='1-99' also works.
- doc_types: PRORULE (proposed rule), RULE (final rule), NOTICE, PRESDOCU
- term: full-text keyword search (strips stop words)
- docket_id: docket identifier (token match). 'FAR Case 2023-008' = exact,
'FAR Case 2023' = all 2023 cases; partial tokens like 'FAR Case 20'
match nothing
- regulation_id_number: RIN (precise match, e.g., '9000-AO56')
- pub_date_gte/lte: publication date range (YYYY-MM-DD)
- comment_date_gte/lte: comment close date range
- effective_date_gte/lte: effective date range
- correction: True finds only the Office of the Federal Register's own
correction notices (C1- prefix documents). Agency-issued corrections
('Final rule; correction.', 'Correcting amendment.') are ordinary RULE
documents and are not flagged: search doc_types=['RULE'] with
term='correction' and check each document's action.
- significant: True for EO 12866 significant rules only
- cfr_title + cfr_part: documents affecting a CFR location, e.g.
cfr_title=48, cfr_part='52' for FAR part 52 (part accepts ranges
like '1-99'; cfr_part requires cfr_title)
- presidential_document_type: executive_order, proclamation, memorandum,
determination, notice, presidential_order, other. Use
['executive_order'] to count or list executive orders: doc_types=
['PRESDOCU'] alone also returns proclamations, memoranda and notices.
- executive_order_number: one EO by number (e.g. 14275)
- order: 'executive_order_number' sorts EOs by number (pair it with
presidential_document_type=['executive_order'])
Presidential documents carry executive_order_number, subtype (Executive
Order, Proclamation, Memorandum, ...), signing_date and
presidential_document_number; other documents omit those keys.
Count caps at 10,000 for broad queries (count_capped=true says so); use
get_facet_counts for the true number, or narrower date ranges.
per_page capped at 100 to stay within MCP response size limits.
Paging: the Federal Register serves only pages 1-50 of any search (a
later page silently comes back as page 1), so page > 50 is refused.
total_pages is the true page count; when it passes 50,
max_reachable_page and paging_note say how to reach the rest (per_page=100
reaches 5,000 documents; split the publication date range beyond that).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| term | No | ||
| order | No | newest | |
| agencies | No | ||
| cfr_part | No | ||
| per_page | No | ||
| cfr_title | No | ||
| doc_types | No | ||
| docket_id | No | ||
| correction | No | ||
| far_council | No | ||
| significant | No | ||
| pub_date_gte | No | ||
| pub_date_lte | No | ||
| comment_date_gte | No | ||
| comment_date_lte | No | ||
| effective_date_gte | No | ||
| effective_date_lte | No | ||
| regulation_id_number | No | ||
| executive_order_number | No | ||
| presidential_document_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
8 tool updates
- First observed
far_case_history - First observed
get_document - First observed
get_documents_batch - First observed
get_facet_counts - First observed
get_public_inspection - First observed
list_agencies - First observed
open_comment_periods - First observed
search_documents
Related MCP Connectors
Federal regulatory intelligence from the Federal Register: search rules and notices, track deadlines
Electronic Code of Federal Regulations including FAR, DFARS, and agency supplements. 13 tools.
13125Federal Register monitoring and regulations.gov tracking. 4 MCP tools for regulatory compliance.
Regulations.gov readiness, rulemaking dockets, documents, comments, and comment periods. 9 tools.
9125
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables AI agents to search and track US federal regulations, documents, and executive orders from the Federal Register, with no API keys required.5MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to search and retrieve executive orders, presidential documents, rules, and agency information from the Federal Register API through natural language queries.125 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables querying the US Federal Register API for federal register documents and data through natural language.152 npmMIT
- FlicenseNot gradedqualityDmaintenanceFederal procurement intelligence toolkit that searches SAM.gov contract opportunities, analyzes agency spending patterns, tracks competitor wins, and monitors small business set-aside programs (8a, HUBZone, SDVOSB, WOSB). 4 tools using SAM.gov and USASpending.gov data.3-
Glama MCP Gateway
Add one secure layer between your agents and this server.