Skip to main content
Glama

Get Section History

get_section_history
Read-only

The amendment record for a single provision: what changed, which Act changed it, which of that Act's sections did so, when it took effect where the publisher records a date, and the wording it replaced where the publisher quotes it.

Cost: 2 credits. An empty history for a provision we hold IS the answer and is charged; the coverage block tells you whether it is empty because nothing changed or because we hold no parsed record.

Read appliedStatus on every event. It is not_applied throughout, because the text this API serves is the publisher's published text and we do not edit it. That is a deliberate, stated position rather than an omission: you should never have to infer currency from silence.

asOf returns a TIMELINE, not text. We hold amendment events and no versioned text, so there is no honest way to render this provision as it stood on a date. Passing asOf tells you how many recorded amendments had taken effect by then, how many had not, and how many carry no date at all. isBounded true means we hold no recorded event affecting that date, which is not the same as there having been none.

Coverage is real and uneven: many acts carry a non-zero amendment count with no parseable footnote behind it, and about half the records we do hold carry no effective date. Read the coverage block on this response for the provision you asked about, and the free GET /acts/coverage for the corpus-wide split (depth.actsWithAmendmentEvents against depth.actsClaimingAmendmentsWithoutEvents).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asOfNoSplit the recorded amendments around a date (YYYY-MM-DD). Returns a timeline, never reconstructed text.
limitNoEvents per page.
act_idYesSection identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404.
offsetNoZero-based offset.
section_numberYesSection number exactly as the publisher writes it. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / asOf / format
      Added value: +"date"
    • addedInput schema / properties / section_number / description
      Added value: +"Section number exactly as the publisher writes it. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

With only readOnlyHint=true and openWorldHint=false in annotations, the description carries a heavy behavioral burden and discharges it exceptionally: it discloses cost (2 credits), that an empty history is still charged and what the coverage block means, that appliedStatus is deliberately always not_applied (a stated position, not an omission), that asOf returns a timeline not reconstructed text, and that coverage data is uneven. No contradiction with annotations; the read-only claim is consistent with 'we do not edit it'.

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 long but every sentence is load-bearing — cost, empty-response interpretation, appliedStatus policy, asOf semantics, and coverage caveats are all genuine agent-relevant concerns. The core purpose is front-loaded in the first sentence, and there is zero filler or repetition of schema content.

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 the tool's genuine semantic complexity — timeline vs text, deliberate not_applied, charged empty responses, uneven coverage — the description is remarkably complete. It addresses cost, empty-result interpretation, appliedStatus, asOf behavior, and coverage caveats, and points to the free corpus-wide coverage endpoint. The presence of an output schema relieves it of explaining return values, and nothing an agent needs 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 description coverage is 100%, so the baseline is 3 and the schema already documents all five parameters with rich detail (e.g., act_id's 'hand-built ids usually 404' gotcha, section_number's '498A is one section' rule). The description adds genuine conceptual value on top by explaining the asOf semantic (timeline, not text) and the meaning of isBounded, which deepens parameter understanding beyond 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 states a specific verb and resource: 'The amendment record for a single provision' — a precise, detailed scope enumerating exactly what is returned (what changed, which Act, which sections, effective dates, replaced wording). The emphasis on 'a single provision' distinguishes it from act-level siblings like get_act_amendments, so an agent can route correctly without opening any schema.

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 context is given for when the tool is appropriate (per-provision amendment history) and it explicitly routes corpus-wide coverage needs to the free GET /acts/coverage endpoint. However, it does not explicitly name sibling tools (e.g., get_act_amendments) with when-to-use-vs-when-not language, so the exclusion guidance is only implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.