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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, and the description adds real value beyond them: abbreviation/element-order tolerance, the error contract ('malformed citations are rejected rather than reported as not found'), and the explicit 2-credit cost. It does not address rate limits or whether resolution is deterministic across recodification boundaries beyond what the asAtDate param says.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then usage context, then behavioral edge cases, then cost — each sentence carries distinct, non-redundant information with no filler.

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

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

With an output schema present, return values need no explanation, and the description covers usage, failure mode, and cost. The only gap is not routing multi-citation callers to the batch sibling, which an agent might otherwise attempt one at a time.

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 justifies the parameters, including the rich state and asAtDate explanations. The description adds only generic input-flexibility commentary and says nothing specific about state or asAtDate, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Identifies a specific resource (the provision named by an Indian legal citation) and behavior (accepts abbreviations, flexible element order), with concrete input examples like 's.302 IPC' and 'Art. 21 of the Constitution'. The scope is distinct from siblings such as resolve_india_citations_batch (singular input) and get_act_section (which requires structured act/section identifiers). Minor nit: the opening is a verbless fragment, but it still conveys purpose unambiguously.

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 states when to use it ('when a user provides a citation rather than a research topic'), steering the agent away from search-style siblings. It does not, however, mention the obvious alternative for multiple citations (resolve_india_citations_batch), which is the most likely sibling confusion point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.