cfr-free

Overview Schema Source Related Servers Discussions Admin

Read one provision as it stood at a date

get_section_at

Read-onlyIdempotent

Retrieve the text of a Title 38 CFR section as it stood on a specific date, useful for date-of-claim and CUE questions about what a regulation said when a claim was filed.

Instructions

One Title 38 provision as it stood at a requested date (YYYY-MM-DD, required). eCFR serves the revision IN FORCE on that date, so a date that is not itself an issue date resolves to the revision that was in force then; the upstream does not report which issue date it served, so the response names the REQUESTED date and never a served-revision date. Stateless: the revision is fetched from eCFR on every call — no local index, no cache. eCFR's point-in-time archive starts at 2017-01-01; a date before that is rejected as not_found. Use this for date-of-claim and CUE questions ("what did this section say when the claim was filed?"); for the CURRENT text use get_section.

Input Schema

Name	Required	Description	Default
`at_date`	Yes	eCFR issue date, YYYY-MM-DD
`citation`	Yes	the citation to read, e.g. "38 CFR 4.130"

Output Schema

Name	Required	Description	Default
`kind`	Yes
`part`	Yes
`path`	Yes
`text`	Yes
`chapter`	Yes
`heading`	Yes
`subpart`	Yes
`citation`	Yes
`markdown`	Yes
`sourceUrl`	Yes
`requestedDate`	Yes
`sourceUrlAtRequestedDate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.1Oct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses key behavior: eCFR serves the revision in force on the date, the response names the requested date rather than the served revision, and calls are stateless with no cache. It also states that dates before 2017-01-01 are rejected as not_found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, followed by date-resolution behavior, statelessness, archive boundary, and usage routing. It is dense but every sentence contributes, and there is no filler.

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?

Given two required params, full schema coverage, an output schema, and read-only annotations, the description supplies everything an agent needs: date semantics, rejection boundary, statelessness, and sibling differentiation.

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 is 3. The description adds real semantic value about at_date: it resolves to the revision in force, the upstream does not report the served issue date, and pre-2017 dates are rejected. Citation semantics are largely left to 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?

The description opens with a specific verb and resource: reading one Title 38 provision as it stood at a requested date. It explicitly distinguishes itself from the sibling get_section by naming that alternative for current text.

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?

It gives explicit use cases for date-of-claim and CUE questions, and explicitly routes current-text requests to get_section. The before-2017 exclusion is also stated as a rejection condition.

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

Deploy Server