Skip to main content
Glama

Indiana Code

Cases citing a court and year

cases_citing_court
Read-onlyIdempotent

Indiana opinions whose text has a (court year) parenthetical. court is an Indigo-style abbreviation such as '7th Cir.', 'N.D. Ind.', 'S.D. Ind.', or 'Ill.'. year is optional (2021). citing_court filters the citing Indiana court (ind, indctapp, indtc). Text-mention index only: not a citator, not treatment, not good law.

Input Schema

NameRequiredDescriptionDefault
yearNo
afterNo
courtYes
limitNo
beforeNo
citing_courtNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.