ecfr-mcp

list_sections_in_part

Read-only

List all sections and appendices in a CFR part with their headings.

Instructions

List all sections and appendices in a CFR part with their headings.

Returns 'sections' in order, each {identifier, heading}, with type='appendix' on appendices (2 CFR 200's Appendix I-XII, for example) and reserved=true on reserved sections, plus 'subparts' (each with its heading, section_count and first and last section). Useful for seeing the scope of a part before reading specific sections.

The part number alone is enough: chapter is optional (Title 48 parts are unique: 52 = FAR, 252 = DFARS, 552 = GSAR) and the answer reports the chapter the part is in. subpart (e.g. '52.2') lists one subpart. A list too long to send at once (FAR Part 52 has 680 entries) comes in pages: page and total_pages say where you are; page=2 gets the rest. detail=True adds eCFR's label, size and received_on for each entry (received_on is when eCFR processed the text, not when it was amended; get_version_history has amendment dates).

part_number accepts int or string.

Input Schema

Name	Required	Description	Default
`date`	No
`page`	No
`detail`	No
`chapter`	No
`subpart`	No
`part_number`	Yes
`title_number`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.0.33Oct 12, 2026

changedInput schema / properties / chapter / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "integer"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / chapter / default
```
Previous value: -"1"New value: +null
```

addedInput schema / properties / detail

Added value: +{
+  "default": false,
+  "title": "Detail",
+  "type": "boolean"
+}

addedInput schema / properties / page

Added value: +{
+  "default": 1,
+  "title": "Page",
+  "type": "integer"
+}

addedInput schema / properties / subpart

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

Changed2 schema fields changedv1.0.7Aug 20, 2026

addedInput schema / properties / chapter / anyOf

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

addedInput schema / properties / part_number / anyOf

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

First observedv0.2.6May 16, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: pagination semantics ('page and total_pages say where you are; page=2 gets the rest'), the 680-entry scale warning, and the exact meaning of detail's received_on field. No auth or rate-limit detail, hence not a 5.

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 core action and return shape, then layered with parameter guidance. Dense but all sentences carry information; the parenthetical examples (2 CFR 200 Appendix I-XII, 52/252/552) earn their space. Slightly long for the payload.

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?

An output schema exists, so return-value explanations are technically optional, yet the description still clarifies what an agent needs to paginate and interpret entries. The only substantive hole is the undocumented `date` parameter, which for a versioned regulatory lookup is a real gap.

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 carries the full burden and does explain part_number type flexibility, chapter optionality with FAR/DFARS/GSAR examples, subpart ('52.2'), page, detail, and the title_number default of 48. However, the `date` parameter is never mentioned, leaving one of seven params with no semantics anywhere.

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?

Opens with a specific verb+resource+scope: 'List all sections and appendices in a CFR part with their headings.' It names concrete return artifacts (sections, subparts, type='appendix', reserved=true) and contrasts against the sibling that reads content ('before reading specific sections'), so an agent can distinguish it from get_cfr_content without opening schemas.

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?

Gives clear usage context ('seeing the scope of a part before reading specific sections') and routes a nuance to a sibling: detail=True's received_on is explicitly not amendment dates, and get_version_history is named as the right tool for those. It stops short of explicit when-not-to-use or prerequisites.

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

Deploy Server