Skip to main content
Glama

US Federal Regulations (CFR)

Read a CFR section

get_cfr_section
Read-onlyIdempotent

Read a CFR section. Use this when the user asks what a specific US federal regulation says, including an FDA, OSHA, EPA, SEC, FTC or FAA section of the eCFR, for example "what does 21 CFR 11.10 say?", "read 29 CFR 1910.134" or "show me 17 CFR 240.10b-5". Pass the CFR title number and the section number. Returns the current text, heading, statutory authority and amendment history of the section, the date the eCFR is up to date as of and a link to it. A very long section is cut at a paragraph and flagged with nextOffset; call again with that offset to read on. This is general information, not legal advice. Do not use it to find a regulation by topic (use search_cfr), for statutes, state law or court decisions, or to decide whether someone complies.

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": {
      "title": "<title>",
      "section": "<section>"
    },
    "name": "get_cfr_section"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesCFR title number, 1 to 50: for example 21 is Food and Drugs, 29 Labor, 17 Securities, 40 Environment, 14 Aeronautics.
offsetNoWhere to start reading, in characters. Leave out to read from the start; to read on in a section that was cut, pass the nextOffset of the last answer.
sectionYesSection number as written in the citation, without the section sign: "11.10", "240.10b-5" or "1910.134".

Output Schema

NameRequiredDescriptionDefault
urlYes
asOfYes
textYes
noticeYes
sourceYes
headingYes
citationYes
authorityNo
titleNameYes
truncatedYes
amendmentsNo
nextOffsetNo
totalCharsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "Where to start reading, in characters. Leave out to read from the start; to read on in a section that was cut, pass the nextOffset of the last answer.",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedOutput schema / properties / nextOffset
      Added value: +{
      +  "type": "integer"
      +}
    • addedOutput schema / properties / totalChars
      Added value: +{
      +  "type": "integer"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "citation",
      -  "titleName",
      -  "heading",
      -  "text",
      -  "truncated",
      -  "asOf",
      -  "url",
      -  "notice",
      -  "source"
      -]New value: +[
      +  "citation",
      +  "titleName",
      +  "heading",
      +  "text",
      +  "truncated",
      +  "totalChars",
      +  "asOf",
      +  "url",
      +  "notice",
      +  "source"
      +]
  2. Changed1 schema field changed
    • removedOutput schema / properties / note_from_openkrill
      Removed value: -{
      -  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
      -  "type": "string"
      -}
  3. Changed1 schema field changed
    • addedOutput schema / properties / note_from_openkrill
      Added value: +{
      +  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantial non-redundant behavior: what fields come back (text, heading, statutory authority, amendment history, eCFR currency date, link), paragraph-boundary truncation with a nextOffset continuation protocol, and a legal-advice disclaimer. That pagination contract is exactly the kind of trait annotations cannot express.

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-loaded with purpose and examples, then returns, then pagination, then exclusions — a sensible ordering with no filler sentences. It runs long and the disclaimer plus returns enumeration could be trimmed given an output schema exists, keeping it just short of 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with 3 params, full schema coverage, and an output schema, everything an agent needs is present: citation inputs, pagination continuation, return contents, currency date, and scope boundaries. Nothing material is left to inference.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3; the description earns above that by tying the optional offset to observed behavior ("A very long section is cut at a paragraph and flagged with nextOffset; call again with that offset"), which explains the parameter's purpose in workflow terms rather than as a bare character count. It restates title/section pairing without adding format detail beyond the schema.

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 ("Read a CFR section") and immediately grounds it with three concrete citation examples spanning agencies. An agent can distinguish it from search_cfr without opening either schema.

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?

Gives explicit positive triggers ("what a specific US federal regulation says", with quoted example queries) and an explicit negative list: not for topic search (names search_cfr), not for statutes, state law or court decisions, and not for compliance determinations. This is the full when/when-not/alternative pattern.

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.