Skip to main content
Glama
1102tools-dev

ecfr-mcp

by 1102tools-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

compare_versions

Read-only

Compare the text of a CFR section at two different dates.

Instructions

Compare the text of a CFR section at two different dates.

Useful for understanding what changed in a regulatory amendment. Returns 'changes' (each paragraph that was added, removed or changed, with its before and after text; also heading, table and pending-amendment-link changes), 'identical' when nothing differs, and the parsed text at both dates side by side. When both texts together are too long to send, the full texts are left out (texts_omitted) and 'changes' is kept. changes_only=True leaves the full texts out every time: the short answer to "what changed".

Dates must be in YYYY-MM-DD format. Historical snapshot availability varies by title and section, including some dates before 2017. Use get_version_history to discover dates. Both dates must not exceed the title's up_to_date_as_of value.

This tool always returns the section-level XML parsed -- pass a small section_id like '15.305', not a whole part. Whole-part comparisons can exceed 100 KB per side.

Input Schema

NameRequiredDescriptionDefault
chapterNo
date_afterYes
section_idYes
date_beforeYes
changes_onlyNo
title_numberNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.33
    • addedInput schema / properties / changes_only
      Added value: +{
+  "default": false,
+  "title": "Changes Only",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv1.0.7
    • addedInput schema / properties / chapter / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / section_id / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  }
+]
  3. First observedv0.2.6

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the read-only/open-world safety profile, and the description goes well beyond them: return payload keys ('changes', 'identical'), the size-based omission behavior (texts_omitted), the changes_only bypass, date format constraints, snapshot availability variance, and the up_to_date_as_of ceiling. This is substantial disclosure for a read tool.

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, then return shape, then constraints — a sensible ordering where the 'short answer' framing for changes_only is a nice compression. It runs long across several short paragraphs, and a couple of constraint sentences could be tightened, but nothing is pure 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?

For a 6-param, 3-required comparison tool with an output schema, the description supplies everything an agent needs that the schema does not: date semantics, sizing caution, omission behavior, and discoverability path. Even though the output schema covers return shapes, the added operational caveats make this feel complete rather than redundant.

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?

With 0% schema description coverage, the description must carry parameter meaning, and it does for the important ones: date format (YYYY-MM-DD), what changes_only=True does, and the size/type constraint on section_id ('15.305', not a whole part). It does not explain the chapter parameter or the significance of title_number (defaulting to 48), leaving two of six params 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?

Opens with a specific verb+resource+scope: 'Compare the text of a CFR section at two different dates.' It immediately differentiates from siblings by framing the task as amendment diffing rather than retrieval, and it names get_version_history as the companion tool for date discovery.

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?

States the use case ('understanding what changed in a regulatory amendment'), names the alternative tool for finding dates ('Use get_version_history to discover dates'), and gives exclusions/limits ('pass a small section_id like 15.305, not a whole part'). An agent knows when to pick this and what not to do with it.

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

Deploy Server

Other Tools