Vaquill

India Section References

india_section_references

Read-only

Outbound citations: the other enactments this provision names, and the sections of its own act it cross-refers to.

Cost: 2 credits. An empty result for a provision we hold IS the answer and is charged; a provision we do not hold is refunded.

Act references are resolved to an actId where the title names something we serve, and returned with resolved: false where it does not. That is the honest split: the publisher names acts we may not hold, and a null id is a coverage fact rather than a parse failure.

This route takes no query parameters and is not paged: one provision's own outbound edges are a short list. totalActs and totalSections are the full counts, and truncated says whether the row cap cut either list.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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_number`	Yes	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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 14, 2026

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.4/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond the readOnlyHint/openWorldHint annotations: it explains the 2-credit cost, the charge/refund distinction, the resolved:false semantics, the lack of paging, and the meaning of totalActs, totalSections, and truncated. This gives the agent a reliable model of edge cases.

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 purposeful, front-loading the core purpose before cost and edge-case semantics. A few phrases like 'that is the honest split' are slightly editorial, but every paragraph contributes useful operational information.

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?

With an output schema present, the description does not need to enumerate return fields. It covers cost, refund behavior, resolution semantics, paging, and truncation, which are exactly the contextual details an agent needs to correctly interpret results. Nothing important appears missing.

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 parameter descriptions are already detailed, including format, examples, and anti-patterns like hand-building act_id. The tool description adds no new parameter-level semantics, so baseline 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 names a specific action and resource: it returns outbound citations for a provision, including other enactments named and cross-references within its own act. This clearly differentiates it from sibling tools like india_act_cited_by, which appears to handle inbound citations.

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 clear situational context: this route handles one provision's outbound edges, takes no query parameters, and is not paged. It does not explicitly name alternative tools or say when not to use it, but the coverage and crediting notes provide enough practical guidance.

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.