Indiana Code

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

Annotations already cover read-only, idempotent, and closed-world, so the description doesn't need to repeat safety traits. Instead it adds genuinely useful conditional behavior: opinion text appears only when the extract has a body, and author appears only when that index is loaded. The clarification that 'author' means the slip byline rather than the trial judge or holding is exactly the kind of non-obvious detail annotations cannot convey.

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

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

Three short sentences, front-loaded with what the tool returns, followed by the two conditional caveats. Dense but efficient; the phrasing ('Includes author when that index is loaded') is slightly elliptical but never wasteful.

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

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

An output schema exists, so return shape need not be explained, and the description fills its remaining obligations: identifying the key type and disclosing the two conditions under which fields are present. Only the source of a valid cluster id and the failure behavior for an unknown id are left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single parameter has no title beyond 'Cluster Id', so the description must compensate. It does partially by qualifying the value as a CourtListener cluster id (not a state or citation identifier), but it gives no format, example, or note on where to obtain one.

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

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

States a specific verb and resource: retrieve one Indiana opinion cluster keyed by CourtListener cluster id. This clearly distinguishes it from the search/list siblings such as case_search and the citation-graph tools, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: 'by CourtListener cluster id' suggests this is a lookup-by-id tool, and the contrast with case_search is inferable from the name. There is no explicit when-to-use/when-not or statement of what to do if you only have a citation (ic_resolve_citation) or need related cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds genuinely non-structural behavior: unresolved federal and sister-state reporter mentions are returned as a separate list, and the index is text-mention only rather than treatment-aware.

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

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

Three tight sentences, front-loaded with the core purpose and finishing with the most important caveat (not a citator). Nothing is repeated from the schema or annotations.

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?

Output schema exists, so return shapes need no explanation, and the description covers purpose, input forms, and caveats well. An unexplained 'limit' parameter and the absence of a named fallback sibling keep it just short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must carry the load, and it does for the required param: 'query is a cluster id, reporter cite, or case number' gives three concrete accepted forms. The optional 'limit' parameter is left unexplained, which is the only gap.

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 first sentence names a specific verb and resource — 'cases this opinion's text cites' — and states the normalization basis (Harvard reporter identifiers, Rule 22 case numbers). The directionality is explicit, which lets an agent separate it from the reverse-direction sibling cases_citing_case without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

'Text-mention index only: not a citator, not treatment, not good law' is a clear when-not statement that prevents misuse for citator-style work. It stops short of naming which sibling to use instead (e.g. case_search or cases_citing_case for reverse lookup), so it is strong but not a full routing rule.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the description correctly spends its words on the non-obvious trait: that results are raw text mentions, not validated citations or treatment. It does not describe result ordering or how pagination behaves, which would have made this a 5.

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

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

Three short sentences, front-loaded with the core purpose, then input formats, then the critical caveat about what the index is not. No filler and nothing redundant with the annotations.

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

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

With an output schema present, return-value detail is unnecessary, and the description covers purpose, query syntax, court values, and the text-mention caveat. The remaining gap is the temporal window parameters (after/before) and limit, which an agent would need to call this confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden; it usefully explains the three accepted query formats and the three court values, which the schema does not. However, after, before, and limit are never explained, leaving three of five parameters with no documented 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?

States a specific resource with a precise relation: 'Opinions whose text cites this case.' The direction (citing, not cited-in) is explicit, which cleanly separates it from the sibling cases_cited_in and from cases_citing_court.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives clear negative guidance — 'Text-mention index only: not a citator, not treatment, not good law' — which tells the agent when results are unsuitable. It stops short of naming a sibling to use instead for citator-style or reverse-direction needs, so the alternative routing is 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.

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

Annotations already cover readOnly/idempotent/openWorld, and the description adds a genuinely important caveat: the result set is a text-mention index, not treatment or good-law analysis, so recall depends on parenthetical formatting. That is real behavioral context beyond structured fields. Doesn't mention result ordering or pagination behavior across the limit param.

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

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

Three terse sentences, front-loaded with the defining constraint, then format examples, then the exclusion. No filler; every clause carries information the agent needs.

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

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

An output schema exists, so return values need not be explained, and the core matching semantics plus the citator caveat are covered. The gap is the unexplained after/before date-bound parameters and limit, which an agent must infer from titles.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does well for court (Indigo abbreviations with examples), year (optional, 2021), and citing_court (ind, indctapp, indtc), but after, before, and limit are never mentioned, leaving half the parameters documented by title alone.

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

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

States a concrete resource and scope: Indiana opinions whose text contains a (court year) parenthetical, matching on the text-mention index. This is clearly separable from citation-graph siblings like cases_citing_case, though it never names those siblings to reinforce the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives explicit when-not guidance — 'not a citator, not treatment, not good law' — which steers the agent away from treating results as citation analysis. It stops short of naming the alternative tool (e.g. cases_citing_case) for actual citator-style lookups.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description appropriately focuses on data caveats. It adds valuable context that status is rule_unreviewed and not a holding, citator, or good law, which is important behavioral disclosure beyond the annotations.

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

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

The description is short, front-loaded, and every sentence adds specific information about the resource, allowed values, or status caveat. There is 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 annotations covering safety and an output schema present, the description need not explain return values. However, for a 6-parameter tool with 0% schema description coverage, it omits pagination semantics and explicit usage alternatives, leaving gaps an agent may need to infer.

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 0%, so the description must compensate for parameter semantics. It explains section_id format, relation values, and court values, but leaves after, before, and limit undocumented, which are relevant pagination controls.

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 that it returns opinions with a citation-sentence signal for a Code section and specifies the relation values, which clearly identifies the resource and scope. It does not explicitly differentiate itself from siblings like cases_citing_case or ic_cases_citing, but the statute-construction focus is still clear.

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 implies the tool is for finding opinions construing a Code section, but it gives no explicit when-to-use guidance, exclusions, or sibling alternatives. An agent must infer whether this or cases_citing_case/ic_cases_citing is the right tool.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description goes beyond them by disclosing that most hits are metadata only and that every classification label is a heuristic read rather than an authoritative judgment. That is material context an agent would otherwise misinterpret.

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 purpose is front-loaded, but the body is a dense run-on sequence of near-identical caveats ('when that index is loaded' appears four times, 'not an official X' restated per filter). The content earns most of its place, but structure and repetition cost it.

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

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

An output schema exists, so return values need not be explained, and the filter semantics are well covered. The gap is the four undocumented parameters (query, after, before, limit) for a tool whose schema provides no descriptions at all.

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 0% schema coverage the description carries the full burden, and it does document court, form, disposition, standard, separate, and author with their accepted values and important semantic caveats (labels are rule reads, not official holdings). But it leaves query, after, before, and limit completely unexplained — four of ten parameters with no syntax, date format, or default behavior described.

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

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

States a specific verb ('Search') plus the exact resource scope: Indiana Supreme Court, Court of Appeals, and Tax Court clusters from a CourtListener extract. That is enough to distinguish it from case_get (retrieval) and ic_search (statutes), though it never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The repeated 'when that index is loaded' wording is genuinely useful usage context, warning the agent that filters may silently not apply. However, there is no guidance on when to use this over case_get or cases_citing_case, and no statement of what to do when an index is absent.

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

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

Annotations already cover read-only, idempotent, non-destructive, and non-open-world behavior. The description adds useful nuance: sections are from the latest snapshot and the tool returns an outline rather than full text. It omits error behavior, but the added context is meaningful.

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

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

Two compact sentences with zero filler. Purpose comes first, followed immediately by the node_id traversal examples, which are dense and directly useful.

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

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

The tool has low complexity: one optional parameter, rich annotations, and an output schema. The description supplies the hierarchical traversal model and latest-snapshot caveat, leaving no call-critical information 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 0%, so the description carries the full burden and does so well: null node_id lists titles, '31' lists articles, '31-16' lists chapters, and '31-16-15' lists sections. These concrete examples fully explain the optional 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?

Names the resource clearly as the Indiana Code outline and specifies the exact hierarchical levels returned: titles, articles, chapters, and sections. It does not explicitly contrast itself with siblings such as ic_get_section or ic_search, so it falls just short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives concrete node_id invocation patterns, but only describes traversal behavior rather than when to choose this tool over alternatives like ic_get_section or ic_search. The usage is implied by 'outline' rather than explicitly routed against siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: mentions are not construal and are not a good-law signal. It does not describe pagination or result ordering, but the output schema covers return structure.

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

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

Three tightly written sentences: purpose first, the critical caveat second, and court values last. No sentence repeats the title or wastes space, and the important limitation is front-loaded.

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 five-parameter tool with zero schema descriptions, the definition is strong on purpose and on the citator caveat but incomplete on the temporal and pagination filters. An agent can call it with only section_id, but it cannot know how after/before are formatted or what limit does beyond the default value.

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 0% schema description coverage, the description must carry parameter semantics. It explains the required section_id format ('35-42-1-1') and gives the court enum values (ind, indctapp, indtc), which is useful, but it leaves after, before, and limit completely unexplained, so three of five parameters remain opaque.

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

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

States a specific resource and scope: opinions whose text mentions a given Indiana Code section. It explicitly distinguishes itself from a citator and from cases that construed, applied, or followed the statute, so an agent can tell it apart from cases_construing and case_search without opening another 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 clearly says when not to rely on this tool: it is a text-mention index, not a citator, and not a good-law signal. However, it does not explicitly name an alternative tool such as cases_construing for the construed/applied/followed use case, leaving the agent to infer the routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real value by disclosing the data coverage window and that long acts are paginated. It doesn't say what happens when act_id is unknown or whether paging is stable, but the additions are meaningful.

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

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

Three short sentences, front-loaded with what is returned and the key identifier format. The parenthetical coverage window interrupts the act_id sentence slightly, but nothing is wasted.

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

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

With an output schema present, return shape needn't be explained; the description covers identifier format, coverage limits, and paging, which is what an agent needs to call it correctly. Missing only error/empty-result behavior.

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 0%, so the description must carry the load: it supplies the act_id format example ('P.L.98-2026') and explains that limit/offset exist for paging long acts. Only defaults and integer typing remain unaddressed, which is a minor gap.

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

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

States a specific verb+resource ('The Code sections an act amended, added or repealed') with a scope detail (effective dates) that distinguishes it from siblings like ic_get_section and ic_browse. An agent can tell this returns an act's code-change footprint, not a single section.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The coverage note ('loaded for 2017 and 2019 to 2026') implicitly tells the agent when this tool yields results, and the paging note tells it when to add limit/offset. However, no sibling is named and no explicit when-not-to-use guidance is given.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral detail that the annotations do not: pages are 1-based and doc_id is a slug-style identifier. It does not say what happens with out-of-range pages, how many pages exist, or whether results are stable, so it adds context without being rich.

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

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

Two tight sentences with no filler, and the resource identification is front-loaded before the paging rule. It is efficient, though the brevity comes at the cost of the usage routing an agent would want.

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

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

An output schema exists, so return values need not be explained, and the two-parameter surface is simple. However, for a paged retrieval tool the description never explains how paging terminates or how it relates to the sibling list/search tools, leaving a real gap in the retrieval loop.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden, and it does explain both params meaningfully: doc_id via concrete examples, and page via the 1-based note (the schema only supplies a default of 1). It stops short of giving the page size or valid page range, which would have made it fully self-sufficient.

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 concrete resource (one page of a companion document) and clarifies scope with the doc_id format (e.g. 'constitution-2026', 'acts-2026'). The verb is carried only by the name/title rather than the description, and it does not contrast itself with ic_get_act, ic_get_section or ic_search_companion, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no statement of when to use this versus ic_list_companion, ic_search_companion or ic_get_act, and no mention of how a doc_id is first obtained. The doc_id example and the 1-based page note imply the intended flow (list/search, then fetch a page) but nothing is stated explicitly.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds what the annotations cannot — the temporal-validity caveat and the presence of pending_acts, confidence, and flags that signal uncertainty. The one weakness is that the January–June warning is stated without explaining why that window is risky.

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

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

Two dense sentences with purpose and parameters front-loaded and zero filler. The final caveat is compressed to the point of being slightly opaque, but it is still information-bearing rather than waste.

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

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

With an output schema present, the description needn't enumerate return fields, and it correctly focuses on the reliability caveat instead. Coverage of both parameters plus the confidence/flags warning makes it callable without further reading; only sibling disambiguation and failure behavior are 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 0%, so the description must carry the parameter burden and largely does: it supplies an example section_id format ('31-16-15-25') and gives as_of's format and default (YYYY-MM-DD, today). It stops short of stating whether as_of accepts only ISO dates or what happens if the id is malformed.

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

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

States a concrete verb+resource ("Text of one section") with a well-formed example identifier and an explicit temporal dimension ("as of a date"). An agent can distinguish it from search/browse siblings, though it never names ic_get_versions, which is the nearest alternative for version-related questions.

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 closing sentence gives a real usage condition ("Check flags and confidence before relying on a date between January and June"), which is a useful caution. However, there is no explicit routing guidance against siblings like ic_get_versions or ic_resolve_citation, so the agent must infer which tool to reach for.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behaviour. The description adds a genuine scope constraint (2017–2026 coverage window) but otherwise spends its text on return fields that the output schema likely covers, and it does not mention pagination, result limits, or how versions are ordered.

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?

A single front-loaded sentence with no filler; the scope window comes early and the output fields follow compactly. It could be tightened by omitting return-field detail already present in the output schema, but it is efficient overall.

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?

Annotations cover the safety profile and an output schema exists, so the description does not need to explain return values. The main gap is that the sole required argument is undocumented and there is no routing guidance among the many ic_* siblings.

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 is one required parameter, section_id, with 0% schema description coverage. The description refers to 'a section' but never explains the expected identifier format or how a section_id is constructed, leaving the agent to guess the required input syntax.

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

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

The description clearly identifies the resource (versions of an Indiana Code section) and its scope (2017–2026, distinct versions with effective dates). It is distinguishable from ic_get_section by emphasising historical versions, though it does not name the sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the output description: an agent can infer this is for retrieving version history rather than the current section text. However, it never states when to use this instead of ic_get_section, ic_get_act, or ic_resolve_citation, nor does it state any prerequisites or exclusions.

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

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

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful context that these are PDFs loaded from the IGA downloads page and lists valid kind categories, but it does not disclose ordering, pagination, or whether year filtering changes the result set.

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 two tight sentences with the resource scope front-loaded and the kind values listed immediately after. There is no filler or repetition.

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?

This is a simple read-only listing tool with an output schema and strong annotations, so the description does not need to explain return values. However, with 0% schema descriptions, it should explain the 'year' filter and ideally distinguish this tool from search/get siblings; those gaps leave it only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It usefully enumerates the allowed kind values despite the schema lacking an enum, but it entirely omits the 'year' parameter, leaving half the parameters undocumented.

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 ('List') and resource ('Constitution, Non-code, full Acts, and archive-title PDFs'), with the source ('IGA downloads page'). It does not explicitly distinguish this tool from siblings like ic_search_companion or ic_get_companion, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides no guidance on when to use this tool instead of ic_search_companion, ic_get_companion, or ic_browse. The sentence about kind values constrains the parameter but does not explain when or why to choose this listing operation.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds non-obvious behavior beyond them: it parses multiple citation spellings and falls back to nearby sections when an id does not exist. That fuzzy-resolution behavior is exactly the kind of trait an agent could not infer from 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?

A single sentence, front-loaded with the verb and resource, with examples placed immediately after the key noun. No filler sentences or restated 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?

Output schema exists so return values need not be enumerated, and the description still summarizes them; annotations cover the safety profile. The remaining gap is ambiguity handling — what is returned when text contains several citations or an unresolvable one, beyond the 'nearby sections' note.

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?

One required parameter with 0% schema description, so the description must carry meaning — and it does, giving three concrete example strings ('IC 31-16-15-25', 'I.C. § 7.1-1-1-1', 'Ind. Code § 35-42-1-1 (2024)') that define what 'text' accepts, including year-qualified forms. It does not say whether the whole text can be long or contain multiple citations.

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?

Specific verb+resource: 'Find Indiana Code citations in free text' with concrete examples of accepted formats and a stated return (canonical section ids, headings). It is clearly distinguishable in intent from id-fetching siblings such as ic_get_section, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The examples imply the 'when' (you have unstructured text, not a known id), and the trailing clause hints at a fallback when an id does not resolve. But there is no explicit guidance like 'use this first, then ic_get_section with the returned id' nor any statement of when not to use it.

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

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description still adds real value by disclosing that results are deduplicated to one hit per section and are snippets rather than full text, which shapes how an agent plans retrieval.

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

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

Three dense sentences: purpose and return shape first, next-step routing second, then parameter semantics. No filler, no restatement of 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?

An output schema exists, so return values needn't be explained, yet the description still frames them usefully. The only real gap for a search tool is the behavior of `limit` (cap, pagination) and what happens when no snapshot year is given by default.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden — and it does for three of four params: `query` is implied by full-text search, `as_of` is given a format (YYYY-MM-DD) plus semantics (year's snapshot), and `title` is given example values ('31', '7.1'). Only `limit` (default 10, no stated maximum) goes undocumented.

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

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

States a specific verb and resource ('Full-text search of Indiana Code sections') and implicitly distinguishes itself from case_search and ic_browse by naming the code and the full-text mode. It also declares the return shape (section ids, headings, snippets) so an agent knows exactly what it gets.

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 routes the follow-up step explicitly ('fetch the text with ic_get_section') and explains the two narrowing dimensions (title number, snapshot year). It stops short of saying when to prefer this over ic_browse or ic_search_companion, which are plausible alternatives an agent must still infer.

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

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description doesn't need to restate that. It adds the important detail that the index covers PDFs rather than structured sections, and points to the companion fetch tool, but says nothing about ranking, matching semantics, or behavior when no results are found.

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

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

Two short sentences, no wasted words, and the corpus scope is front-loaded, with the sibling pointer following naturally. Nothing to trim.

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

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

An output schema and annotations carry the return format and safety profile, but with 0% parameter documentation and a 'kind' filter of unknown domain, the definition leaves an agent guessing at invocation details for a 4-parameter search tool. The corpus scope is well covered; the filtering contract is not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across four parameters, and the description only implies that 'query' is a full-text string. The 'kind' and 'year' filters, which clearly shape the search, are documented nowhere and the description does not compensate. An agent cannot know what values 'kind' accepts or how 'year' interacts with query.

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 and resource ('Full-text search of companion PDFs') and enumerates the corpus it covers (Constitution, Non-code statutes, full Acts text, archive titles), which lets an agent distinguish it from the generic 'ic_search' sibling. It stops short of explicitly contrasting with ic_search or ic_list_companion.

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 routes the agent to 'ic_get_companion for a page', which clarifies the search-vs-fetch boundary, but there is no guidance on when to use this over 'ic_search' or 'ic_list_companion', which are equally plausible for IGA content. Usage is implied by corpus scope rather than stated.

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