Vaquill

India Act Cited By

india_act_cited_by

Read-only

Inbound citations: provisions elsewhere in the corpus that name this act.

Cost: 2 credits. A confident "nothing cites this" is the answer and is charged.

🔴 Matched on the act's TITLE, not on an identifier, because that is what the corpus stores. A citing document that wrote the title differently is missed, and the publisher's own line breaks make that measurable. Read matchBasis and treat the result as a floor rather than a complete set.

A foundational act can be cited by thousands of provisions, so the answer is PAGED with page + pageSize, the same as the rest of this API.

total is the number of distinct citing PROVISIONS across all pages, not the size of the page you were served (returned) and not the number of matching passages: one provision is stored as many passages, so total is the smaller number. totalIsExact goes false only if the corpus scan behind that count hits its ceiling, which no act in the corpus currently reaches.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	1-based page number.
`limit`	No	DEPRECATED alias for `pageSize`, kept working for clients written against the original shape. Send one or the other, not both.
`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.
`pageSize`	No	Rows per page (1-100). Defaults to 25.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 14, 2026

addedInput schema / properties / limit / anyOf

Added value: +[
+  {
+    "maximum": 100,
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / limit / default
```
Removed value: -25
```

changedInput schema / properties / limit / description

Previous value: -"Rows to return."New value: +"DEPRECATED alias for `pageSize`, kept working for clients written against the original shape. Send one or the other, not both."

removedInput schema / properties / limit / maximum
```
Removed value: -100
```
removedInput schema / properties / limit / minimum
```
Removed value: -1
```
removedInput schema / properties / limit / type
```
Removed value: -"integer"
```

addedInput schema / properties / page

Added value: +{
+  "default": 1,
+  "description": "1-based page number.",
+  "examples": [
+    1
+  ],
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / pageSize

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 100,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Rows per page (1-100). Defaults to 25.",
+  "examples": [
+    25
+  ]
+}

AddedSep 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing cost, title-based matching, likely false negatives, pagination behavior, and the meaning of `total` versus `returned`. It also explains `totalIsExact` and `matchBasis` semantics. There is no contradiction with `readOnlyHint: true` or `openWorldHint: false`.

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?

The description is dense but well structured, with clear bolded caveats and a front-loaded first sentence. However, the supplied text ends with an incomplete/truncated sentence about `totalIsExact` ('goes false when ...?'), which prevents a perfect structure score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paged read-only tool with an output schema, the description covers the important non-obvious behaviors: title matching, incompleteness risk, cost, and pagination/total semantics. The incomplete `totalIsExact` explanation is a small gap, but the presence of an output schema reduces the need for the description to fully document every return field.

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%, and the schema already documents `act_id`, `page`, `pageSize`, and `limit` with examples and constraints. The description mostly discusses output-field semantics (`total`, `returned`, `totalIsExact`) rather than adding new parameter-level guidance, so the baseline of 3 is appropriate.

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 opens with a specific definition — 'Inbound citations: provisions elsewhere in the corpus that name this act' — which clearly identifies the resource and the direction of the lookup. It also adds the key distinction that matching is done on the act's TITLE, not an identifier, which further separates it from nearby sibling tools.

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 provided: this tool finds provisions that cite the act, returns paged results, and should be treated as a floor rather than a complete set. It does not explicitly name alternatives or say when not to use it, so it stops short of a 5.

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.