Vaquill

Act Amendment History

get_act_amendments

Read-only

The amendment history recorded against one enactment: substitutions, insertions and omissions, each with the amending Act and its effective date (e.g. 'Subs. by Act 22 of 2023, s. 44 (w.e.f. 13-11-2025)'). Use to check whether a provision still reads as enacted before relying on its text. An empty list means no amendment was recorded, NOT that the Act was never amended. Cost: 5 credits.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	1-based page number.
`type`	No	Amendment action class. Served in the NOMINAL spelling; the corpus stores the verbal form (`substituted`) and either is accepted. Values: `substitution`, `insertion`, `omission`, `renumbering`, `addition`, `repeal`, `deletion`, `adaptation`, `amendment`, `note`.
`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.
`section`	No	Keep only footnotes attached to this section, written exactly as the publisher does. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A.
`pageSize`	No	Results per page (1-200).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedSep 14, 2026

addedInput schema / properties / act_id / examples
```
Added value: +[
+  "IND_state_20326"
+]
```

changedInput schema / properties / page / description

Previous value: -"Page number"New value: +"1-based page number."

addedInput schema / properties / page / examples
```
Added value: +[
+  1
+]
```

changedInput schema / properties / pageSize / description

Previous value: -"Results per page"New value: +"Results per page (1-200)."

addedInput schema / properties / pageSize / examples
```
Added value: +[
+  100
+]
```

changedInput schema / properties / section / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 40,
+    "pattern": "^[A-Za-z0-9().\\- ]{1,40}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / section / description

Previous value: -"Filter by section number"New value: +"Keep only footnotes attached to this section, written exactly as the publisher does. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A."

addedInput schema / properties / section / examples
```
Added value: +[
+  "23"
+]
```

changedInput schema / properties / type / description

Previous value: -"Amendment action class. Served in the NOMINAL spelling; the corpus stores the verbal form (`substituted`) and either is accepted."New value: +"Amendment action class. Served in the NOMINAL spelling; the corpus stores the verbal form (`substituted`) and either is accepted. Values: `substitution`, `insertion`, `omission`, `renumbering`, `addition`, `repeal`, `deletion`, `adaptation`, `amendment`, `note`."

Changed3 schema fields changedSep 7, 2026

changedInput schema / properties / type / description

Previous value: -"Filter: substitution, insertion, omission, note, renumbering"New value: +"Amendment action class. Served in the NOMINAL spelling; the corpus stores the verbal form (`substituted`) and either is accepted."

addedInput schema / properties / type / enum

Added value: +[
+  "substitution",
+  "insertion",
+  "omission",
+  "renumbering",
+  "addition",
+  "repeal",
+  "deletion",
+  "adaptation",
+  "amendment",
+  "note"
+]

addedInput schema / properties / type / examples
```
Added value: +[
+  "substitution"
+]
```

First observedSep 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals a critical caveat: an empty list means no amendment was recorded, not that the Act was never amended. It also discloses the amending Act and effective date format, and specifies a cost of 5 credits. These are meaningful behavioral traits that shape agent expectations and are not present in the structured annotations.

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 compact, front-loads the core function, includes one illustrative example, and each remaining sentence adds distinct value: usage guidance, the empty-list caveat, and cost. No filler or repetition of the title exists.

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 output schema existsley and the annotations declare readOnlyHint, the description is sufficiently complete for an agent to select and invoke the tool. It covers the key caveat about empty results pending amendment, the cost, and the type of response. The remaining operational details like pagination are already documented in the input schema.

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 the schema already fully documents all five parameters, including examples for act_id, type normalization, and section formatting. The description adds no additional parameter-level meaning beyond framing the tool as 'one enactment.' With full schema coverage, the baseline score of 3 applies.

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 exactly what the tool returns: amendment history for one enactment, including substitutions, insertions, omissions, amending Act, and effective date. It pairs a specific verb with a clear resource and grounds it with a concrete example, making its purpose unambiguous. It is clearly distinguished from related tools like get_act_text or get_act_status by focusing on amendment history rather than content or status.

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?

The description gives explicit guidance on when to use the tool: check whether a provision still reads as enacted before relying on its text. It does not explicitly name alternatives or exclusion conditions, but the purpose and context are clear enough for an agent to select this tool over siblings. A small gap is not saying when to prefer get_section_history or get_act_status instead.

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.