eCFR

get_cfr_structure

Read-only

Get the hierarchical table of contents for a CFR title or subset.

Returns a nested tree of titles, chapters, parts, subparts, and sections
with identifiers, descriptions, and byte sizes, plus the date it
describes.

IMPORTANT: Does NOT support section-level filtering (returns 400).
Use part or subpart, then walk the children to find sections.

Common patterns:
- part='15' for FAR Part 15 structure
- subpart='15.3' for just that subpart's sections
- chapter='1', depth=2 for the FAR's subchapters and parts only
- appendix='Appendix A to Part 200' with part='200' (title 2) for one appendix

depth keeps that many levels below the node asked for (part='19',
depth=1 gives Part 19's subparts); deeper levels are replaced by
'children_omitted' (how many there were). For the sections of one part,
list_sections_in_part is shorter. A tree too large
to send at once (a whole chapter is about 1 MB) is cut to the deepest
depth that fits, and 'note' says so.

subchapter needs chapter in Title 48 (each chapter has its own
subchapter A, B, ...). part/subpart/chapter/appendix accept int or string.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_cfr_structure"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No
`part`	No
`depth`	No
`chapter`	No
`subpart`	No
`appendix`	No
`subchapter`	No
`title_number`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare read-only/open-world safety; the description adds substantial behavioral context beyond them: the 400 on section-level filters, truncation of oversized trees (~1 MB chapter) to the deepest fitting depth with a 'note' field, and 'children_omitted' counts for pruned levels. It also flags the Title 48 subchapter-needs-chapter constraint, which would otherwise cause silent misuse.

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 return shape, then a scoped IMPORTANT block, then worked examples, then depth semantics — a sensible ordering with almost no filler. Slight deductions for line-wrapped mid-sentence fragments and a somewhat dense block that could be tightened, but every sentence carries operative 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?

The tool is objectively complex (8 optional params, deep filtering, output truncation) yet the description covers error conditions, truncation fallbacks, sibling selection, and the Title 48 special case. With an output schema present, it need not restate return field names, and the combination leaves nothing essential for a correct call.

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 0%, so the description must carry all semantics, and it does for most: concrete values for part, subpart, chapter, appendix, an explanation of what depth actually counts ('keeps that many levels below the node asked for') and the subchapter/chapter dependency. The 'date' parameter is only faintly addressed via 'plus the date it describes', leaving its default/format behavior undocumented.

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 ('Get the hierarchical table of contents for a CFR title or subset') and immediately describes the returned nested tree, so an agent knows this is structural navigation rather than content retrieval. Implicitly separable from get_cfr_content and list_sections_in_part by the 'table of contents' framing, which the usage note later reinforces.

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?

Explicit when-not guidance: 'Does NOT support section-level filtering (returns 400)' with the workaround (use part/subpart then walk children). Also names the sibling alternative ('For the sections of one part, list_sections_in_part is shorter') and supplies four concrete call patterns covering part, subpart, chapter+depth, and appendix.

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

All eCFR tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.