Search US and Indian statutes, regulations, constitutions, and court rules.
Scored across 22 tools
Most tools have clear resource/action targets, but there is meaningful overlap: search vs search_acts, fetch vs get_act_text, and get_act_amendments vs get_section_history. The descriptions explicitly guide selection, which helps, but the set still contains multiple tools that an agent could reasonably confuse.
All names use snake_case and are generally readable, but the convention is not fully uniform: verb_noun patterns (get_act_section, list_acts) mix with noun phrases (india_act_cited_by, india_section_references) and the odd get_pricing_in.
22 tools is on the heavy side for a read-only legal research API. Many tools are justified by the domain, but generic compatibility tools and several fine-grained retrieval endpoints push the surface beyond a tightly scoped set.
Coverage is strong for Indian legislation: search, retrieval, act/section metadata, amendment history, citations, definitions, subordinate instruments, status, filters, coverage, and citation resolution are all present. Minor gaps remain, such as unavailable IEA/BSA mappings and thin amendment-record coverage.
Fetch one Indian enactment by the id from a search result, returning {id, title, text, url, metadata}. Also accepts a source URL or a bare path. NOTE: the India corpus serves an enactment as publisher links rather than inline text, so text carries the title and metadata carries the PDF, HTML and plain-text URLs to read. Prefer get_act_text if you can call it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and non-destructive annotations, the description discloses a critical corpus-specific behavior: the India corpus serves publisher links rather than inline text, so text carries the title and metadata carries PDF, HTML, and plain-text URLs. This is exactly the kind of non-obvious behavior an agent needs before calling the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The primary action and return shape are front-loaded in the first sentence. The following sentences each add necessary context: alternate accepted inputs, the publisher-link quirk, and the sibling preference. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values in detail, yet it still highlights the unusual text and metadata behavior. With annotations covering safety and the description covering the corpus quirk and alternative tool, an agent has what it needs to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by saying the id comes from a search result and that a source URL or bare path is also accepted, but it does not provide examples or format constraints for those alternate forms. The semantic help is real but incomplete for a zero-coverage parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetching one Indian enactment by id from a search result, and it lists the returned shape. It also distinguishes itself from the sibling get_act_text by explicitly preferring that tool when available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent exactly where the id comes from (a search result) and gives an explicit alternative: prefer get_act_text if you can call it. The fallback condition 'if you can call it' makes the routing decision between the two tools clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number. | |
| type | No | Action classes are returned in nominal form, but filters accept both nominal and stored verbal spellings. For example, `substitution` and `substituted` are both accepted. | |
| 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). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Metadata for one provision, including its citation, position in the act, structural features and references. Use when identifying or inspecting a provision without fetching its wording. Text is not included. Use get_act_section_body to read it. wordCount covers all passages, and actsReferenced normalizes whitespace before deduplication so publisher line breaks do not create duplicate acts. Cost: 2 credits.
| 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 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`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lowered. The description still adds value beyond them: it clarifies that text is excluded, documents field quirks (wordCount spans all passages, actsReferenced normalizes whitespace before dedup), and discloses a cost of 2 credits — real behavioral context. It stops short of error/auth behavior, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and the sibling routing are front-loaded in the first three sentences. The wordCount/actsReferenced details are the densest part and could be trimmed, but they are grounded and earn their place better than most filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't be explained, and the description nonetheless clarifies the one field nuance an agent might misread (dedup normalization). Combined with annotations and full param coverage, nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters already carry rich guidance (id provenance, near-spelling fallback, didYouMean on miss). The description adds nothing param-specific beyond what the schema states, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Metadata for one provision' — and enumerates what the metadata includes (citation, position, structural features, references). It explicitly distinguishes itself from the sibling get_act_section_body, so an agent can select it without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit condition ('when identifying or inspecting a provision without fetching its wording') and names the alternative tool (get_act_section_body) with the reason to pick it for text. This is exactly the when-to-use/when-to-use-something-else routing the dimension rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The publisher's full text for one provision, taken directly from the act document without synthesized search headers. Use when reading, quoting or citing the provision's wording rather than its metadata. Amendments are not applied to this text. Check get_section_history for recorded changes before treating the wording as current law. Cost: 3 credits.
| 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 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`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds material context beyond that: the text is unamended, it lacks synthesized search headers, it may not reflect current law, and it costs 3 credits. These are exactly the behavioral traits an agent needs to avoid misusing the wording.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core purpose, followed by usage, the amendments caveat, the sibling pointer, and cost. No sentence is redundant; each adds a distinct fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary. The description otherwise covers purpose, selection criteria, correctness caveats, and cost – everything needed to invoke this read-only tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameter descriptions are unusually rich (id construction pitfalls, 404/didYouMean behavior, suffix rules). The description adds no parameter-level meaning, so the baseline of 3 applies – the schema carries this dimension fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('full text for one provision') and clarifies scope ('taken directly from the act document without synthesized search headers'). This distinguishes it from sibling get_act_section (metadata-oriented) and get_section_history without requiring the agent to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('reading, quoting or citing the provision's wording rather than its metadata') and when to consult an alternative ('Check get_section_history for recorded changes before treating the wording as current law'). Names the sibling and the condition that routes to it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An act's standing in three separate fields, publisherStatus for India Code's label, servedStatus for API availability and repealClaim for the publisher's sourced repeal record. Use when assessing whether an act remains law or why it is unavailable. These are not one verdict. A repealClaim does not verify that the repealing instrument was brought into force. Cost: 1 credit.
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, non-destructive, closed-world), so the description earns credit for adding genuine behavioral nuance: the warning that the three fields are not one verdict, the caveat that repealClaim does not verify the repealing instrument was brought into force, and the explicit 1-credit cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and its three output fields, then usage, then caveats, then cost. Every sentence carries weight. The phrasing is slightly compressed and makes the reader parse clauses, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary. The description covers purpose, when to use, the semantic ambiguity between the three status fields, and the credit cost. It could say a bit more about what each field's presence/absence means, but it is essentially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole act_id parameter is richly documented in the schema itself (pattern, example, and a note about hand-built ids 404ing). The description adds nothing about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (an act), the specific operation (retrieve status), and enumerates the exact fields returned: publisherStatus, servedStatus, repealClaim. That level of specificity clearly separates it from siblings like get_act_amendments or get_act_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use when assessing whether an act remains law or why it is unavailable" gives a clear triggering context. It does not, however, name an alternative tool or a case where a sibling should be preferred instead, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An act's table of contents, with chapters and parts where the publisher supplies them and provisions listed beneath. Use when locating a section or planning a traversal of the act. hasHierarchy is false for most acts, where nodes is a flat section list rather than an error. Section numbers sort numerically with alphabetic suffixes attached. Cost: 2 credits.
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely non-duplicative behavior: hasHierarchy=false is a flat section list rather than an error, numeric sort with alphabetic suffixes, and a 2-credit cost. That is meaningful disclosure beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences, all front-loaded with the core purpose first, then usage cues, then behavioral caveats, then cost. Each sentence carries information; the trailing "Cost: 2 credits." fragment is terse but useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary. Combined with the flat-list caveat, sort order, and cost, the definition gives an agent enough to call and interpret results correctly; only the relationship to specific sibling tools is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (act_id) and schema description coverage is 100%, with the schema itself giving a detailed warning about hand-built ids 404ing. The description adds no parameter-specific meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (an act's table of contents) and its structure (chapters/parts with provisions beneath). This clearly distinguishes it from siblings like get_act_text or get_act_section, which return content rather than navigational structure, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use when locating a section or planning a traversal of the act" gives clear positive usage context and implies the TOC/navigation role versus content-fetching siblings. No explicit when-not-to-use or named alternative is provided, keeping it 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.
Source links for one enactment: the plain-text, PDF and HTML renderings, plus how many sections it holds. Use when the user wants to read or cite the Act itself rather than a matched section. Cost: 3 credits.
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely new behavioral context: the 3-credit cost and the shape of what comes back (source links plus a section count). It doesn't mention rate limits or auth, but those are not implied by the read-only annotations either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the return content is front-loaded, then the selection condition, then cost. No filler or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't enumerate return fields, and it still covers usage context, cost, and scope. An agent has everything needed to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already explains the act_id format and the chapter-derivability pitfall, so the description carries no additional parameter meaning. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — sourcing the plain-text, PDF and HTML renderings of one enactment plus its section count. It also explicitly distinguishes itself from the matched-section sibling ('rather than a matched section'), so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use condition ('when the user wants to read or cite the Act itself') and contrasts it with the matched-section alternative. It stops short of naming the sibling tool or stating exclusions beyond that contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a repealed Indian criminal code to the 2023 code that replaced it, section by section: IPC to BNS and CrPC to BNSS, in force from 1 July 2024. Pass either side ('ipc' or 'bns' both work). Use whenever a source, a pleading or the user cites an old section number, so you answer under the provision actually in force rather than the repealed one. 'iea'/'bsa' return 404 until that mapping lands. Cost: 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| act_code | Yes | `ipc` and `bns` return the same mapping, as do `crpc` and `bnss`. Case-insensitive. `iea` and `bsa` are accepted but return 404 until their mapping is available. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive and closed-world safety, so the bar is lower. The description still adds real context beyond them: a 1-credit cost, the 1 July 2024 in-force date, bidirectional input, and the failure mode for 'iea'/'bsa' (404).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each load-bearing: scope, effective date, usage trigger, known limitation, cost. Front-loaded with the mapping scope and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation. The description covers the effective date, bidirectionality, the accepted-but-unmapped codes, and the credit cost — everything an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 case-insensitivity, the ipc/bns and crpc/bnss equivalence, and the iea/bsa 404. The description restates the bidirectional behavior but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (map), specific resources (repealed IPC/CrPC to 2023 BNS/BNSS), and the granularity (section by section). This is clearly distinguishable from siblings like resolve_india_citation or get_act_section, which do not perform repealed-to-current mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Use whenever a source, a pleading or the user cites an old section number', plus a rationale. It also notes a when-not condition ('iea'/'bsa' return 404). It stops short of naming a sibling tool as the alternative for citation resolution, so it is clear context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
India corpus counts for acts and provisions, broken down by jurisdiction, regulator and status, plus coverage depth. Use when checking whether the corpus supports a question before searching or interpreting an empty result. The depth block distinguishes text coverage from much thinner parsed amendment coverage. actsClaimingAmendmentsWithoutEvents marks missing records, not an absence of amendments. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, non-destructive, closed-world), so the description correctly spends its words elsewhere: it discloses that the depth block separates text vs parsed amendment coverage and that actsClaimingAmendmentsWithoutEvents signals missing records rather than zero amendments. The 'Free' note adds a cost signal. These are genuine interpretation-level behaviors beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then usage, then two sharp caveats, with almost no padding. The trailing isolated 'Free' is a slightly awkward fragment but a useful cost flag, so structure is strong without being perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-structure explanation is not required; the description still covers purpose, usage triggers, and two field-level gotchas, which is adequate for a zero-parameter diagnostic tool. Only one of the output fields is called out by name, so some interpretive detail is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter meaning to convey and the baseline of 4 applies. Nothing in the description misrepresents or omits parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: corpus counts for acts and provisions, with named dimensions (jurisdiction, regulator, status) and coverage depth. This is clearly distinct from the sibling search/list_acts/resolve tools, so an agent can place it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when: 'before searching' and 'when interpreting an empty result' — two concrete triggering scenarios. It does not name an alternative tool explicitly (e.g. list_act_filters), so it stops short of the full when/when-not/alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account-wide spendable credit balance shared by the India and United States APIs. Use for pre-flight checks or low-balance alerts from an India workflow. This returns the same balance as get_credit_balance, not a separate India allowance. Check bySource before assuming credits will last. Subscription credits expire at the period end. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, closed-world behavior. The description adds non-obvious semantics: subscription credits expire at period end, and the balance should not be assumed sufficient without consulting bySource. It does not cover auth requirements, but that is a minor gap for a read-only numeric lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and scope, and each clause carries distinct information (equivalence, use case, expiry caveat, cost). The trailing 'Free.' fragment is slightly abrupt but delivers useful cost context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required; the description still flags the bySource field as the thing to inspect. For a no-param read-only lookup, the agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics for the description to add. Baseline for a parameterless tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (account-wide spendable credit balance) with scope qualifiers (shared by India and US APIs) and explicitly clarifies it is not a separate India allowance. An agent can distinguish this from get_credit_balance purely from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case (pre-flight checks, low-balance alerts from an India workflow) and names the equivalent sibling tool, so the agent knows this is not a distinct allowance worth querying separately. Nothing about when to reach for it is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Credit-to-price conversion and per-endpoint costs for the India legislation API, billed in US dollars. Use when estimating a workflow or comparing endpoint charges. Set region to US for United States primary-law pricing instead. Both surfaces use the same API key and account-wide credit balance. No authentication is required.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Defaults to the jurisdiction of the documentation you are reading. If omitted, returns pricing only for that jurisdiction's endpoints, not prices across jurisdictions. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds non-obvious operational context: billing is in USD, both jurisdictions share one API key and account-wide credit balance, and no authentication is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose and cost scope before usage and the region note. The closing 'No authentication is required' is mildly redundant given the read-only annotations, but each sentence otherwise carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, and annotations cover the safety profile. Purpose, timing, cross-jurisdiction behavior, and auth expectations are all present; only explicit sibling disambiguation against get_india_credit_balance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the region parameter's default and scoping behavior are fully documented in the schema. The description echoes this ('Set region to US...') but adds no syntax, format, or edge-case detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (credit-to-price conversion and per-endpoint costs for the India legislation API) and its billing unit (US dollars), so the agent knows exactly what it returns. It does not explicitly differentiate itself from the similarly-named sibling get_india_credit_balance, which is the main gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage context ('estimating a workflow or comparing endpoint charges') and cross-jurisdiction guidance via the region parameter. There is no explicit when-not or named alternative tool, but the conditional redirect to US pricing is a genuine routing instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Paged inbound citations from provisions elsewhere in the corpus that name an act. Use when finding provisions that mention the act, rather than following its outbound references. Matching uses the act's title, not its identifier, so title variants and line breaks can be missed. Read matchBasis and treat results as a floor. total counts distinct citing provisions across all pages. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), but the description adds substantial beyond-schema behavior: title-based matching that can miss variants and line breaks, an instruction to read matchBasis and treat results as a floor, the meaning of total across pages, and a credit cost of 2. This is rich recall/pagination/cost disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded sentences: purpose first, then the usage disambiguation, then matching caveats, then pagination semantics and cost. Every sentence carries distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't explain return shape, and it still volunteers the critical caveats an agent needs (title-match recall risk, matchBasis, floor interpretation, per-page total). Nothing material is missing for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so page, limit, pageSize, and act_id are all documented in the schema itself. The description adds only the semantics of the returned total, not parameter guidance, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (paged inbound citations naming an act) and immediately disambiguates direction by contrasting with 'following its outbound references.' An agent can distinguish this from sibling reference tools like india_section_references or get_corresponding_provisions without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('finding provisions that mention the act') and implicitly excludes the outbound direction, which is clear context. It stops short of naming the specific sibling tool to use for outbound references, so it isn't fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extracted defined terms and their defining provisions, plus a separate definitionSections list. Use when a question turns on an act's own meaning of a term. Extraction covers only a minority of acts, so an empty result does not mean the act defines nothing. definitionSections identifies provisions to read even without extracted terms. terms is paged, but definitionSections is not. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/openWorldHint=false/destructiveHint=false already covering the safety profile, the description adds non-obvious behavior: partial extraction coverage, the cost of 2 credits, and the asymmetric pagination (terms paged, definitionSections not). It doesn't explain return shape, but that's largely covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then caveats and cost. Five short clauses with no wasted filler, though the terse fragment style ('terms is paged, but definitionSections is not. Cost: 2 credits.') is compact to the point of choppiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't be explained. Combined with annotations, the description covers coverage limits, cost, pagination asymmetry, and the fallback field — enough for correct invocation. One gap: it doesn't reconcile the act_id parameter (schema example/detail drift toward section identifiers) which could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3; the schema already documents page, limit, pageSize and act_id. The description's mention that 'terms is paged, but definitionSections is not' adds useful scoping context but no new syntax for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: extracts defined terms with their defining provisions, plus a separate definitionSections list. An agent can distinguish it from generic section/text siblings like get_act_text or get_act_section_body. It doesn't explicitly name an alternative tool, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition ('when a question turns on an act's own meaning of a term'), plus an important when-not-to-conclude rule: empty results don't mean the act defines nothing since extraction covers only a minority of acts. It also tells the agent to fall back to definitionSections when terms are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paged rules, regulations, notifications and orders the publisher records as made under an act. Use when looking beyond the parent statute to its subordinate instruments. Matching uses the parent's title, not parent_act_id, which is an India Code identifier that does not address this corpus. Check matchBasis. total counts distinct instruments across all pages, while returned counts rows on this page. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe read-only, non-open-world operation, and the description adds genuinely useful behavior beyond that: the parent-title matching quirk (with a nudge to check matchBasis), the distinction that 'total counts distinct instruments across all pages, while returned counts rows on this page', and a stated cost of 2 credits. It does not cover failure modes for unmatched titles or rate limits, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Everything is front-loaded – purpose first, then the matching caveat, then the count semantics and cost. Each sentence carries information, though the compressed phrasing ('Matching uses the parent's title, not parent_act_id') is dense and relies on the reader parsing a negation mid-sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is not required, and the description still usefully clarifies the total/returned fields. Combined with paging, cost, and the matching caveat, an agent has enough to invoke it correctly; only edge-case behavior (e.g., what happens when no subordinate instruments match) is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: it warns that matching uses the parent's title, not parent_act_id, which resolves ambiguity left by the act_id schema text (whose examples and wording reference section/USC citation ids). It does not document page/limit/pageSize, which the schema already handles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource combination – paged rules, regulations, notifications and orders made under an act – and its scope ('subordinate instruments') clearly distinguishes it from siblings like get_act_text, get_act_amendments, and get_act_structure, which address the parent statute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use condition ('Use when looking beyond the parent statute to its subordinate instruments') and a crucial caveat about matching by parent title rather than parent_act_id. It stops short of naming specific alternative tools to prefer in other circumstances, so it is clear context but not full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 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`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Self-describing filter vocabulary: every category, state, department and status the acts corpus actually holds, with counts. Call this before filtering, so a query uses a value that exists instead of returning empty because the spelling was wrong.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the values returned reflect what the corpus 'actually holds', counts are included, and it is positioned as a pre-flight lookup — details annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The nature of the output is front-loaded and the operational instruction follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-format details are not required here, and with no parameters there are no input semantics left unexplained. For a zero-arg, read-only vocabulary lookup, the description covers purpose, usage timing and payoff completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly makes no parameter claims that would be redundant with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (the filter vocabulary) and enumerates exactly what it contains: category, state, department and status values with counts. No sibling tool does this, so an agent can identify it immediately from the name plus description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance ('call this before filtering') and explains the concrete failure it prevents (empty results from a misspelled value). It does not name which filtering siblings it should precede, but the trigger condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and filter enactments rather than searching their text: by jurisdiction (central or a state), issuing regulator, year and status. Use when the user wants to know WHAT exists in an area before asking what it says, or to confirm an Act's exact title before citing it. Cost: 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number. | |
| sort | No | Sort order. `popular` is DEPRECATED and behaves as `year_desc`: it ordered by a read counter held only in the retired store. Values: `year_desc`, `year_asc`, `title_asc`, `title_desc`, `popular`. | year_desc |
| state | No | Jurisdiction slug. `central` is a value here, for Union legislation. Live counts per jurisdiction are on GET /acts/coverage. | |
| search | No | Keep only acts whose title contains this substring, matched case-insensitively. A title filter, not a search over the text: use POST /acts/search for that. | |
| status | No | The publisher's lifecycle status for the act. Their claim, not our verdict: see GET /acts/{actId}/status. Values: `in_force`, `repealed`, `superseded`, `spent`. | |
| yearTo | No | Latest year of enactment to include, inclusive. | |
| category | No | Jurisdictional class of the instrument. `repealed` and `spent` are accepted for backward compatibility and resolve against the act's status instead. Values: `central`, `state`, `regulatory`, `repealed`, `spent`. | |
| pageSize | No | Results per page (1-100). | |
| yearFrom | No | Earliest year of enactment to include, inclusive. Matched against the publisher's own year field, which is occasionally corrupt, so there is no lower bound and a value below 1800 is a legitimate way to find those rows. | |
| department | No | Accepts both regulator slugs such as `sebi` and `rbi` and free-text state department names such as `Law Department`. Values are not limited to a fixed enum or a uniform slug format. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
The provision named by an Indian legal citation, accepting common abbreviations and flexible element order. Use when a user provides a citation rather than a research topic, such as s.302 IPC, O. 39 R. 1 CPC or Art. 21 of the Constitution. Subsection and clause references are supported. Malformed citations are rejected rather than reported as not found. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| cite | Yes | One citation string. | |
| state | No | Narrow to one jurisdiction. Required for a State-universal title, where the same short title names a different act in each State. | |
| asAtDate | No | The date the conduct or document belongs to, as YYYY-MM-DD. This is how a caller says which side of the 2023 recodification they mean: without it, a criminal section number resolves to BOTH the old code and its replacement, because both are live law. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Provision resolutions for a list of Indian legal citations, using the same resolver as resolve_india_citation. Use when several citations need resolving without individual calls. Accepts up to 50 distinct citations and 500 entries before deduplication. One citation failing does not invalidate the others. Unknown request fields are rejected rather than ignored. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Narrow to one jurisdiction. Required for a State-universal title. | |
| asAtDate | No | The date the conduct or document belongs to, as YYYY-MM-DD. This is how a caller says which side of the 2023 recodification they mean: without it, a criminal section number resolves to BOTH the old code and its replacement, because both are live law. | |
| citations | Yes | Citation strings, as a lawyer would type them. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Generic corpus search over Indian Central and State legislation, returning {id, title, url} records for citation. Present so this server works in clients that require the standard search/fetch pair. Prefer search_acts if you can call it: it filters by category, state, year and status. Pair with fetch to read a result.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: this tool exists for client compatibility with the standard search/fetch pair, framing it as a fallback rather than a preferred path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no filler, and the fallback positioning plus the preferred alternative are front-loaded. It does restate the return shape that the output schema already provides, a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value detail is not required, and the description still adds the fallback rationale and the search_acts alternative. The only real omission is query input semantics, which is the gap the zero-coverage parameter leaves open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required 'query' parameter, so the description must carry that burden. It only calls the search 'generic' and never explains what the query accepts (free text, keywords, citation strings) or how matches are ranked, leaving the agent to guess at input syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('generic corpus search over Indian Central and State legislation') plus the return shape, and explicitly contrasts itself with the sibling search_acts. An agent can distinguish it from the other ~20 siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing guidance ('Prefer search_acts if you can call it: it filters by category, state, year and status') and states the follow-up action ('Pair with fetch to read a result'). This is exactly the when/when-not/alternative structure a high score requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Indian legislation down to the individual section: Central and State Acts plus the instruments of the principal regulators (SEBI, RBI, MCA, IRDAI, TRAI, DGFT). Use for any 'what does Indian law say' question. Supports boolean and phrase queries; filters by category, state, year and status. Returns sections with title, chapter and a sourceUrl pointing at the publisher's own document. The returned actId (e.g. 'IND_central_2065') feeds every acts tool. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number. `page * pageSize` may not exceed 100; narrow the query with filters to reach deeper matches. | |
| query | Yes | Search query. | |
| state | No | Jurisdiction slug. `central` is a value here, for Union legislation. Live counts per jurisdiction are on GET /acts/coverage. | |
| yearTo | No | Latest year of enactment to include, inclusive. | |
| actTitle | No | Filter by words in the act's title. Each word must appear, so `Bharatiya Nyaya` narrows to the Sanhita. | |
| category | No | Jurisdictional class. `repealed` and `spent` are accepted for backward compatibility and resolve against `actStatus` instead. Values: `central`, `state`, `regulatory`, `repealed`, `spent`. | |
| pageSize | No | Results per page (1-50). | |
| yearFrom | No | Earliest year of enactment to include, inclusive. Matched against the publisher's own year field, which is occasionally corrupt, so there is no lower bound and a value below 1800 is a legitimate way to find those rows. | |
| actStatus | No | Filter by the publisher's lifecycle status. Accepts one value or a list. This is the publisher's claim, not our verdict: see GET /acts/{actId}/status. Values: `in_force`, `repealed`, `superseded`, `spent`. | |
| matchType | No | One of `any`, `all`, `phrase`. Filters ranked candidates rather than re-querying the index, so `phrase` matches only within the top candidates and not every corpus match. Narrow with structured filters first when you need exhaustive phrase results. Defaults to `any`. | any |
| department | No | Accepts both regulator slugs such as `sebi` and `rbi` and free-text state department names such as `Law Department`. Values are not limited to a fixed enum or a uniform slug format. | |
| sectionType | No | Filter by structural kind of the passage. Accepts one value or a list. Values: `amendment_provision`, `article`, `body`, `chapter_heading`, `definition_clause`, `definitions`, `part_heading`, `preamble`, `schedule`, `section`, `short_title`, `sub_section`. | |
| legalSubject | No | Accepts one value or a list, matched against subject classifications assigned at ingest. | |
| isSubordinate | No | True for subordinate instruments only (rules, notifications, circulars, orders); false for principal acts only. Omit for both. | |
| provisionType | No | Filter by what the provision DOES. Accepts one value or a list. Values: `mandatory`, `general`, `prohibitory`, `overriding`, `discretionary`, `declaratory`. | |
| sectionNumber | No | Filter by exact section number. The publisher's own numbering, which is not an integer: `498A`, `376DA` and `2-A` all occur, and the alphabetic suffix is part of the number rather than a sub-provision. | |
| excludeRepealed | No | Drop provisions whose act the publisher records as repealed or spent. Off by default, because repealed law is still law that was in force and is routinely the thing being researched. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_act_amendments2 fields changedInput schema / properties / type / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "substitution",
+ "insertion",
+ "omission",
+ "renumbering",
+ "addition",
+ "repeal",
+ "deletion",
+ "adaptation",
+ "amendment",
+ "note"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / type / enumRemoved value: -[
- "substitution",
- "insertion",
- "omission",
- "renumbering",
- "addition",
- "repeal",
- "deletion",
- "adaptation",
- "amendment",
- "note"
-]list_acts6 fields changedInput schema / properties / category / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "central",
+ "state",
+ "regulatory",
+ "repealed",
+ "spent"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / category / enumRemoved value: -[
- "central",
- "state",
- "regulatory",
- "repealed",
- "spent"
-]Input schema / properties / state / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "andaman-and-nicobar-islands",
+ "andaman-nicobar",
+ "andhra-pradesh",
+ "arunachal-pradesh",
+ "assam",
+ "bihar",
+ "central",
+ "chandigarh",
+ "chhattisgarh",
+ "dadra-and-nagar-haveli-and-daman-and-diu",
+ "dadra-nagar-haveli",
+ "delhi",
+ "goa",
+ "gujarat",
+ "haryana",
+ "himachal-pradesh",
+ "jammu-and-kashmir",
+ "jammu-kashmir",
+ "jharkhand",
+ "karnataka",
+ "kerala",
+ "ladakh",
+ "lakshadweep",
+ "madhya-pradesh",
+ "maharashtra",
+ "manipur",
+ "meghalaya",
+ "mizoram",
+ "nagaland",
+ "odisha",
+ "puducherry",
+ "punjab",
+ "rajasthan",
+ "sikkim",
+ "tamil-nadu",
+ "telangana",
+ "tripura",
+ "uttar-pradesh",
+ "uttarakhand",
+ "west-bengal"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / state / enumRemoved value: -[
- "andaman-and-nicobar-islands",
- "andaman-nicobar",
- "andhra-pradesh",
- "arunachal-pradesh",
- "assam",
- "bihar",
- "central",
- "chandigarh",
- "chhattisgarh",
- "dadra-and-nagar-haveli-and-daman-and-diu",
- "dadra-nagar-haveli",
- "delhi",
- "goa",
- "gujarat",
- "haryana",
- "himachal-pradesh",
- "jammu-and-kashmir",
- "jammu-kashmir",
- "jharkhand",
- "karnataka",
- "kerala",
- "ladakh",
- "lakshadweep",
- "madhya-pradesh",
- "maharashtra",
- "manipur",
- "meghalaya",
- "mizoram",
- "nagaland",
- "odisha",
- "puducherry",
- "punjab",
- "rajasthan",
- "sikkim",
- "tamil-nadu",
- "telangana",
- "tripura",
- "uttar-pradesh",
- "uttarakhand",
- "west-bengal"
-]Input schema / properties / status / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "in_force",
+ "repealed",
+ "superseded",
+ "spent"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / status / enumRemoved value: -[
- "in_force",
- "repealed",
- "superseded",
- "spent"
-]resolve_india_citation2 fields changedInput schema / properties / state / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "andaman-and-nicobar-islands",
+ "andaman-nicobar",
+ "andhra-pradesh",
+ "arunachal-pradesh",
+ "assam",
+ "bihar",
+ "central",
+ "chandigarh",
+ "chhattisgarh",
+ "dadra-and-nagar-haveli-and-daman-and-diu",
+ "dadra-nagar-haveli",
+ "delhi",
+ "goa",
+ "gujarat",
+ "haryana",
+ "himachal-pradesh",
+ "jammu-and-kashmir",
+ "jammu-kashmir",
+ "jharkhand",
+ "karnataka",
+ "kerala",
+ "ladakh",
+ "lakshadweep",
+ "madhya-pradesh",
+ "maharashtra",
+ "manipur",
+ "meghalaya",
+ "mizoram",
+ "nagaland",
+ "odisha",
+ "puducherry",
+ "punjab",
+ "rajasthan",
+ "sikkim",
+ "tamil-nadu",
+ "telangana",
+ "tripura",
+ "uttar-pradesh",
+ "uttarakhand",
+ "west-bengal"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / state / enumRemoved value: -[
- "andaman-and-nicobar-islands",
- "andaman-nicobar",
- "andhra-pradesh",
- "arunachal-pradesh",
- "assam",
- "bihar",
- "central",
- "chandigarh",
- "chhattisgarh",
- "dadra-and-nagar-haveli-and-daman-and-diu",
- "dadra-nagar-haveli",
- "delhi",
- "goa",
- "gujarat",
- "haryana",
- "himachal-pradesh",
- "jammu-and-kashmir",
- "jammu-kashmir",
- "jharkhand",
- "karnataka",
- "kerala",
- "ladakh",
- "lakshadweep",
- "madhya-pradesh",
- "maharashtra",
- "manipur",
- "meghalaya",
- "mizoram",
- "nagaland",
- "odisha",
- "puducherry",
- "punjab",
- "rajasthan",
- "sikkim",
- "tamil-nadu",
- "telangana",
- "tripura",
- "uttar-pradesh",
- "uttarakhand",
- "west-bengal"
-]resolve_india_citations_batch2 fields changedInput schema / properties / state / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "andaman-and-nicobar-islands",
+ "andaman-nicobar",
+ "andhra-pradesh",
+ "arunachal-pradesh",
+ "assam",
+ "bihar",
+ "central",
+ "chandigarh",
+ "chhattisgarh",
+ "dadra-and-nagar-haveli-and-daman-and-diu",
+ "dadra-nagar-haveli",
+ "delhi",
+ "goa",
+ "gujarat",
+ "haryana",
+ "himachal-pradesh",
+ "jammu-and-kashmir",
+ "jammu-kashmir",
+ "jharkhand",
+ "karnataka",
+ "kerala",
+ "ladakh",
+ "lakshadweep",
+ "madhya-pradesh",
+ "maharashtra",
+ "manipur",
+ "meghalaya",
+ "mizoram",
+ "nagaland",
+ "odisha",
+ "puducherry",
+ "punjab",
+ "rajasthan",
+ "sikkim",
+ "tamil-nadu",
+ "telangana",
+ "tripura",
+ "uttar-pradesh",
+ "uttarakhand",
+ "west-bengal"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / state / enumRemoved value: -[
- "andaman-and-nicobar-islands",
- "andaman-nicobar",
- "andhra-pradesh",
- "arunachal-pradesh",
- "assam",
- "bihar",
- "central",
- "chandigarh",
- "chhattisgarh",
- "dadra-and-nagar-haveli-and-daman-and-diu",
- "dadra-nagar-haveli",
- "delhi",
- "goa",
- "gujarat",
- "haryana",
- "himachal-pradesh",
- "jammu-and-kashmir",
- "jammu-kashmir",
- "jharkhand",
- "karnataka",
- "kerala",
- "ladakh",
- "lakshadweep",
- "madhya-pradesh",
- "maharashtra",
- "manipur",
- "meghalaya",
- "mizoram",
- "nagaland",
- "odisha",
- "puducherry",
- "punjab",
- "rajasthan",
- "sikkim",
- "tamil-nadu",
- "telangana",
- "tripura",
- "uttar-pradesh",
- "uttarakhand",
- "west-bengal"
-]search_acts12 fields changedInput schema / properties / actStatus / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "in_force",
+ "repealed",
+ "superseded",
+ "spent"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "in_force",
+ "repealed",
+ "superseded",
+ "spent"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / actStatus / enumRemoved value: -[
- "in_force",
- "repealed",
- "superseded",
- "spent"
-]Input schema / properties / category / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "central",
+ "state",
+ "regulatory",
+ "repealed",
+ "spent"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / category / enumRemoved value: -[
- "central",
- "state",
- "regulatory",
- "repealed",
- "spent"
-]Input schema / properties / legalSubject / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "administrative_law",
+ "banking_finance",
+ "civil_procedure",
+ "constitutional_law",
+ "corporate_law",
+ "criminal_law",
+ "environmental_law",
+ "family_law",
+ "general",
+ "information_technology",
+ "intellectual_property",
+ "labour_law",
+ "property_law",
+ "tax_law"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "administrative_law",
+ "banking_finance",
+ "civil_procedure",
+ "constitutional_law",
+ "corporate_law",
+ "criminal_law",
+ "environmental_law",
+ "family_law",
+ "general",
+ "information_technology",
+ "intellectual_property",
+ "labour_law",
+ "property_law",
+ "tax_law"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / legalSubject / enumRemoved value: -[
- "administrative_law",
- "banking_finance",
- "civil_procedure",
- "constitutional_law",
- "corporate_law",
- "criminal_law",
- "environmental_law",
- "family_law",
- "general",
- "information_technology",
- "intellectual_property",
- "labour_law",
- "property_law",
- "tax_law"
-]Input schema / properties / provisionType / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "mandatory",
+ "general",
+ "prohibitory",
+ "overriding",
+ "discretionary",
+ "declaratory"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "mandatory",
+ "general",
+ "prohibitory",
+ "overriding",
+ "discretionary",
+ "declaratory"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / provisionType / enumRemoved value: -[
- "mandatory",
- "general",
- "prohibitory",
- "overriding",
- "discretionary",
- "declaratory"
-]Input schema / properties / sectionType / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "amendment_provision",
+ "article",
+ "body",
+ "chapter_heading",
+ "definition_clause",
+ "definitions",
+ "part_heading",
+ "preamble",
+ "schedule",
+ "section",
+ "short_title",
+ "sub_section"
+ ],
+ "type": "string"
+ },
+ {
+ "items": {
+ "enum": [
+ "amendment_provision",
+ "article",
+ "body",
+ "chapter_heading",
+ "definition_clause",
+ "definitions",
+ "part_heading",
+ "preamble",
+ "schedule",
+ "section",
+ "short_title",
+ "sub_section"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sectionType / enumRemoved value: -[
- "amendment_provision",
- "article",
- "body",
- "chapter_heading",
- "definition_clause",
- "definitions",
- "part_heading",
- "preamble",
- "schedule",
- "section",
- "short_title",
- "sub_section"
-]Input schema / properties / state / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "andaman-and-nicobar-islands",
+ "andaman-nicobar",
+ "andhra-pradesh",
+ "arunachal-pradesh",
+ "assam",
+ "bihar",
+ "central",
+ "chandigarh",
+ "chhattisgarh",
+ "dadra-and-nagar-haveli-and-daman-and-diu",
+ "dadra-nagar-haveli",
+ "delhi",
+ "goa",
+ "gujarat",
+ "haryana",
+ "himachal-pradesh",
+ "jammu-and-kashmir",
+ "jammu-kashmir",
+ "jharkhand",
+ "karnataka",
+ "kerala",
+ "ladakh",
+ "lakshadweep",
+ "madhya-pradesh",
+ "maharashtra",
+ "manipur",
+ "meghalaya",
+ "mizoram",
+ "nagaland",
+ "odisha",
+ "puducherry",
+ "punjab",
+ "rajasthan",
+ "sikkim",
+ "tamil-nadu",
+ "telangana",
+ "tripura",
+ "uttar-pradesh",
+ "uttarakhand",
+ "west-bengal"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / state / enumRemoved value: -[
- "andaman-and-nicobar-islands",
- "andaman-nicobar",
- "andhra-pradesh",
- "arunachal-pradesh",
- "assam",
- "bihar",
- "central",
- "chandigarh",
- "chhattisgarh",
- "dadra-and-nagar-haveli-and-daman-and-diu",
- "dadra-nagar-haveli",
- "delhi",
- "goa",
- "gujarat",
- "haryana",
- "himachal-pradesh",
- "jammu-and-kashmir",
- "jammu-kashmir",
- "jharkhand",
- "karnataka",
- "kerala",
- "ladakh",
- "lakshadweep",
- "madhya-pradesh",
- "maharashtra",
- "manipur",
- "meghalaya",
- "mizoram",
- "nagaland",
- "odisha",
- "puducherry",
- "punjab",
- "rajasthan",
- "sikkim",
- "tamil-nadu",
- "telangana",
- "tripura",
- "uttar-pradesh",
- "uttarakhand",
- "west-bengal"
-]get_act_section1 field changedInput schema / properties / section_number / descriptionPrevious 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`."get_act_section_body1 field changedInput schema / properties / section_number / descriptionPrevious 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`."get_section_history1 field changedInput schema / properties / section_number / descriptionPrevious 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`."india_section_references1 field changedInput schema / properties / section_number / descriptionPrevious 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`."get_act_amendments1 field changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"get_act_section3 fields changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"Input schema / properties / section_number / descriptionPrevious 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`."Input schema / properties / section_number / patternPrevious value: -"^[A-Za-z0-9().\\- ]{1,40}$"New value: +"^[^/\\\\\\x00-\\x1f]{1,40}$"get_act_section_body3 fields changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"Input schema / properties / section_number / descriptionPrevious 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`."Input schema / properties / section_number / patternPrevious value: -"^[A-Za-z0-9().\\- ]{1,40}$"New value: +"^[^/\\\\\\x00-\\x1f]{1,40}$"get_act_status1 field changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"get_act_structure1 field changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"get_act_text1 field changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"get_section_history3 fields changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"Input schema / properties / section_number / descriptionPrevious 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`."Input schema / properties / section_number / patternPrevious value: -"^[A-Za-z0-9().\\- ]{1,40}$"New value: +"^[^/\\\\\\x00-\\x1f]{1,40}$"india_act_cited_by1 field changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"india_act_definitions1 field changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"india_act_subordinate1 field changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"india_section_references3 fields changedInput schema / properties / act_id / patternPrevious value: -"^[a-zA-Z0-9_-]+$"New value: +"^[^/\\\\\\x00-\\x1f]+$"Input schema / properties / section_number / descriptionPrevious 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`."Input schema / properties / section_number / patternPrevious value: -"^[A-Za-z0-9().\\- ]{1,40}$"New value: +"^[^/\\\\\\x00-\\x1f]{1,40}$"get_act_amendments1 field changedInput schema / properties / type / descriptionPrevious 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`."New value: +"Action classes are returned in nominal form, but filters accept both nominal and stored verbal spellings. For example, `substitution` and `substituted` are both accepted."get_corresponding_provisions1 field changedInput schema / properties / act_code / descriptionPrevious value: -"Either side of a recodification pair, matched case-insensitively so `IPC` and `ipc` are the same request. `ipc`/`bns` and `crpc`/`bnss` each return the same mapping; `iea`/`bsa` are accepted and 404 until that mapping lands. Values: `ipc`, `crpc`, `iea`, `bns`, `bnss`, `bsa`."New value: +"`ipc` and `bns` return the same mapping, as do `crpc` and `bnss`. Case-insensitive. `iea` and `bsa` are accepted but return 404 until their mapping is available."get_pricing_in1 field changedInput schema / properties / region / descriptionPrevious value: -"Jurisdiction to price. `US` for the United States primary-law surface, `IN` for the India legislation surface. Defaults to the jurisdiction of the document you are reading, so a caller who does not set it gets the prices for the endpoints that document describes and nothing else."New value: +"Defaults to the jurisdiction of the documentation you are reading. If omitted, returns pricing only for that jurisdiction's endpoints, not prices across jurisdictions."list_acts1 field changedInput schema / properties / department / descriptionPrevious value: -"Issuing body. Deliberately NOT an enumerated list: this field holds 943 distinct values and mixes clean regulator slugs (`sebi`, `rbi`, `moefcc`) with free-text state department names (`Law Department`). Read GET /acts/filters for the values with the most data behind them."New value: +"Accepts both regulator slugs such as `sebi` and `rbi` and free-text state department names such as `Law Department`. Values are not limited to a fixed enum or a uniform slug format."search_acts3 fields changedInput schema / properties / department / descriptionPrevious value: -"Issuing body. Deliberately NOT an enumerated list: this field holds 943 distinct values and mixes clean regulator slugs (`sebi`, `rbi`, `moefcc`) with free-text state department names (`Law Department`). Read GET /acts/filters for the values with the most data behind them."New value: +"Accepts both regulator slugs such as `sebi` and `rbi` and free-text state department names such as `Law Department`. Values are not limited to a fixed enum or a uniform slug format."Input schema / properties / legalSubject / descriptionPrevious value: -"Filter by subject area, classified at ingest. Accepts one value or a list. Values: `administrative_law`, `banking_finance`, `civil_procedure`, `constitutional_law`, `corporate_law`, `criminal_law`, `environmental_law`, `family_law`, `general`, `information_technology`, `intellectual_property`, `labour_law`, `property_law`, `tax_law`."New value: +"Accepts one value or a list, matched against subject classifications assigned at ingest."Input schema / properties / matchType / descriptionPrevious value: -"How query terms must appear in the provision text. `any` (the default) leaves hybrid ranking to do the work; `all` keeps only provisions containing EVERY query term; `phrase` keeps only those containing the exact phrase.\n\n⚠️ It narrows the ranked candidate pool rather than re-querying the index, so a `phrase` search returns phrase matches WITHIN the top candidates, not every phrase match in the corpus. For an exhaustive phrase search, narrow with the structured filters first.\n\nValues: `any`, `all`, `phrase`."New value: +"One of `any`, `all`, `phrase`. Filters ranked candidates rather than re-querying the index, so `phrase` matches only within the top candidates and not every corpus match. Narrow with structured filters first when you need exhaustive phrase results. Defaults to `any`."get_india_credit_balanceget_act_amendments9 fields changedInput schema / properties / act_id / examplesAdded value: +[
+ "IND_state_20326"
+]Input schema / properties / page / descriptionPrevious value: -"Page number"New value: +"1-based page number."Input schema / properties / page / examplesAdded value: +[
+ 1
+]Input schema / properties / pageSize / descriptionPrevious value: -"Results per page"New value: +"Results per page (1-200)."Input schema / properties / pageSize / examplesAdded value: +[
+ 100
+]Input schema / properties / section / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 40,
+ "pattern": "^[A-Za-z0-9().\\- ]{1,40}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / section / descriptionPrevious 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."Input schema / properties / section / examplesAdded value: +[
+ "23"
+]Input schema / properties / type / descriptionPrevious 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`."get_corresponding_provisions3 fields changedInput schema / properties / act_code / descriptionPrevious value: -"Act code: ipc, crpc, iea, bns, bnss or bsa"New value: +"Either side of a recodification pair, matched case-insensitively so `IPC` and `ipc` are the same request. `ipc`/`bns` and `crpc`/`bnss` each return the same mapping; `iea`/`bsa` are accepted and 404 until that mapping lands. Values: `ipc`, `crpc`, `iea`, `bns`, `bnss`, `bsa`."Input schema / properties / act_code / enumAdded value: +[
+ "ipc",
+ "crpc",
+ "iea",
+ "bns",
+ "bnss",
+ "bsa"
+]Input schema / properties / act_code / examplesAdded value: +[
+ "ipc"
+]get_section_history2 fields changedInput schema / properties / asOf / formatAdded value: +"date"Input schema / properties / section_number / descriptionAdded 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."india_act_cited_by8 fields changedInput schema / properties / limit / anyOfAdded value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / limit / defaultRemoved value: -25Input schema / properties / limit / descriptionPrevious 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."Input schema / properties / limit / maximumRemoved value: -100Input schema / properties / limit / minimumRemoved value: -1Input schema / properties / limit / typeRemoved value: -"integer"Input schema / properties / pageAdded value: +{
+ "default": 1,
+ "description": "1-based page number.",
+ "examples": [
+ 1
+ ],
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / pageSizeAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Rows per page (1-100). Defaults to 25.",
+ "examples": [
+ 25
+ ]
+}india_act_definitions4 fields changedInput schema / properties / act_id / examplesPrevious value: -[
- "IND_state_17068"
-]New value: +[
+ "IND_central_2114"
+]Input schema / properties / limitAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "DEPRECATED alias for `pageSize`, kept working for clients written against the original shape. Send one or the other, not both.",
+ "examples": [
+ 25
+ ]
+}Input schema / properties / pageAdded value: +{
+ "default": 1,
+ "description": "1-based page number.",
+ "examples": [
+ 1
+ ],
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / pageSizeAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Rows per page (1-100). Defaults to 25.",
+ "examples": [
+ 25
+ ]
+}india_act_subordinate8 fields changedInput schema / properties / limit / anyOfAdded value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / limit / defaultRemoved value: -25Input schema / properties / limit / descriptionPrevious 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."Input schema / properties / limit / maximumRemoved value: -100Input schema / properties / limit / minimumRemoved value: -1Input schema / properties / limit / typeRemoved value: -"integer"Input schema / properties / pageAdded value: +{
+ "default": 1,
+ "description": "1-based page number.",
+ "examples": [
+ 1
+ ],
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / pageSizeAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Rows per page (1-100). Defaults to 25.",
+ "examples": [
+ 25
+ ]
+}india_section_references1 field changedInput schema / properties / section_number / descriptionAdded 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."list_acts17 fields changedInput schema / properties / category / descriptionPrevious value: -"Jurisdictional class."New value: +"Jurisdictional class of the instrument. `repealed` and `spent` are accepted for backward compatibility and resolve against the act's status instead. Values: `central`, `state`, `regulatory`, `repealed`, `spent`."Input schema / properties / department / descriptionPrevious value: -"Issuing body. Free text rather than a list: 943 distinct values, mixing regulator slugs with state department names. See GET /acts/filters."New value: +"Issuing body. Deliberately NOT an enumerated list: this field holds 943 distinct values and mixes clean regulator slugs (`sebi`, `rbi`, `moefcc`) with free-text state department names (`Law Department`). Read GET /acts/filters for the values with the most data behind them."Input schema / properties / page / descriptionPrevious value: -"Page number"New value: +"1-based page number."Input schema / properties / page / examplesAdded value: +[
+ 1
+]Input schema / properties / pageSize / descriptionPrevious value: -"Results per page (1-100)"New value: +"Results per page (1-100)."Input schema / properties / pageSize / examplesAdded value: +[
+ 50
+]Input schema / properties / search / descriptionPrevious value: -"Filter by title substring"New value: +"Keep only acts whose title contains this substring, matched case-insensitively. A title filter, not a search over the text: use POST /acts/search for that."Input schema / properties / search / examplesAdded value: +[
+ "income tax"
+]Input schema / properties / sort / descriptionPrevious value: -"Sort order. `popular` is DEPRECATED and behaves as `year_desc`: it ordered by a read counter held only in the retired store."New value: +"Sort order. `popular` is DEPRECATED and behaves as `year_desc`: it ordered by a read counter held only in the retired store. Values: `year_desc`, `year_asc`, `title_asc`, `title_desc`, `popular`."Input schema / properties / state / descriptionPrevious value: -"Jurisdiction slug. `central` is a value here."New value: +"Jurisdiction slug. `central` is a value here, for Union legislation. Live counts per jurisdiction are on GET /acts/coverage."Input schema / properties / status / descriptionPrevious value: -"The publisher's lifecycle status for the act."New value: +"The publisher's lifecycle status for the act. Their claim, not our verdict: see GET /acts/{actId}/status. Values: `in_force`, `repealed`, `superseded`, `spent`."Input schema / properties / yearFrom / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 2100,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / yearFrom / descriptionPrevious value: -"Minimum year (inclusive)"New value: +"Earliest year of enactment to include, inclusive. Matched against the publisher's own year field, which is occasionally corrupt, so there is no lower bound and a value below 1800 is a legitimate way to find those rows."Input schema / properties / yearFrom / examplesAdded value: +[
+ 2015
+]Input schema / properties / yearTo / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 2100,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / yearTo / descriptionPrevious value: -"Maximum year (inclusive)"New value: +"Latest year of enactment to include, inclusive."Input schema / properties / yearTo / examplesAdded value: +[
+ 2024
+]resolve_india_citation3 fields changedInput schema / properties / asAtDate / descriptionPrevious value: -"Which side of the 2023 recodification you mean, as YYYY-MM-DD."New value: +"The date the conduct or document belongs to, as YYYY-MM-DD. This is how a caller says which side of the 2023 recodification they mean: without it, a criminal section number resolves to BOTH the old code and its replacement, because both are live law."Input schema / properties / asAtDate / formatAdded value: +"date"Input schema / properties / state / descriptionPrevious value: -"Narrow to one jurisdiction."New value: +"Narrow to one jurisdiction. Required for a State-universal title, where the same short title names a different act in each State."resolve_india_citations_batch1 field changedInput schema / properties / asAtDate / formatAdded value: +"date"search_acts13 fields changedInput schema / properties / actStatus / descriptionPrevious value: -"Filter by the publisher's lifecycle status: `in_force`, `repealed`, `superseded`, `spent`. Accepts one value or a list. This is the publisher's claim, not our verdict: see GET /acts/{actId}/status."New value: +"Filter by the publisher's lifecycle status. Accepts one value or a list. This is the publisher's claim, not our verdict: see GET /acts/{actId}/status. Values: `in_force`, `repealed`, `superseded`, `spent`."Input schema / properties / category / descriptionPrevious value: -"Jurisdictional class. `repealed` and `spent` are accepted for backward compatibility and resolve against `actStatus` instead."New value: +"Jurisdictional class. `repealed` and `spent` are accepted for backward compatibility and resolve against `actStatus` instead. Values: `central`, `state`, `regulatory`, `repealed`, `spent`."Input schema / properties / legalSubject / descriptionPrevious value: -"Filter by subject area, e.g. `tax_law`, `criminal_law`, `environmental_law`, `company_law`."New value: +"Filter by subject area, classified at ingest. Accepts one value or a list. Values: `administrative_law`, `banking_finance`, `civil_procedure`, `constitutional_law`, `corporate_law`, `criminal_law`, `environmental_law`, `family_law`, `general`, `information_technology`, `intellectual_property`, `labour_law`, `property_law`, `tax_law`."Input schema / properties / matchType / descriptionPrevious value: -"How query terms must appear in the provision text. `any` (the default) leaves hybrid ranking to do the work; `all` keeps only provisions containing EVERY query term; `phrase` keeps only those containing the exact phrase.\n\n⚠️ It narrows the ranked candidate pool rather than re-querying the index, so a `phrase` search returns phrase matches WITHIN the top candidates, not every phrase match in the corpus. For an exhaustive phrase search, narrow with the structured filters first."New value: +"How query terms must appear in the provision text. `any` (the default) leaves hybrid ranking to do the work; `all` keeps only provisions containing EVERY query term; `phrase` keeps only those containing the exact phrase.\n\n⚠️ It narrows the ranked candidate pool rather than re-querying the index, so a `phrase` search returns phrase matches WITHIN the top candidates, not every phrase match in the corpus. For an exhaustive phrase search, narrow with the structured filters first.\n\nValues: `any`, `all`, `phrase`."Input schema / properties / page / examplesAdded value: +[
+ 1
+]Input schema / properties / pageSize / descriptionPrevious value: -"Results per page (1-50)"New value: +"Results per page (1-50)."Input schema / properties / pageSize / examplesAdded value: +[
+ 10
+]Input schema / properties / provisionType / descriptionPrevious value: -"Filter by what the provision DOES: `definitional`, `prohibitory`, `procedural`, `penal`, `overriding` and others. Accepts a value or a list."New value: +"Filter by what the provision DOES. Accepts one value or a list. Values: `mandatory`, `general`, `prohibitory`, `overriding`, `discretionary`, `declaratory`."Input schema / properties / sectionType / descriptionPrevious value: -"Filter by structural kind: `section`, `sub_section`, `definitions`, `preamble`, `schedule`, `short_title`."New value: +"Filter by structural kind of the passage. Accepts one value or a list. Values: `amendment_provision`, `article`, `body`, `chapter_heading`, `definition_clause`, `definitions`, `part_heading`, `preamble`, `schedule`, `section`, `short_title`, `sub_section`."Input schema / properties / yearFrom / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 2100,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / yearFrom / descriptionPrevious value: -"Minimum year (inclusive)"New value: +"Earliest year of enactment to include, inclusive. Matched against the publisher's own year field, which is occasionally corrupt, so there is no lower bound and a value below 1800 is a legitimate way to find those rows."Input schema / properties / yearTo / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 2100,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / yearTo / descriptionPrevious value: -"Maximum year (inclusive)"New value: +"Latest year of enactment to include, inclusive."get_pricing_inindia_act_cited_byindia_act_definitionsindia_act_subordinateindia_section_referencesget_act_amendments3 fields changedInput schema / properties / type / descriptionPrevious 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."Input schema / properties / type / enumAdded value: +[
+ "substitution",
+ "insertion",
+ "omission",
+ "renumbering",
+ "addition",
+ "repeal",
+ "deletion",
+ "adaptation",
+ "amendment",
+ "note"
+]Input schema / properties / type / examplesAdded value: +[
+ "substitution"
+]get_act_sectionget_act_section_bodyget_act_statusget_act_structureget_act_text1 field changedInput schema / properties / act_id / examplesAdded value: +[
+ "IND_state_20326"
+]get_coverageget_section_historylist_acts14 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter: central, state, regulatory, repealed, spent"New value: +"Jurisdictional class."Input schema / properties / category / enumAdded value: +[
+ "central",
+ "state",
+ "regulatory",
+ "repealed",
+ "spent"
+]Input schema / properties / category / examplesAdded value: +[
+ "central"
+]Input schema / properties / department / descriptionPrevious value: -"Filter by regulatory body (e.g. 'sebi', 'rbi')"New value: +"Issuing body. Free text rather than a list: 943 distinct values, mixing regulator slugs with state department names. See GET /acts/filters."Input schema / properties / department / examplesAdded value: +[
+ "sebi"
+]Input schema / properties / sort / descriptionPrevious value: -"Sort: year_desc, year_asc, title_asc, title_desc, popular"New value: +"Sort order. `popular` is DEPRECATED and behaves as `year_desc`: it ordered by a read counter held only in the retired store."Input schema / properties / sort / enumAdded value: +[
+ "year_desc",
+ "year_asc",
+ "title_asc",
+ "title_desc",
+ "popular"
+]Input schema / properties / sort / examplesAdded value: +[
+ "title_asc"
+]Input schema / properties / state / descriptionPrevious value: -"Filter by state slug (e.g. 'maharashtra', 'delhi')"New value: +"Jurisdiction slug. `central` is a value here."Input schema / properties / state / enumAdded value: +[
+ "andaman-and-nicobar-islands",
+ "andaman-nicobar",
+ "andhra-pradesh",
+ "arunachal-pradesh",
+ "assam",
+ "bihar",
+ "central",
+ "chandigarh",
+ "chhattisgarh",
+ "dadra-and-nagar-haveli-and-daman-and-diu",
+ "dadra-nagar-haveli",
+ "delhi",
+ "goa",
+ "gujarat",
+ "haryana",
+ "himachal-pradesh",
+ "jammu-and-kashmir",
+ "jammu-kashmir",
+ "jharkhand",
+ "karnataka",
+ "kerala",
+ "ladakh",
+ "lakshadweep",
+ "madhya-pradesh",
+ "maharashtra",
+ "manipur",
+ "meghalaya",
+ "mizoram",
+ "nagaland",
+ "odisha",
+ "puducherry",
+ "punjab",
+ "rajasthan",
+ "sikkim",
+ "tamil-nadu",
+ "telangana",
+ "tripura",
+ "uttar-pradesh",
+ "uttarakhand",
+ "west-bengal"
+]Input schema / properties / state / examplesAdded value: +[
+ "maharashtra"
+]Input schema / properties / status / descriptionPrevious value: -"Filter: in_force, repealed, spent"New value: +"The publisher's lifecycle status for the act."Input schema / properties / status / enumAdded value: +[
+ "in_force",
+ "repealed",
+ "superseded",
+ "spent"
+]Input schema / properties / status / examplesAdded value: +[
+ "repealed"
+]resolve_india_citationresolve_india_citations_batchsearch_acts24 fields changedInput schema / properties / actStatusAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Filter by the publisher's lifecycle status: `in_force`, `repealed`, `superseded`, `spent`. Accepts one value or a list. This is the publisher's claim, not our verdict: see GET /acts/{actId}/status.",
+ "enum": [
+ "in_force",
+ "repealed",
+ "superseded",
+ "spent"
+ ],
+ "examples": [
+ "repealed"
+ ]
+}Input schema / properties / actTitle / descriptionPrevious value: -"Filter by act title substring (e.g. 'Indian Penal Code', 'BNSS')"New value: +"Filter by words in the act's title. Each word must appear, so `Bharatiya Nyaya` narrows to the Sanhita."Input schema / properties / actTitle / examplesAdded value: +[
+ "Bharatiya Nyaya Sanhita"
+]Input schema / properties / category / descriptionPrevious value: -"Filter: central, state, regulatory, repealed, spent"New value: +"Jurisdictional class. `repealed` and `spent` are accepted for backward compatibility and resolve against `actStatus` instead."Input schema / properties / category / enumAdded value: +[
+ "central",
+ "state",
+ "regulatory",
+ "repealed",
+ "spent"
+]Input schema / properties / category / examplesAdded value: +[
+ "central"
+]Input schema / properties / department / descriptionPrevious value: -"Filter by regulatory body (e.g. 'sebi', 'rbi')"New value: +"Issuing body. Deliberately NOT an enumerated list: this field holds 943 distinct values and mixes clean regulator slugs (`sebi`, `rbi`, `moefcc`) with free-text state department names (`Law Department`). Read GET /acts/filters for the values with the most data behind them."Input schema / properties / department / examplesAdded value: +[
+ "sebi"
+]Input schema / properties / excludeRepealedAdded value: +{
+ "default": false,
+ "description": "Drop provisions whose act the publisher records as repealed or spent. Off by default, because repealed law is still law that was in force and is routinely the thing being researched.",
+ "examples": [
+ true
+ ],
+ "type": "boolean"
+}Input schema / properties / isSubordinateAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "True for subordinate instruments only (rules, notifications, circulars, orders); false for principal acts only. Omit for both.",
+ "examples": [
+ false
+ ]
+}Input schema / properties / legalSubjectAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Filter by subject area, e.g. `tax_law`, `criminal_law`, `environmental_law`, `company_law`.",
+ "enum": [
+ "administrative_law",
+ "banking_finance",
+ "civil_procedure",
+ "constitutional_law",
+ "corporate_law",
+ "criminal_law",
+ "environmental_law",
+ "family_law",
+ "general",
+ "information_technology",
+ "intellectual_property",
+ "labour_law",
+ "property_law",
+ "tax_law"
+ ],
+ "examples": [
+ "tax_law"
+ ]
+}Input schema / properties / matchTypeAdded value: +{
+ "default": "any",
+ "description": "How query terms must appear in the provision text. `any` (the default) leaves hybrid ranking to do the work; `all` keeps only provisions containing EVERY query term; `phrase` keeps only those containing the exact phrase.\n\n⚠️ It narrows the ranked candidate pool rather than re-querying the index, so a `phrase` search returns phrase matches WITHIN the top candidates, not every phrase match in the corpus. For an exhaustive phrase search, narrow with the structured filters first.",
+ "enum": [
+ "any",
+ "all",
+ "phrase"
+ ],
+ "examples": [
+ "phrase"
+ ],
+ "type": "string"
+}Input schema / properties / provisionTypeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Filter by what the provision DOES: `definitional`, `prohibitory`, `procedural`, `penal`, `overriding` and others. Accepts a value or a list.",
+ "enum": [
+ "mandatory",
+ "general",
+ "prohibitory",
+ "overriding",
+ "discretionary",
+ "declaratory"
+ ],
+ "examples": [
+ "mandatory"
+ ]
+}Input schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Search query."Input schema / properties / query / examplesAdded value: +[
+ "assessment of a registered dealer"
+]Input schema / properties / query / maxLengthPrevious value: -10000New value: +1000Input schema / properties / sectionNumber / descriptionPrevious value: -"Filter by exact section number (e.g. '23', '302', '498A')"New value: +"Filter by exact section number. The publisher's own numbering, which is not an integer: `498A`, `376DA` and `2-A` all occur, and the alphabetic suffix is part of the number rather than a sub-provision."Input schema / properties / sectionNumber / examplesAdded value: +[
+ "498A"
+]Input schema / properties / sectionTypeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Filter by structural kind: `section`, `sub_section`, `definitions`, `preamble`, `schedule`, `short_title`.",
+ "enum": [
+ "amendment_provision",
+ "article",
+ "body",
+ "chapter_heading",
+ "definition_clause",
+ "definitions",
+ "part_heading",
+ "preamble",
+ "schedule",
+ "section",
+ "short_title",
+ "sub_section"
+ ],
+ "examples": [
+ "definitions"
+ ]
+}Input schema / properties / state / descriptionPrevious value: -"Filter by state slug (e.g. 'maharashtra', 'delhi')"New value: +"Jurisdiction slug. `central` is a value here, for Union legislation. Live counts per jurisdiction are on GET /acts/coverage."Input schema / properties / state / enumAdded value: +[
+ "andaman-and-nicobar-islands",
+ "andaman-nicobar",
+ "andhra-pradesh",
+ "arunachal-pradesh",
+ "assam",
+ "bihar",
+ "central",
+ "chandigarh",
+ "chhattisgarh",
+ "dadra-and-nagar-haveli-and-daman-and-diu",
+ "dadra-nagar-haveli",
+ "delhi",
+ "goa",
+ "gujarat",
+ "haryana",
+ "himachal-pradesh",
+ "jammu-and-kashmir",
+ "jammu-kashmir",
+ "jharkhand",
+ "karnataka",
+ "kerala",
+ "ladakh",
+ "lakshadweep",
+ "madhya-pradesh",
+ "maharashtra",
+ "manipur",
+ "meghalaya",
+ "mizoram",
+ "nagaland",
+ "odisha",
+ "puducherry",
+ "punjab",
+ "rajasthan",
+ "sikkim",
+ "tamil-nadu",
+ "telangana",
+ "tripura",
+ "uttar-pradesh",
+ "uttarakhand",
+ "west-bengal"
+]Input schema / properties / state / examplesAdded value: +[
+ "maharashtra"
+]Input schema / properties / yearFrom / examplesAdded value: +[
+ 2015
+]Input schema / properties / yearTo / examplesAdded value: +[
+ 2024
+]fetchget_act_amendmentsget_act_textget_corresponding_provisionslist_act_filterslist_actssearchsearch_actsSearch and read U.S. Code statutes with legal and inline citations linking to uscode.ecfr.io.
Public Indian legal search MCP for Roop judgments, statutes, and corpus grounding.
Search UK Acts, Statutory Instruments, and legislation with full text retrieval
Resolve, search and verify legal citations against the official sources, with provenance.
Add one secure layer between your agents and this server.
