Skip to main content
Glama

Citations From a Section

india_section_references
Read-only

Outbound citations from a provision to other enactments and sections of its own act. Use when following references outwards, not finding citations to the act. actId identifies served targets, while resolved false marks coverage gaps rather than parse failures. Results are not paged. totalActs and totalSections give full counts, so check truncated before treating returned references as complete. Cost: 2 credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
section_numberYesSection 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
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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`."
  2. Changed3 schema fields changed
    • 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}$"
  3. Changed1 schema field changed
    • 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."
  4. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, openWorld=false, non-destructive), yet the description adds substantial operational context: unpaged results, totalActs/totalSections counts, the need to check 'truncated' before trusting completeness, that resolved=false signals coverage gaps rather than parse failures, and a 2-credit cost. This is exactly the kind of disclosure structured fields cannot carry.

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?

Front-loaded with purpose, then usage direction, then delivered-value semantics, then result-shape caveats, then cost. Every sentence adds a distinct fact with no filler.

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?

For a read-only, two-parameter tool with an output schema, the description covers traversal direction, field interpretation, non-pagination, truncation handling, and cost. An agent has everything needed to call and correctly interpret the call.

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 coverage is 100%, so the baseline is 3, but the description adds interpretive meaning beyond the schema: actId 'identifies served targets' and resolved=false indicates coverage gaps. The actId phrasing is slightly terse and does not fully clarify its relationship to the returned references, so it stops short of a 5.

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?

States the exact verb and resource: 'Outbound citations from a provision to other enactments and sections of its own act.' This immediately distinguishes it from the inbound sibling india_act_cited_by and from get_act_section_body, so an agent can route 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when following references outwards, not finding citations to the act,' which names both the triggering condition and the excluded alternative (inbound citation lookup). Nothing is left to inference about direction of traversal.

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.