US Federal Regulations (CFR)

Read an eCFR section (FDA, OSHA, EPA)

get_cfr_section

Read-onlyIdempotent

Read an eCFR section (FDA, OSHA, EPA). 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.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	Yes	CFR title number, 1 to 50: for example 21 is Food and Drugs, 29 Labor, 17 Securities, 40 Environment, 14 Aeronautics.
`offset`	No	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.
`section`	Yes	Section number as written in the citation, without the section sign: "11.10", "240.10b-5" or "1910.134".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`asOf`	Yes
`text`	Yes
`notice`	Yes
`source`	Yes
`heading`	Yes
`citation`	Yes
`authority`	No
`titleName`	Yes
`truncated`	Yes
`amendments`	No
`nextOffset`	No
`totalChars`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 13, 2026

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"
+]

Changed1 schema field changedOct 5, 2026

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"
-}

Changed1 schema field changedOct 4, 2026

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"
+}

First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial context beyond them: what is returned (current text, heading, statutory authority, amendment history, eCFR as-of date, link), the truncation behavior at paragraph boundaries with nextOffset, and a not-legal-advice disclaimer. Pagination semantics are a genuine behavioral disclosure the annotations cannot carry.

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 usage, then return shape, then exclusions — a logical order. It is on the long side, and the agency list and citation examples appear in both the title and the description, which is mild redundancy, but nearly every sentence adds information.

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 full annotations, complete schema coverage and an output schema, this description covers everything an agent needs: trigger, inputs, pagination continuation, return contents, and scope limits. Nothing material is missing.

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 100%, so title, section and offset are already documented with examples and ranges. The description only restates 'pass the CFR title number and the section number' and reiterates the offset loop already described in the schema's offset field. Baseline 3 is correct when the schema does the heavy lifting.

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 (Read) and resource (an eCFR section), names the agencies covered, and gives three concrete citation examples. An agent can distinguish this from search_cfr purely from the description 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?

Explicitly states the triggering condition (user asks what a specific federal regulation says), gives example phrasings, names the alternative for topic-based lookup (search_cfr), and enumerates exclusions: statutes, state law, court decisions, compliance determinations. This is a complete when/when-not/alternative set.

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

All US Federal Regulations (CFR) tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.