Search US and Indian statutes, regulations, constitutions, and court rules.
Scored across 22 tools
Search and search_acts overlap, as do fetch and get_act_text, and get_act_amendments vs get_section_history can be blurred at the act/section boundary. The descriptions are unusually explicit about which endpoint to prefer, which helps, but an agent still has to navigate several near-duplicate paths.
The tool names mix bare verbs (fetch, search), get_* verbs (get_act_status, get_section_history), and noun-phrase india_act_* tools, so there is no single predictable pattern. Everything is readable snake_case, but the conventions are not consistent enough to make names a reliable guide.
22 tools is slightly heavy for what is fundamentally a read-only legal research API, but most tools earn their place by covering distinct operations like search, structure, status, amendments, citations, and definitions. The count is inflated by a few compatibility and account tools (search, fetch, credits, pricing) rather than by redundant core functionality.
The server covers the full research lifecycle: discover acts, filter, search sections, read provision text, check status, amendments, structure, definitions, and citation graphs. Minor gaps exist, such as no direct full-act inline text and no subordinate instrument text endpoint, but agents can work around them via source links and per-section bodies.
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?
The readOnlyHint annotation is consistent with the fetch semantics. The description explains the unusual behavior that `text` contains the title and `metadata` contains the URLs, which is important for agents to know. No side effects are mentioned, and none are implied.
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 description is reasonably concise and well-structured, with a clear main sentence, a note about behavior, and an alternative recommendation. It avoids unnecessary repetition, though the 'Also accepts' phrase is slightly redundant with the schema.
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?
The description includes the return structure, explains the special handling of text and metadata, and gives a preference for an alternative tool. It does not cover error cases or all possible inputs, but for a simple fetch operation it provides sufficient context.
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 schema only has `id` with no description, but the description adds that it comes from a search result and can also be a source URL or bare path. This gives some semantic context but remains ambiguous about the exact format or acceptable values, so the parameter is not fully specified.
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 clearly states the tool fetches an Indian enactment and specifies the return fields. However, the phrase 'from a search result' and 'Also accepts a source URL or a bare path' add ambiguity about the input, slightly reducing clarity.
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?
Provides a clear preference for `get_act_text` when possible and explains that the returned `text` field is just the title while links are in `metadata`. This gives useful guidance, though it does not compare against other sibling tools like `get_act_structure`.
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 | Amendment action class. Served in the NOMINAL spelling; the corpus stores the verbal form (`substituted`) and either is accepted. Values: `substitution`, `insertion`, `omission`, `renumbering`, `addition`, `repeal`, `deletion`, `adaptation`, `amendment`, `note`. | |
| act_id | Yes | Section identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404. | |
| section | No | Keep only footnotes attached to this section, written exactly as the publisher does. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A. | |
| pageSize | No | Results per page (1-200). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals a critical caveat: an empty list means no amendment was recorded, not that the Act was never amended. It also discloses the amending Act and effective date format, and specifies a cost of 5 credits. These are meaningful behavioral traits that shape agent expectations and are not present in the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the core function, includes one illustrative example, and each remaining sentence adds distinct value: usage guidance, the empty-list caveat, and cost. No filler or repetition of the title exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema existsley and the annotations declare readOnlyHint, the description is sufficiently complete for an agent to select and invoke the tool. It covers the key caveat about empty results pending amendment, the cost, and the type of response. The remaining operational details like pagination are already documented in the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all five parameters, including examples for act_id, type normalization, and section formatting. The description adds no additional parameter-level meaning beyond framing the tool as 'one enactment.' With full schema coverage, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool returns: amendment history for one enactment, including substitutions, insertions, omissions, amending Act, and effective date. It pairs a specific verb with a clear resource and grounds it with a concrete example, making its purpose unambiguous. It is clearly distinguished from related tools like get_act_text or get_act_status by focusing on amendment history rather than content or status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: check whether a provision still reads as enacted before relying on its text. It does not explicitly name alternatives or exclusion conditions, but the purpose and context are clear enough for an agent to select this tool over siblings. A small gap is not saying when to prefer get_section_history or get_act_status instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A single provision with its citation, its position in the act, the structural features its text carries, and what it points at.
Cost: 2 credits.
This does not return the provision's text. GET /acts/{actId}/sections/{n}/body
does, and is priced separately because it reads the act document.
wordCount is summed across every passage of the provision. actsReferenced
is whitespace-normalised before deduplication, because the publisher's line
breaks otherwise make one cited act look like two.
| Name | Required | Description | Default |
|---|---|---|---|
| act_id | Yes | Section identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404. | |
| section_number | Yes | Section number exactly as the publisher writes it. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by stating it does not mutate. It adds behavioral details beyond annotations: the credit cost, the fact that wordCount sums across passages, and that actsReferenced is whitespace-normalized before deduplication. No contradiction exists.
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 description is concise and front-loaded: it states the purpose, then cost, then what it does not do, then two specific output nuances. Every sentence contributes value without redundancy or fluff.
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 the tool has an output schema, the description need not restate return values. It explains the two key output field nuances (wordCount and actsReferenced), provides pricing, and directs to the text endpoint. It covers all necessary context for an agent to decide when and how to invoke 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?
The input schema already provides detailed descriptions for both parameters, including patterns, examples, and warnings about hand-assembling IDs. The description adds no additional parameter-level meaning; it focuses on output behavior and cost. With schema coverage at 100%, the baseline of 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?
The description clearly states it returns 'a single provision with its citation, its position in the act, the structural features its text carries, and what it points at.' It explicitly distinguishes from get_act_section_body by noting it does not return the provision's text, which separates it from that sibling. The purpose is specific and non-tautological.
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?
The description explicitly directs the agent to an alternative for text retrieval: 'GET /acts/{actId}/sections/{n}/body does, and is priced separately because it reads the act document.' It also clarifies cost (2 credits) and explains why the alternative is priced differently. This is clear guidance on when to use this tool versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The publisher's own text for one provision.
Cost: 3 credits. Refunded when we hold the provision and cannot reproduce its text, because you asked for text and did not get it.
The text is sliced out of the act document by the character offsets stored with
each passage. It is never assembled by concatenating search passages: those
carry a retrieval header that we synthesized (Act: ... | India | State | In Force), and serving that as statute would put our words inside a quotation of
the law.
This text is as the publisher published it. We do not apply amendments to
it. GET /acts/{actId}/sections/{n}/history lists every amendment we hold for
the provision, each with an appliedStatus saying whether it is reflected here.
It is not.
| Name | Required | Description | Default |
|---|---|---|---|
| act_id | Yes | Section identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404. | |
| section_number | Yes | Section number exactly as the publisher writes it. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is reinforced by the description's emphasis that it returns the publisher's original text and does not apply amendments. It also transparently discloses the credit cost, refund condition, and potential 404 for hand-built IDs. No contradictions with 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?
The description is structured in clear paragraphs and contains valuable warnings and context. It is slightly repetitive in places, such as the refund explanation and the trailing 'It is not.' phrase, but overall each sentence contributes useful 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?
The description covers the tool's purpose, cost, refund behavior, important usage cautions, and the relationship to amendment history. With an output schema present, it does not need to describe return fields. It is sufficiently complete for an agent to decide when and how to call 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?
Both parameters are fully described in the schema. act_id guidance explains why IDs should come from search results and why hand-built IDs often fail; section_number clarifies exact formatting and that alphanumeric suffixes are part of the number. This goes beyond basic schema definitions.
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 clearly states that the tool returns 'the publisher's own text for one provision,' distinguishing it from search snippets and amended versions. The title 'Get Act Section Body' reinforces the retrieval purpose, though the first sentence is a noun phrase rather than an explicit action verb.
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?
The description gives practical usage guidance: it warns against assembling text from search passages, points to the history endpoint for amendments, and explains the refund condition when text cannot be reproduced. It does not explicitly contrast with every sibling tool like get_act_text or get_act_section, but the core alternatives are addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything we know about an act's standing, kept in three separate vocabularies that are deliberately never collapsed into one verdict.
Cost: 1 credit.
publisherStatus is act_status exactly as India Code records it. Their
word.
servedStatus is ours: whether this API answers for the act, or has retired
it as withdrawn by the publisher or as a duplicate of one we kept.
repealClaim is the publisher's repeal record WITH its source, and with the
caveat that we do not verify whether the repealing instrument was itself
brought into force.
That last distinction is not pedantry. India Code lists the Industrial Disputes Act, 1947 as repealed by Act 37 of 2020, the Industrial Relations Code, which has never been commenced. Serving that as flatly "repealed" would be wrong, so this endpoint does not.
A retired act answers here with servedStatus: retired and the reason, rather
than 404ing, because "we deliberately withdrew this" is a more useful answer
than "no such thing".
| 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?
The description is transparent about semantic caveats: it does not verify whether a repealing instrument was commenced, and it deliberately returns retired acts rather than 404ing. Combined with readOnlyHint, the behavior is well disclosed.
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 description is longer than average, but nearly every sentence carries meaningful nuance. The Industrial Disputes example is illustrative rather than padding, though it could be tightened without losing value.
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?
The description explains the main status categories and the retired behavior clearly. It does not fully enumerate the complete response shape, but it provides enough context for the primary use case and the available output schema is noted.
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 act_id parameter is fully described in the schema with an example, format, length, and a practical warning to take IDs from search results rather than constructing them. The tool description adds no further parameter detail, but the schema coverage is strong.
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 name and description make the purpose unmistakable: retrieve the standing/status of an act. The description also contrasts this endpoint with a plain fetch by explaining that retired acts are returned with a reason rather than 404ing.
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?
The description explains when this endpoint is the right choice, especially the retired-act behavior, and the parameter guidance warns against hand-building IDs. It does not explicitly name sibling tools to avoid, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The act's own shape: its chapters and parts where the publisher gives any, and the provisions under each.
Cost: 2 credits.
hasHierarchy is false for most acts and that is not an error: the publisher
gives many acts no chapter or part divisions at all, and for those nodes is a
flat list of sections. The free GET /acts/coverage publishes how many acts do
carry a hierarchy, as depth.actsWithStructure.
Section numbers are sorted numerically with their alphabetic suffixes kept
attached, so 498A follows 498 and 10 follows 2.
| 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 indicate readOnlyHint=true. The description adds valuable behavioral context: the 2-credit cost, the fact that hasHierarchy=false is normal (not an error), the flat nodes list for such acts, and the numeric sorting with alphabetic suffixes. This goes beyond annotations and helps the agent interpret results correctly.
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 description is well-structured with clear paragraphs, front-loading the core purpose. It includes necessary caveats (hasHierarchy, sorting) and a cost note without redundancy. The length is appropriate for the complexity, and each sentence serves a purpose.
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 the output schema exists (per context), the description need not explain return values. It covers cost, hierarchy behavior, sorting, and even references a related free endpoint for statistics. It is complete for an agent to call the tool correctly and interpret the result, with minor gaps like potential pagination not mentioned.
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 input schema covers 100% of parameters (act_id) with a detailed description, including pattern, examples, and guidance on deriving the ID. The tool description does not add any extra parameter semantics, so it relies entirely on the schema. Baseline 3 is appropriate given high coverage.
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 clearly states the tool's function: retrieving an act's internal structure (chapters, parts, provisions). It uses a specific verb and resource, and the tool name 'get_act_structure' aligns. It distinguishes itself from siblings like get_act_section (single section) and get_act_text (full text) by focusing on the hierarchy shape.
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?
The description gives clear context on when the tool is relevant (for any act) and explains the common hasHierarchy=false case. However, it does not explicitly name alternatives or state when not to use this tool, though the purpose is distinct enough that an agent can infer usage. Lacks explicit exclusions or alternative tool mentions.
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?
The readOnlyHint annotation already indicates no writes, and the description adds no contradiction. It does disclose the return content (links and section count) and the cost. It does not mention error cases or rate limits, but the annotation and description together are sufficient for safe use.
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 description is concise, containing only two sentences plus cost information. Every sentence adds necessary information: what is returned, when to use it, and cost. No redundant 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?
Given the single parameter with complete schema coverage, the readOnly annotation, and the description of the output (links and section count), the tool description is fully adequate for an agent to invoke it correctly. No additional context is needed.
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 sole parameter act_id is fully described with an example, a warning against hand-building IDs, an explanation of why the chapter is not derivable from a citation, and a likely failure mode (404). This is exceptionally clear parameter guidance.
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 clearly states the tool returns source links (plain-text, PDF, HTML) and section count for one enactment, and explicitly distinguishes it from section-level lookup by saying 'rather than a matched section.' This makes the tool's purpose and scope unambiguous.
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?
The description gives explicit usage guidance: use when the user wants to read or cite the Act itself rather than a section. It also implies the alternative (section lookup) and includes the cost, so an agent knows when and why to choose this tool.
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 | 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`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: both directions ('ipc' or 'bns') return the same mapping, 'iea'/'bsa' return 404 until mapping lands, and the tool costs 1 credit. This is meaningful operational context without contradicting 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?
The description is compact and front-loaded: purpose first, then usage trigger, then edge-case behavior, then cost. Every sentence carries useful information, with no filler or repetition of schema boilerplate.
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 single-parameter tool with an output schema and read-only annotations, the description covers everything an agent needs: what the mapping is, when to use it, how the input direction works, the iea/bsa failure mode, the effective date, and the cost. Nothing material 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%, with the schema already explaining case-insensitivity, the equivalence of paired codes, and the 404 behavior for 'iea'/'bsa'. The description largely restates this information ('Pass either side...'), so it adds little beyond the schema. 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?
The description opens with a specific verb and resource: 'Map a repealed Indian criminal code to the 2023 code that replaced it, section by section: IPC to BNS and CrPC to BNSS.' It clearly distinguishes this mapping tool from sibling tools like get_act_section or resolve_india_citation by naming the exact code pairs and their effective date.
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?
The description gives an explicit trigger: '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.' This is clear context, though it does not name or exclude alternative sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the corpus behind this API: how many acts and provisions it holds, how they break down by jurisdiction, regulator and status, and how DEEP that holding goes.
Cost: free.
Read the depth block before building on this API. It answers four independent
questions, because "we hold the act" and "we hold what amended it" are different
claims and only one of them is true for most of the corpus:
actsWithText is every act we serve;
actsWithAmendmentEvents is the much smaller set for which we hold parsed
amendment records;
actsClaimingAmendmentsWithoutEvents is the known gap between them, published
so that an empty amendment list is legible as a gap rather than as a claim
that nothing ever changed.
Two different kinds of count appear here and they are labelled. passages in
the breakdown lists is faceted live and exact right now. The act-level numbers
in totals and depth come from a full distinct-act scan, and measuredOn
says when it ran. Do not divide one into the other.
| 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?
The annotations already declare readOnlyHint and openWorldHint, so the base behavioral contract is clear. The description adds valuable detail about the meaning of the 'depth' block, the distinction between act counts and amendment-event counts, and cautions against dividing incompatible numbers.
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 description is more verbose than strictly necessary, but the extra length is used to prevent real misunderstandings about the semantics of counts and the 'depth' field. The structure is logical and front-loaded with the core purpose.
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 zero parameters and no output schema details in the description, the tool is adequately specified. The description explains the key data distinctions and cautions, so an agent has enough context to call it correctly and interpret results sensibly.
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?
There are no parameters, so there is nothing to document. The schema coverage is complete and no additional parameter guidance is needed.
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 clearly states the tool's purpose: describing the corpus behind the API, including counts of acts and provisions, breakdowns by jurisdiction/regulator/status, and depth of holdings. It is unmistakably distinct from sibling tools that fetch individual acts or sections.
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?
The description explains when to use this tool implicitly: to understand corpus coverage and depth before building on the API. It does not explicitly contrast with sibling tools, but the zero-parameter interface and focus on aggregate statistics make the use case clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the credits this API key's account can spend right now.
Free. Never charged, so it is safe to poll for low-balance alerting or to pre-flight a batch job.
Authentication: any valid vq_key_ key. No particular scope is required.
Credits are account-wide and are not split by jurisdiction: the same balance
funds the India legislation endpoints and the United States primary-law
endpoints, from one ledger. This route and the United States
GET /api/v1/credits/balance therefore report the same number, and spending on
either surface moves both.
Read bySource before assuming a balance is durable: subscription credits are
use-it-or-lose-it at the period end, while payg credits you purchased persist
and burn last. nextExpiry tells you what is about to be forfeited and when.
curl https://api.vaquill.ai/api/v1/in/credits/balance \
-H "Authorization: Bearer $VAQUILL_API_KEY"| 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 only carry readOnlyHint=true and openWorldHint=false, so the description carries the burden of real behavioral disclosure — and it delivers far beyond it: the endpoint is free and safe to poll, requires only any valid `vq_key_` key with no scope, reports an account-wide balance shared across jurisdictions, and exposes the bySource durability split (subscription credits forfeit at period end, payg persists) plus nextExpiry semantics. No contradiction with annotations; this is exactly the kind of contextual cost/safety/expiry detail that structured fields cannot express.
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 description is longer than average (~150 words plus a curl example), but every section earns its place: purpose statement up front, then cost/safety, auth, cross-jurisdiction semantics, balance durability, and a concrete example. Bolded labels and clear paragraph breaks make it scannable. It is slightly verbose relative to the minimal feature surface, but nothing is redundant.
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 zero-parameter, read-only tool with an output schema present, the description is effectively complete. It covers authentication requirements, cost implications, polling suitability, ledger semantics across jurisdictions, and the durability/expiry behavior an agent must understand before trusting the number. The output schema covers return-value shape, so the description need not restate 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 has zero parameters and 100% schema coverage, so the baseline per the rubric is 4. There is nothing for the description to add about parameter syntax or meaning, and it correctly omits fabricated parameter details. The description instead clarifies the implicit scoping — the balance is keyed to 'this API key's account' — which is reasonable compensation for the absence of an account 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 opening sentence states a specific verb plus resource — 'Returns the credits this API key's account can spend right now.' This clearly differentiates it from all 21 siblings, which are act/section/search/citation tools; the only near-relative, get_pricing_in, is about cost rates, not balance. An agent can identify this as a read-only balance endpoint 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?
The description gives explicit use cases ('safe to poll for low-balance alerting or to pre-flight a batch job') and explains the relationship to the US credits endpoint, including that both read the same ledger. It does not name a concrete alternative MCP sibling to prefer in some cases, but for a zero-parameter read tool with no close sibling, the context provided is clear and actionable.
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 rate and per-endpoint costs for the India legislation surface (/in/acts/*).
No authentication required. 1 credit = $0.01 USD, billed in USD.
Pass ?region=US to price the United States primary-law surface instead: it is the same credit balance and the same key.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the non-mutating nature, and the description adds helpful behavioral details such as no authentication required, the credit-to-USD conversion rate, and billing currency. This goes beyond the annotations without contradicting them.
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 description is concise, well-structured, and free of unnecessary detail. It uses short paragraphs and bolded key phrases to communicate pricing, authentication, and region selection efficiently.
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 the simple one-optional-parameter interface and the presence of an output schema, the description covers all necessary context: what is priced, which surfaces can be priced, authentication requirements, and billing units. No critical information 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?
The schema already provides full documentation for the optional region parameter, including its enum values and default behavior. The description adds a concrete usage example (?region=US) and clarifies that the same credit balance and key apply, which enriches the parameter guidance.
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 clearly states the tool provides credit-to-price conversion and per-endpoint costs for the India legislation surface, which is a specific and identifiable resource. It also distinguishes the tool by allowing an alternative region (US) to be priced instead, making its scope explicit.
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?
The description states that no authentication is required and explains how to switch to the US region using ?region=US, which is actionable guidance. It does not explicitly contrast with sibling tools, but there is no other pricing-specific sibling, so the main usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The amendment record for a single provision: what changed, which Act changed it, which of that Act's sections did so, when it took effect where the publisher records a date, and the wording it replaced where the publisher quotes it.
Cost: 2 credits. An empty history for a provision we hold IS the answer and
is charged; the coverage block tells you whether it is empty because nothing
changed or because we hold no parsed record.
Read appliedStatus on every event. It is not_applied throughout, because
the text this API serves is the publisher's published text and we do not edit
it. That is a deliberate, stated position rather than an omission: you should
never have to infer currency from silence.
asOf returns a TIMELINE, not text. We hold amendment events and no
versioned text, so there is no honest way to render this provision as it stood
on a date. Passing asOf tells you how many recorded amendments had taken
effect by then, how many had not, and how many carry no date at all. isBounded
true means we hold no recorded event affecting that date, which is not the same
as there having been none.
Coverage is real and uneven: many acts carry a non-zero amendment count with no
parseable footnote behind it, and about half the records we do hold carry no
effective date. Read the coverage block on this response for the provision you
asked about, and the free GET /acts/coverage for the corpus-wide split
(depth.actsWithAmendmentEvents against
depth.actsClaimingAmendmentsWithoutEvents).
| 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 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=true and openWorldHint=false in annotations, the description carries a heavy behavioral burden and discharges it exceptionally: it discloses cost (2 credits), that an empty history is still charged and what the coverage block means, that appliedStatus is deliberately always not_applied (a stated position, not an omission), that asOf returns a timeline not reconstructed text, and that coverage data is uneven. No contradiction with annotations; the read-only claim is consistent with 'we do not edit it'.
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 description is long but every sentence is load-bearing — cost, empty-response interpretation, appliedStatus policy, asOf semantics, and coverage caveats are all genuine agent-relevant concerns. The core purpose is front-loaded in the first sentence, and there is zero filler or repetition of schema content.
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 the tool's genuine semantic complexity — timeline vs text, deliberate not_applied, charged empty responses, uneven coverage — the description is remarkably complete. It addresses cost, empty-result interpretation, appliedStatus, asOf behavior, and coverage caveats, and points to the free corpus-wide coverage endpoint. The presence of an output schema relieves it of explaining return values, and nothing an agent needs to call 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%, so the baseline is 3 and the schema already documents all five parameters with rich detail (e.g., act_id's 'hand-built ids usually 404' gotcha, section_number's '498A is one section' rule). The description adds genuine conceptual value on top by explaining the asOf semantic (timeline, not text) and the meaning of isBounded, which deepens parameter understanding beyond the 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?
The description states a specific verb and resource: 'The amendment record for a single provision' — a precise, detailed scope enumerating exactly what is returned (what changed, which Act, which sections, effective dates, replaced wording). The emphasis on 'a single provision' distinguishes it from act-level siblings like get_act_amendments, so an agent can route correctly 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?
Clear context is given for when the tool is appropriate (per-provision amendment history) and it explicitly routes corpus-wide coverage needs to the free GET /acts/coverage endpoint. However, it does not explicitly name sibling tools (e.g., get_act_amendments) with when-to-use-vs-when-not language, so the exclusion guidance is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inbound citations: provisions elsewhere in the corpus that name this act.
Cost: 2 credits. A confident "nothing cites this" is the answer and is charged.
🔴 Matched on the act's TITLE, not on an identifier, because that is what
the corpus stores. A citing document that wrote the title differently is
missed, and the publisher's own line breaks make that measurable. Read
matchBasis and treat the result as a floor rather than a complete set.
A foundational act can be cited by thousands of provisions, so the answer is
PAGED with page + pageSize, the same as the rest of this API.
total is the number of distinct citing PROVISIONS across all pages, not the
size of the page you were served (returned) and not the number of matching
passages: one provision is stored as many passages, so total is the smaller
number. totalIsExact goes false only if the corpus scan behind that count hits
its ceiling, which no act in the corpus currently reaches.
| 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?
The description goes well beyond the annotations by disclosing cost, title-based matching, likely false negatives, pagination behavior, and the meaning of `total` versus `returned`. It also explains `totalIsExact` and `matchBasis` semantics. There is no contradiction with `readOnlyHint: true` or `openWorldHint: false`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well structured, with clear bolded caveats and a front-loaded first sentence. However, the supplied text ends with an incomplete/truncated sentence about `totalIsExact` ('goes false when ...?'), which prevents a perfect structure score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paged read-only tool with an output schema, the description covers the important non-obvious behaviors: title matching, incompleteness risk, cost, and pagination/total semantics. The incomplete `totalIsExact` explanation is a small gap, but the presence of an output schema reduces the need for the description to fully document every return field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents `act_id`, `page`, `pageSize`, and `limit` with examples and constraints. The description mostly discusses output-field semantics (`total`, `returned`, `totalIsExact`) rather than adding new parameter-level guidance, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific definition — 'Inbound citations: provisions elsewhere in the corpus that name this act' — which clearly identifies the resource and the direction of the lookup. It also adds the key distinction that matching is done on the act's TITLE, not an identifier, which further separates it from nearby sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: this tool finds provisions that cite the act, returns paged results, and should be treated as a floor rather than a complete set. It does not explicitly name alternatives or say when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The terms an act defines, and the provision that defines them.
Cost: 2 credits. Refunded when the act holds no extracted definitions, because the caller asked for definitions and did not get any.
⚠️ Coverage is thin and stated rather than implied: extracted defined terms
exist for a minority of served acts. An empty answer here means we did not
extract them, NOT that the act defines nothing. definitionSections is
returned separately so you can read the defining provision directly even when
no terms were extracted from it.
terms is paged with page + pageSize, because a long definitions clause can
run to thousands of entries. definitionSections is short and is NOT paged, so
it repeats in full on every page.
| 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?
The description goes well beyond the readOnlyHint annotation by disclosing the 2-credit cost, the refund condition, the thin-coverage semantics, and the detailed paging behavior for `terms` versus `definitionSections`. It even clarifies that empty answers are about extraction coverage, not the act's content. This is rich behavioral 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?
The description is dense but every sentence earns its place: purpose, cost/refund, coverage caveat, and paging semantics. The critical warning is front-loaded before the paging details, and there is no fluff or repetition of schema content.
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 is present and the input schema is fully documented, the description covers all operational quirks an agent needs: cost, refunds, coverage limitations, interpretation of empty results, and pagination. Nothing essential is missing for invoking the 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?
The input schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds value by explaining why `page` and `pageSize` exist (a definitions clause can run to thousands of entries) and by clarifying that `definitionSections` is unpaged and repeats on every page. This goes beyond the schema's per-parameter descriptions.
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 opening line, 'The terms an act defines, and the provision that defines them,' clearly identifies the resource and the response's two-part shape. It lacks an explicit verb like 'list' or 'retrieve' and does not call out sibling tools, but the resource is unambiguous.
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?
The description provides strong contextual guidance: it warns that coverage is thin, explains that an empty result means no extraction rather than no definitions, and tells the caller to consult `definitionSections` directly. It does not explicitly name alternative tools or state when not to use this tool, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subordinate instruments the publisher records as made under this act: rules, regulations, notifications and orders.
Cost: 2 credits. An act with no subordinate instruments on record is the answer and is charged.
🔴 Resolved by the parent's TITLE. The stored parent_act_id is India Code's
own identifier and does not address this corpus, so a hard link would resolve to
nothing. Title matching reaches a served parent for most instruments that name
one, and matchBasis says so on every response.
Paged with page + pageSize. total counts distinct INSTRUMENTS across all
pages, not the rows on this page (returned) and not matching passages.
| 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?
The description discloses the 2-credit cost, the charged empty-result case, the parent-title resolution behavior, and the meaning of `total` as distinct instruments rather than rows or passages. This goes well beyond the `readOnlyHint` and `openWorldHint` annotations and gives agents important non-obvious behavioral facts.
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?
Every sentence earns its place: the core resource is front-loaded, followed by cost, the parent-resolution caveat, and pagination semantics. Despite carrying many caveats, the description is compact and well-structured.
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 paged list tool with an output schema, the description covers the non-obvious behaviors an agent needs: cost, empty-result charging, parent resolution limitations, and total-vs-returned counting. No critical gap is apparent.
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?
All 4 parameters have schema descriptions, so the 100% coverage baseline applies. The description does not add new input-specific semantics beyond what the schema already says; the pagination and `total` details are about response behavior rather than parameter meaning.
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 opening line clearly identifies the resource (subordinate instruments: rules, regulations, notifications and orders) and an act-specific scope. However, it is phrased as a noun phrase rather than an explicit verb like 'List' or 'Get', and it does not contrast with sibling tools.
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?
No alternative tools are named, and there is no explicit condition for choosing this tool over siblings such as `india_act_definitions` or `get_act_amendments`. The description does provide useful operational context about parent-title resolution and pagination, but the primary use case is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outbound citations: the other enactments this provision names, and the sections of its own act it cross-refers to.
Cost: 2 credits. An empty result for a provision we hold IS the answer and is charged; a provision we do not hold is refunded.
Act references are resolved to an actId where the title names something we
serve, and returned with resolved: false where it does not. That is the
honest split: the publisher names acts we may not hold, and a null id is a
coverage fact rather than a parse failure.
This route takes no query parameters and is not paged: one provision's own
outbound edges are a short list. totalActs and totalSections are the full
counts, and truncated says whether the row cap cut either list.
| Name | Required | Description | Default |
|---|---|---|---|
| act_id | Yes | Section identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404. | |
| section_number | Yes | Section number exactly as the publisher writes it. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnlyHint/openWorldHint annotations: it explains the 2-credit cost, the charge/refund distinction, the resolved:false semantics, the lack of paging, and the meaning of totalActs, totalSections, and truncated. This gives the agent a reliable model of edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but purposeful, front-loading the core purpose before cost and edge-case semantics. A few phrases like 'that is the honest split' are slightly editorial, but every paragraph contributes useful operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to enumerate return fields. It covers cost, refund behavior, resolution semantics, paging, and truncation, which are exactly the contextual details an agent needs to correctly interpret results. Nothing important appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter descriptions are already detailed, including format, examples, and anti-patterns like hand-building act_id. The tool description adds no new parameter-level semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: it returns outbound citations for a provision, including other enactments named and cross-references within its own act. This clearly differentiates it from sibling tools like india_act_cited_by, which appears to handle inbound citations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear situational context: this route handles one provision's outbound edges, takes no query parameters, and is not paged. It does not explicitly name alternative tools or say when not to use it, but the coverage and crediting notes provide enough practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
Read-only operation is already indicated by annotations; description adds that it includes counts, but doesn't detail return structure. Slight room for more transparency, but adequate given 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?
Single concise sentence with key information front-loaded; no wasted words.
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?
Fully describes the tool's purpose and usage context; no missing information necessary for a simple read-only filter-listing tool.
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?
No parameters, so no parameter semantics needed; description is self-contained.
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 clearly states the tool provides filter vocabulary (categories, states, departments, statuses) with counts, making its purpose unambiguous.
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 explicitly instructs to call before filtering to use valid values and avoid empty results due to misspellings, providing clear when-to-use guidance.
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 | 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the non-obvious behavioral detail that it costs 1 credit, which is useful beyond the readOnlyHint annotation. It also clarifies that filters apply to what exists, not the text. No contradiction with 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?
The description is three concise sentences: first the function, then the use cases, then the cost. Nothing is extraneous, and the key distinctions appear up front.
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?
The tool has an output schema, a full parameter schema, and readOnlyHint annotations. The description adequately fills the remaining gaps: helps you decide when to use it (browsing vs searching), explains the cost, and points to a filter scope. No essential behavior for selecting or invoking it 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 coverage is 100%, so each parameter already has a detailed description. The tool description adds a high-level abstract of filter dimensions (jurisdiction, regulator, year, status) but does not add meaning beyond what the schema already offers.
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 clearly states the tool browses and filters enactments by jurisdiction, regulator, year, and status. It explicitly contrasts this with searching the text, distinguishing it from the sibling search tools. An agent can immediately identify this as the 'what exists' listing tool.
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 provides clear use cases ('when the user wants to know WHAT exists' or 'confirm an exact title') and implicitly separates this from text search ('rather than searching their text'). However, it does not name alternative siblings such as search_acts explicitly, so when-not guidance is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a citation a lawyer would type into the provision it names.
Cost: 2 credits. A malformed citation is a 422 and is NOT charged. Every
other outcome is, including not_found: a confident negative is the answer.
Accepts what Indian practice actually writes, not what a style guide prescribes.
Three published standards exist and they disagree about element order, while the
most common real form, u/s 302 IPC, appears in none of them. So order does not
matter, and all of these work:
u/s 302 IPC
Section 302 of the Indian Penal Code, 1860
s.302 IPC
S. 376(2)(g), IPC
clause (a) of sub-section (1) of section 302 IPC
O. 39 R. 1 CPC
Art. 21 of the Constitution
Regulation 24 of the SEBI (LODR) Regulations, 2015
Maharashtra Act No. LXXVII of 2018🔴 Read status before reading candidates. ambiguous is a real answer
and it is charged, because narrowing a citation to two named enactments is the
work. The commonest cause is the 2023 recodification: after 1 July 2024,
s. 302 names both IPC 302 (murder) and BNS 302 (uttering words to wound
religious feelings), while BNS 103 is murder. Both codes are live law
simultaneously for the lifetime of pending trials, so this endpoint will not
choose for you. Send asAtDate and it will.
r/w ("read with") is split into separate citations and each is resolved.
| 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 | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark the tool as read-only, the description adds important behavioral disclosure beyond that: 'Read `status` before reading `candidates`', ambiguous answers are charged, malformed citations return 422 and are not charged, and r/w citations are split. It also explains why ambiguity may be intentional due to the 2023 recodification.
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 description is long but every section earns its place: a one-sentence purpose, cost and charging behavior, accepted-form flexibility with concrete examples, the critical status-then-candidates warning, and the recodification explanation. The structure is front-loaded and scannable despite the dense material.
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 the tool's moderate complexity, an output schema, and read-only annotations, the description covers the essential operational concerns: costs, failure modes, ambiguity, jurisdiction/date disambiguation, and r/w handling. Nothing critical for correct invocation 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?
With 100% schema description coverage, the baseline is 3, but the description adds meaningful semantic context: it explains that element order does not matter despite style-guide disagreements, shows multiple accepted forms for `cite`, and clarifies how `asAtDate` resolves post-recoodification ambiguity. The `state` parameter is not expanded in prose, but the schema already describes it 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?
The description begins with a precise verb and object: 'Turn a citation a lawyer would type into the provision it names.' This clearly identifies the tool's function and distinguishes it from the batch sibling by focusing on a single citation. It also conveys the real-world flexibility of accepted input forms.
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?
The description gives strong usage context: order does not matter, examples show accepted formats, and callers are told to send `asAtDate` when ambiguity exists. It does not explicitly contrast this singular tool with `resolve_india_citations_batch`, so the when-to-use versus alternative guidance is slightly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The same resolver over a list, for when you would otherwise loop.
Cost: 2 credits per DISTINCT citation. Batching buys a round trip, never a discount. Duplicates are collapsed before pricing, so sending the same citation twice is charged once. Each citation is refunded individually when we fail on it; one citation failing never refunds or voids the others.
Up to 50 distinct citations, and up to 500 before deduplication. Unknown fields on the body are refused rather than ignored.
| 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 | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral context beyond annotations: cost per distinct citation, duplicate collapsing before pricing, item-level refunds on failure, upper limits of 50 distinct and 500 total citations, and strict refusal of unknown fields. These details meaningfully affect how an agent should invoke and reason about 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 description is succinct and front-loaded with the core purpose, followed by structured operational details. Each sentence earns its place, though the billing and limit details add length; this is justified because they are decision-relevant.
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?
Covers what the tool does, when to use it, pricing/refund behavior, input limits, and strictness about unknown fields. An output schema exists, so return-value details need not be in the description. This is complete for an agent selecting and invoking the 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?
The input schema already documents all three parameters with examples and descriptions, so the description does not need to repeat them. The mention of duplicate collapsing and distinct-citation pricing complements the 'citations' parameter semantics. At 100% schema coverage, the baseline of 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?
The description opens with 'The same resolver over a list,' which clearly identifies this as the batch version of resolve_india_citation, and states the resource (India citations) and operation (resolve). This distinguishes it from its singular sibling and from search/listing tools.
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 this is 'for when you would otherwise loop,' giving agents a clear decision rule to use the batch tool rather than repeatedly calling the singular resolver. Sibling context further reinforces this. It does not need to name the alternative because the guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicate readOnlyHint and openWorldHint. The description adds context about the return format (`{id, title, url}`) and its role in the standard search/fetch pair, which is useful but does not contradict 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?
The description is three sentences long and front-loaded with the core purpose. The sentence about being present for client compatibility is somewhat redundant but not overly verbose. Overall, it is concise and easy to parse.
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?
The description mentions the return format and how to use the result with `fetch`, which covers the main workflow. However, it lacks details on query syntax, result pagination, or potential errors, making it slightly incomplete for a fully self-contained tool description.
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 only parameter, `query`, is a string with no schema description. The tool description does not elaborate on what constitutes a valid query, search syntax, or any constraints. Since schema coverage is 0% and the description does not compensate, the semantic meaning of `query` remains largely unspecified.
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 clearly states the tool performs a generic corpus search over Indian Central and State legislation, returning records for citation. It explicitly distinguishes itself from the more specialized search_acts tool, which filters by category, state, year, and status.
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?
The description provides explicit guidance: prefer search_acts when available, and pair this search with fetch to read results. This tells the agent exactly when and how to use this tool relative to alternatives.
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 | 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. ⚠️ 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. Values: `any`, `all`, `phrase`. | any |
| department | No | 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. | |
| 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 | 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`. | |
| 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 | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: boolean and phrase query support, filters by category/state/year/status, the return shape (sections with title, chapter, sourceUrl), the 2-credit cost, and the fact that actId feeds downstream acts tools. This is useful, non-derivable context.
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 description is front-loaded with the core purpose and use case, then efficiently covers query capabilities, return values, downstream integration, and cost in five sentences. No obvious filler, though the opening sentence partially restates the title.
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 17-parameter tool with full schema coverage and an output schema, the description covers scope, use case, filters, return shape, cost, and integration with other acts tools. The main gap is not explaining how it relates to sibling tools like list_acts or the generic search tool, but the schema and output schema carry most operational detail.
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 the baseline is 3. The description only summarizes filter categories already present in the schema (category, state, year, status) and does not add new parameter-level semantics. The schema carries the parameter detail.
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 ('Search'), a specific resource ('Indian legislation down to the individual section'), and explicitly enumerates the coverage: Central and State Acts plus regulator instruments. It also distinguishes itself from siblings by stating that the returned actId feeds every acts tool.
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?
The description gives an explicit invocation context: 'Use for any "what does Indian law say" question.' It does not, however, list when not to use this tool or name direct alternatives such as list_acts, search, or resolve_india_citation, so it falls just 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
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_actsPublic 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.
Search and cite US law from official sources, then form an LLC or nonprofit with free agent tools.
Add one secure layer between your agents and this server.
