Skip to main content
Glama

search_cfr

Read-only

Full-text search across the Code of Federal Regulations.

Returns matching sections with excerpts, headings, scores, and hierarchy.

current_only=True (default) returns only text in effect now. eCFR's own
"current" index still lists some superseded and removed versions, so
each hit is checked against the section's version history: older
copies of a section are dropped, and hits whose text has since been
replaced or removed are dropped and listed under current_check
('superseded' with the current version's date, 'removed' with the
removal date). Up to 10 parts per page are checked; any hit not
checked is marked. current_only=False returns every historical
version, so a section amended 5 times appears 5 times.

Search caps at 10,000 total results. Use hierarchy filters (title,
chapter, part) to narrow if you hit the cap. chapter/part/subpart/section
filters need a title; without one, title 48 is assumed (title_assumed
says so). Labels like 'FAR Part 15', 'Subpart 15.3' or '§ 52.212-5' are
read as 15, 15.3 and 52.212-5. Most titles other than 48 number chapters
in Roman numerals (2 CFR chapter 'II').

order controls result ordering: 'relevance' (default), 'newest_first',
'oldest_first', 'hierarchy', or 'citations'.

agency_slugs filters to one or more agencies (single slug string or a
list, e.g. 'defense-acquisition-regulations-system'). Use list_agencies()
to find slugs.

last_modified_after/before use YYYY-MM-DD format and filter by the
date sections were last amended. Useful for finding recent regulatory changes.

per_page accepts 1 to 5000 (default 20); paginate with page for more.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_cfr"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo
partNo
orderNo
queryYes
titleNo
chapterNo
sectionNo
subpartNo
per_pageNo
agency_slugsNo
current_onlyNo
last_modified_afterNo
last_modified_beforeNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the read-only annotations: explains the current_only version-history check, how superseded/removed hits are dropped and reported under current_check, the 10-part-per-page check limit and marking of unchecked hits, the 10,000-result cap, and the implicit title-48 assumption. This is exactly the behavioral context an agent needs to interpret results correctly.

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?

Front-loads the core purpose and return shape, then groups guidance logically by parameter. It is long, but the length is justified by 13 parameters and no schema descriptions; a few sentences could still be tightened without losing meaning.

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?

Covers result caps, pagination, filtering prerequisites, default assumptions, and historical-version behavior. With an output schema and read-only annotations already present, the description adds the remaining context an agent needs to invoke and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the full burden and does: current_only semantics, order enum values, agency_slugs format and helper, YYYY-MM-DD for date filters, per_page range and default, hierarchy filter prerequisites, and label parsing rules like 'FAR Part 15' and Roman-numeral chapters. Only 'query' and 'page' are left implicit, which is acceptable.

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 specific verb and resource ('Full-text search across the Code of Federal Regulations') and immediately says what comes back (matching sections with excerpts, headings, scores, hierarchy). It is clearly distinguishable from siblings like get_cfr_content or lookup_far_clause because it describes full-text retrieval rather than direct lookup.

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?

Gives practical when-to-use guidance: current_only=True vs False for historical versions, hierarchy filters when hitting the 10,000-result cap, last_modified filters for recent changes, and list_agencies() for slug discovery. It does not explicitly name sibling alternatives for definition lookup or section retrieval, so a 4 rather than 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.