cfr-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.2
Disambiguation5/5
Each tool occupies a distinct niche: search returns snippets, where_does_term_appear gives only hit counts, lookup_citation retrieves full text, browse_structure shows hierarchy, what_changed lists dates, compare_versions shows diffs, and list_agencies maps agencies to titles. The descriptions explicitly cross-reference each other to guide the correct choice.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (lookup_citation, search_regulations, browse_structure, compare_versions, list_agencies), but two tools use interrogative phrases (where_does_term_appear, what_changed). This is a minor deviation that remains readable and predictable, but it is not perfectly uniform.
Tool Count5/5
Seven tools is well within the ideal range for a focused legal-research server. Each tool serves a distinct and necessary function for navigating, searching, and analyzing the CFR without redundancy or bloat.
Completeness5/5
The tool set covers the full research workflow: orientation (list_agencies, where_does_term_appear), discovery (search_regulations, browse_structure), retrieval (lookup_citation), and historical analysis (what_changed, compare_versions). There are no obvious dead ends; each tool refers to others for follow-up, creating a coherent end-to-end experience.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It usefully discloses that the tool returns only hierarchy and no text, but it does not explain behavior around the optional date parameter, what happens when part is omitted, or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the action and resource, and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but with no annotations and no parameter descriptions, the description should provide more context about the date parameter and intended usage. It is minimally viable but has clear gaps.
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?
Schema description coverage is 0%, and the description only implicitly covers 'title' and 'part'. The 'date' parameter is completely undocumented in both the schema and the description, so the description only partially compensates for the lack of parameter documentation.
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 uses a specific verb ('Return'), names the resource ('CFR hierarchy'), and states the input scope ('for a title (or one part)') and output scope ('without any text'). This clearly differentiates the tool from siblings like search_regulations and lookup_citation, which imply text-oriented operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the core use case—browsing the CFR hierarchy without content—and implies when it is appropriate. However, it does not explicitly mention alternatives or state when not to use this tool, leaving usage largely to inference from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It meaningfully discloses a non-obvious behavior: large parts return an outline instead of full text, and it gives a follow-up strategy. It could add more about truncation or formatting, but the output schema covers return 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 compact sentences, each carrying necessary information: the core purpose and the important part-vs-section behavioral caveat. No filler or redundant restatement.
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 main retrieval behavior and the key edge case of large parts. The main gaps are the lack of sibling routing and the unexplained max_chars parameter, but the schema provides good examples and the output schema exists.
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?
The description adds no parameter-level meaning beyond the schema. The citation and date parameters are already well described in the schema, but max_chars has no description there and the tool description does not clarify it either. At 67% schema coverage, the description should have compensated for this gap.
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 states a clear action and resource: 'Retrieve the text of a specific CFR citation.' The added note about large parts returning outlines helps clarify scope, though it does not explicitly distinguish this tool from siblings like search_regulations or browse_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: for a specific section citation, and as a follow-up after a part-level outline. However, it does not explicitly mention alternatives or state when not to use this tool versus the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses an important trait: 'fetches no regulation text at all' and calls itself a 'cheap orientation tool.' However, it leaves out how the date parameter affects behavior, result limits, or edge cases, so it is informative but not comprehensive.
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 two tightly written sentences: the first states the purpose and output, the second gives the use case and a key behavioral trait. Every sentence earns its place and the key information is front-loaded.
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?
For a simple two-parameter orientation tool, the description covers purpose, output shape, when to use it, and a key behavioral constraint. An output schema exists for return details. The main missing pieces are the date parameter semantics and explicit sibling routing, but these are minor relative to the overall clarity.
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?
Schema description coverage is 0%, so the description must compensate for both parameters. It gives meaning to query by calling it a 'term' and by describing the output as containing titles/chapters/parts with hit counts, but the optional date parameter is never explained. This is a significant gap in parameter understanding.
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 action and resource: 'Show which titles/chapters/parts contain a term, with hit counts.' It also frames the tool as a cheap orientation step before searching, which distinguishes it from search-oriented siblings like search_regulations.
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 a clear decision rule: 'Use this before searching when you don't know which part of the CFR governs a topic.' It does not explicitly name alternative tools or state when not to use it, but the intended context is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the output type (agencies and CFR titles/chapters) and hints at the intended lookup flow, but it does not document filter matching behavior, default output when filter is null, or other edge cases.
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 concise sentences with no filler. The core function is stated first, followed by a concrete usage example. Every sentence adds value.
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 tool is simple: one optional parameter, an output schema is present, and the description gives both the purpose and intended usage. It is nearly complete, with only minor missing details about filter semantics.
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?
Schema description coverage is 0%, so the description must compensate. It implies the filter parameter is an agency name such as 'EPA' used to find the right CFR title, but it does not explicitly define how matching works or what null does.
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 uses a specific verb and resource: 'List federal agencies and the CFR titles/chapters they administer.' It states exactly what the tool returns and makes the tool distinguishable from siblings like search_regulations or browse_structure, which perform different tasks.
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 second sentence provides a concrete use case and sequencing: 'Use this to turn a name like EPA into the right CRT title before searching.' This clearly signals when to use the tool, though it does not explicitly describe when not to use it or name an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly discloses a key limitation: results are only citations, headings, and short snippets, and never full text. It does not explain filtering semantics or rate limits, but the most important behavioral trait is stated directly.
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 two tight sentences with no filler. It front-loads the core purpose, immediately states the output limitation, and gives a concise actionable follow-up.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for launching a search and understanding the snippet-only limitation, and an output schema exists to document return values. However, it does not explain the optional filters (date, title, agency), default limit behavior, or how it differs from the sibling where_does_term_appear, leaving some room for agent confusion.
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?
The description adds no parameter-specific guidance. Schema description coverage is only 40%, covering title and agency, while query, date, and limit are essentially undocumented. The tool name implies query is the search term, but date format, limit behavior, and filter interactions are left unexplained.
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 identifies a precise verb ('Full-text search'), a clear resource ('the CFR'), and the scope ('across the CFR'). It differentiates the tool from sibling lookup_citation by explicitly stating that it returns only citations, headings, and snippets, not full text.
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 explicitly tells the agent to follow up with lookup_citation to read full text, which clarifies when to use this tool versus that sibling. However, it does not address alternatives like where_does_term_appear or specify when to use them instead, so the guidance is incomplete across all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It does well by disclosing that output includes amendment dates, corrections, cross-links to Federal Register rules, and URLs explaining the 'why.' It stops short of describing edge cases such as how 'since' changes results or what happens when no amendments exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The main function is front-loaded, the cross-link context is useful, and the compare_versions follow-up is a helpful closing action. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives solid context about output and workflow, and the presence of an output schema reduces the need to explain return structure. However, the tool is not fully self-sufficient because the optional 'since' parameter's semantics are left unclear and 'citation' input format is not addressed.
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?
Schema coverage is only 50%: 'citation' has no schema description and 'since' only has 'YYYY-MM-DD' without explaining what it filters. The tool description does not compensate; it only uses the word 'citation' generically and never explains the optional 'since' parameter, leaving an agent to guess its intended effect.
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 'List amendment dates for a citation, plus any published corrections,' giving a specific verb, resource, and scope. It also distinguishes itself from compare_versions by explicitly positioning that sibling as the follow-up for seeing text changes.
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 clearly tells the agent to use compare_versions next to see actual text changes, which defines a workflow and differentiates this tool from a key sibling. It does not, however, describe when to choose lookup_citation or search_regulations instead, so guidance is good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the core operation (showing a diff), the minimum date constraint ('Both dates must be 2017-01-03 or later'), and the intent of comparing pre/post amendment text. It does not explicitly state that the tool is read-only, but 'Show' and 'diff' strongly imply a non-destructive operation. Some detail about output formatting is left to the output schema, which is reasonable.
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 four tight sentences: purpose, workflow, parameter mapping, and a constraint. Each sentence earns its place, the most important information is front-loaded, and there is no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent to call the tool correctly: it explains what the tool does, how to choose dates, which sibling to use first, and an important date restriction. With an output schema present, the description does not need to document return values. The optional max_chars parameter is absent, but its name and default make it self-evident, so this is not a blocking gap.
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 description adds meaningful semantic guidance beyond the schema: it maps date_a to the day before an amendment and date_b to the amendment date, and imposes a global minimum date. The schema already covers citation and date formats, and date_b's optionality. However, max_chars is not mentioned in the description and appears to lack schema coverage, so the description does not fully compensate for that one parameter.
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 clear verb-and-resource statement: 'Show how a citation's text differs between two dates, as a diff.' This immediately distinguishes it from siblings like lookup_citation and what_changed. The mention of what_changed further clarifies that compare_versions is specifically for diffing text between dates, not for finding dates.
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 says 'Use what_changed first to find amendment dates worth comparing' and then gives a concrete recipe for date_a and date_b. This tells the agent when to use this tool and how it fits with an alternative, leaving no ambiguity about the recommended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cfr-mcp MCP server](https://glama.ai/mcp/servers/mccallar/cfr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mccallar/cfr-mcp)

Score Badge

Copy to your README.md:

[![cfr-mcp MCP server](https://glama.ai/mcp/servers/mccallar/cfr-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mccallar/cfr-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mccallar/cfr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server