cfr-free

Overview Schema Source Related Servers Discussions Admin

Line redline of one provision between two eCFR issue dates

redline

Read-onlyIdempotent

Compare one Title 38 citation across two eCFR issue dates to show which lines changed, were added, or removed, with status and raw text from each date.

Instructions

Line-level redline of one Title 38 provision between two eCFR issue dates: which lines of citation changed, were added, or were removed between from_date and to_date (both YYYY-MM-DD, both required — this tool has no default-to). The dates are SELECTORS — eCFR serves the revision in force on the requested date; they are not a verified stamp of which issue date was served. Returns the status (changed/added/removed/unchanged), both sides' raw text, and one hunk per line (same/add/del with 1-based anchors into each side's text). Identical or impossible dates (e.g. month 13) are rejected as errors before any fetch; a citation missing from BOTH dates is a not_found error after the fetches. Stateless: both dates' full-title XML is fetched from eCFR per call — no local index needed, no cache. When either side exceeds the core's line cap the per-line walk is replaced by two whole-text coarse blocks (coarse: true) — passed through uncapped here, the core's own bound.

Input Schema

Name	Required	Description
`to_date`	Yes	eCFR issue date, YYYY-MM-DD
`citation`	Yes	the citation to redline, e.g. "38 CFR 4.125" (≤ 120 chars)
`from_date`	Yes	eCFR issue date, YYYY-MM-DD

Output Schema

Name	Required	Description
`hunks`	Yes
`coarse`	Yes
`notice`	Yes	the limit on what the two dates mean: eCFR serves the revision in force on the requested date and does not report which issue date that is, so the dates are selectors and not a stamp of the revision served
`status`	Yes
`toText`	No
`citation`	Yes
`fromText`	No
`toIssueDate`	Yes
`fromIssueDate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.1Oct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses that dates are selectors rather than verified issue stamps, that full-title XML is refetched per call with no cache, and the exact error ordering (date validation before fetch, not_found after fetch). Also explains the coarse-block degradation when the core line cap is exceeded.

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 purpose and organized around output, error behavior, and statelessness, with no filler sentences. It is dense to the point of being a single long paragraph, which slightly hurts scanability.

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 stateless remote-fetch diff tool, it covers return shape, failure modes, cost implications (full-title fetch per call), and degraded-mode output, and an output schema already documents the payload. Nothing an agent needs in order to call it correctly is missing.

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, but the description adds real meaning the schema cannot: the dates act as selectors for the revision in force, not as a guarantee of which issue date was served. The citation parameter itself gets no added semantics beyond the schema example.

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: a line-level redline of one Title 38 provision between two eCFR issue dates, enumerating the outcomes (changed/added/removed/unchanged). It is clearly narrower than whole-title siblings like diff_issues or single-date get_section_at.

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?

Clear usage context: both dates are required and there is no default-to, so the agent knows it must supply a comparison window. However, it never names diff_issues or get_section_at as alternatives, so routing between the comparison tools is left implicit.

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

Deploy Server