Vaquill

Section Amendment History

get_section_history

Read-only

Recorded amendments to one provision, including the changing Act and section, effective dates and replaced wording where published. Use when tracing changes or checking whether published text reflects later amendments. An empty history can mean no changes or no parsed records, as coverage explains. Read appliedStatus on every event. Amendments are not applied to served text. Cost: 2 credits.

Input Schema

TableJSON Schema

Name	Required	Description
`asOf`	No	Split the recorded amendments around a date (YYYY-MM-DD). Returns a timeline, never reconstructed text.
`limit`	No	Events per page.
`act_id`	Yes	Section 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.
`offset`	No	Zero-based offset.
`section_number`	Yes	Section number as the publisher writes it, e.g. `302` or `498A`; an alphanumeric suffix is part of the number, not a sub-provision. Near spellings (`498-A`, `Sec. 302`, `302(1)`) are tried when the exact one misses. A miss is a 404 with the act's nearest numbers in `didYouMean`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

changedInput schema / properties / section_number / description

Previous value: -"Section number as the publisher writes it, e.g. `302` or `498A`. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A.\n\nWhen the number as sent matches nothing, common spellings are tried: a `s.` / `Sec.` / `Section` prefix, `498-A` or `498 A` or `498a` for `498A`, and a trailing sub-provision such as `302(1)`, which serves the whole section. A match is served only when exactly one stored number fits, and the response carries `resolvedFrom`. A miss returns 404 with `reason` and the act's nearest numbers in `didYouMean`."New value: +"Section number as the publisher writes it, e.g. `302` or `498A`; an alphanumeric suffix is part of the number, not a sub-provision. Near spellings (`498-A`, `Sec. 302`, `302(1)`) are tried when the exact one misses. A miss is a 404 with the act's nearest numbers in `didYouMean`."

Changed3 schema fields changedOct 1, 2026

changedInput schema / properties / act_id / pattern

Previous value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"

changedInput schema / properties / section_number / description

Previous 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."New value: +"Section number as the publisher writes it, e.g. `302` or `498A`. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A.\n\nWhen the number as sent matches nothing, common spellings are tried: a `s.` / `Sec.` / `Section` prefix, `498-A` or `498 A` or `498a` for `498A`, and a trailing sub-provision such as `302(1)`, which serves the whole section. A match is served only when exactly one stored number fits, and the response carries `resolvedFrom`. A miss returns 404 with `reason` and the act's nearest numbers in `didYouMean`."

changedInput schema / properties / section_number / pattern

Previous value: -"^[A-Za-z0-9().\\- ]{1,40}$"New value: +"^[^/\\\\\\x00-\\x1f]{1,40}$"

Changed2 schema fields changedSep 14, 2026

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."

AddedSep 7, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only declare a safe read (readOnlyHint=true), and the description adds substantial behavioral context beyond that: empty histories can mean either no changes or unparsed records, coverage quality matters, 'Read appliedStatus on every event', amendments are NOT applied to served text, and the call costs 2 credits. Those are exactly the non-obvious traits an agent needs.

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 resource definition, then usage, then caveats, then cost. Dense and largely waste-free, though the telegraphic fragments ('Read appliedStatus on every event.', 'Cost: 2 credits.') read as clipped rather than polished.

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?

An output schema exists, so return values need no explanation, yet the description still flags the critical field to inspect (appliedStatus) and warns that served text is not amended. Combined with the coverage caveat and cost note, an agent has everything needed to call and interpret this tool correctly.

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 100%, so act_id, section_number, asOf, limit and offset are all fully documented in the schema with patterns, examples and even 404/didYouMean behavior. The description adds no parameter-level syntax of its own, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource and scope: 'Recorded amendments to one provision, including the changing Act and section, effective dates and replaced wording where published.' The 'one provision' scope implicitly separates it from the act-level sibling get_act_amendments, but that sibling is never named, so an agent must infer the boundary.

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?

'Use when tracing changes or checking whether published text reflects later amendments' gives clear positive usage context and a concrete scenario. It does not, however, state when to prefer the act-wide get_act_amendments or get_act_status instead, so the routing decision is left partly to inference.

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

All Vaquill tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.