Indiana Code

In Code Section

in_code_section

Read-onlyIdempotent

Get the FULL TEXT of a section of the Indiana Code — Indiana state law — by citation, plus when it was added or amended. "IC 9-21-5-5" is an oversized-vehicle speed limit (traffic, Title 9); "IC 32-31-3-6" defines "rent" in the landlord-tenant chapter (Title 32). An ARTICLE ("IC 24-16") or CHAPTER ("IC 24-16-4") reference also works — it returns that group's own section list (citation + heading for each) instead of failing, so you can pick the right one and call this again for its full text. Pass year (e.g. 2020) to retrieve a historical annual edition instead of the current code — Indiana publishes a separate archived edition per year. Keyless. Use for "what does Indiana Code 9-21-5-5 say" or to check an Indiana statute a lease, ticket, or case relies on.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "section": "9-21-5-5"
    },
    "name": "in_code_section"
  }
}

Input Schema

Name	Required	Description	Default
`year`	No	Optional 4-digit year for a historical annual edition, e.g. "2020". Omit for the current Indiana Code.
`section`	Yes	Section, chapter, or article as cited — "9-21-5-5" (section), "24-16-4" (chapter), "24-16" (article). The title is the part before the first dash (title "7.1" is the one exception that itself contains a dot).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "section": "9-21-5-5"
-  }
-]New value: +[
+  {
+    "section": "9-21-5-5"
+  },
+  {
+    "section": "24-16"
+  }
+]

changedInput schema / properties / section / description

Previous value: -"Section as cited, e.g. \"9-21-5-5\" or \"32-31-3-6\". The title is the part before the first dash (title \"7.1\" is the one exception that itself contains a dot)."New value: +"Section, chapter, or article as cited — \"9-21-5-5\" (section), \"24-16-4\" (chapter), \"24-16\" (article). The title is the part before the first dash (title \"7.1\" is the one exception that itself contains a dot)."

First observedOct 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent/open-world safety, so the description's added value is real: article/chapter references degrade gracefully into a section list instead of failing, `year` selects a separately archived annual edition, and the tool is keyless. It stops short of describing error behavior for bad citations or any pagination/return-shape limits.

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

Conciseness4/5

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

The lead sentence front-loads the action and return content; the examples, fallback behavior, and `year` note each add distinct information. It runs long with several illustrative asides, but no sentence is purely filler.

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

Completeness5/5

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

Even without an output schema, the description explains what comes back in both the section case (full text plus amendment date) and the article/chapter case (citation + heading per section), plus historical-edition behavior and keyless access. An agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100% and already documents both params, but the description adds genuine meaning: it shows worked citation formats per level (section vs chapter vs article) and how a returned section list is meant to be followed up. The title-numbering caveat lives only in the schema, not the description.

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

Purpose5/5

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

States a specific verb and resource ('Get the FULL TEXT of a section of the Indiana Code') plus what else comes back (added/amended dates). The concrete citations and the Title/Article/Chapter breakdown make it unmistakable next to a search-style sibling like in_code_search.

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

Usage Guidelines4/5

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

Gives an explicit use case ('what does Indiana Code 9-21-5-5 say' or verifying a statute a lease, ticket, or case relies on) and explains that article/chapter refs return a section list to re-call on. It does not explicitly name in_code_search as the alternative for keyword lookup, so 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.

All Indiana Code tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.