ecfr-mcp

get_cfr_structure

Read-only

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

Instructions

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.

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.

Changed1 schema field changedv1.0.33Oct 12, 2026

addedInput schema / properties / depth

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Depth"
+}

Changed5 schema fields changedv1.0.7Aug 20, 2026

addedInput schema / properties / appendix

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Appendix"
+}

addedInput schema / properties / chapter / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / part / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / subchapter / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / subpart / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv0.2.6May 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, non-destructive, open world), yet the description still adds real behavioral detail: the 400 on section-level filtering, depth's replacement of deeper levels with 'children_omitted', automatic truncation of oversized trees with a 'note' field, and the Title 48 subchapter-needs-chapter constraint. These are failure modes an agent cannot infer from annotations.

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 the purpose and the critical limitation, then organized under a 'Common patterns' header. Slightly long and the parenthetical byte-size aside is nearly filler, but every block conveys distinct usable information.

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 read-only tool with 8 optional selectors and an output schema handling return values, the description covers selection logic, depth/truncation behavior, and edge cases well. The only meaningful omission is guidance on the date parameter, which determines whether the agent queries get_latest_date first.

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 description coverage is 0% across 8 parameters, so the description carries the load and mostly does: depth semantics, subchapter/chapter coupling, int-or-string acceptance for part/subpart/chapter/appendix, and worked examples for each selector. It leaves the date parameter's meaning (which point-in-time to request, versus get_latest_date) and why title_number defaults to 48 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?

States a specific verb and resource ('Get the hierarchical table of contents for a CFR title or subset') and immediately differentiates itself from the sibling that overlaps most, list_sections_in_part, for getting sections of a single part. An agent can select this over the other 12 siblings without opening a 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?

Explicit exclusions ('Does NOT support section-level filtering (returns 400). Use part or subpart'), a named alternative for the narrowing case, and four concrete invocation patterns covering part, subpart, chapter+depth, and appendix. This is about as prescriptive as usage guidance gets.

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

Deploy Server