check_constitutional_status

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that results include 'confirmed_reference (verified via referenced regulations),' notes it is 'Live from SAOS; not legal advice,' and warns against misinterpreting citations as invalidations. It implies a read-only operation. It lacks details like pagination or error handling, but covers key nuances for a legal search 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 compact, with a clear opening statement, a brief input instruction, and a warning. It front-loads the core purpose and avoids redundancy. The IMPORTANT note adds necessary caution without being verbose, though it makes the description slightly longer than ideal.

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 no output schema and no annotations, the description covers the essential input requirements and hints at the return value ('Returns TK judgments with confirmed_reference'). It also includes a legal disclaimer and a caution about interpretation. It does not fully explain the return structure, but for a search tool with well-described parameters, it is sufficiently 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 coverage is 100%, so the baseline is 3. The description adds value by grouping parameters into alternatives ('document_id or journal_year + journal_entry') and clarifying optionality ('optionally an article and title_hint'). It also mentions the output concept 'confirmed_reference,' which enhances understanding of how parameters affect results.

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: 'Find Polish Constitutional Tribunal (TK) judgments that cite a given statutory provision.' It specifies the resource (TK judgments), the action (find/cite), and the input method (document_id or journal_year + journal_entry). This distinguishes it from general case law search tools and aligns with the sibling 'find_judgments_for_provision' while adding a specific court focus.

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 usage context by explaining the required identifiers ('Provide document_id or journal_year + journal_entry') and optional parameters ('optionally an article and title_hint'). It also includes an important caveat about interpreting results ('does NOT by itself mean the provision was struck down'). However, it does not explicitly mention alternatives or when not to use this tool, so it falls 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.