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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the return content ('full Markdown text') and the covered document types and jurisdiction, but says nothing about pagination of long documents, permission requirements for accessing documents, or behavior on an unresolved identifier.

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 that names the action, the output format, the resource scope, and the jurisdiction with zero filler. Nothing in it is redundant or misplaced.

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 is simple (two parameters, output schema present) and the description covers purpose, scope, and input forms adequately. However, with no annotations at all, it leaves an agent guessing about paging through long judgments and about failure modes for malformed identifiers.

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 schema already documents both parameters including the 5,000-character page semantics. The description adds only that the identifier may be a URL or official identifier, which the schema already states, so it does not meaningfully exceed the baseline.

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 ('Retrieve'), a specific output form ('full Markdown text'), the resource types covered ('legislation document or court judgment'), and the jurisdiction ('Ireland (IE)'). This clearly separates it from the search_* siblings, which return identifiers rather than full text, though no sibling is named 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 rather than stated: 'by its URL or official identifier' hints that this is the follow-up step to a search, and verify_citation is not mentioned as an alternative for citation checking. No explicit when-to-use or when-not-to-use guidance is present.

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?

No annotations are provided, so the description carries the full burden. 'Return' implies a read-only listing and it specifies scope (Ireland, all tiers, sub-portals), but it does not explicitly state read-only safety, auth requirements, or whether results are static or cached.

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 informative tier parentheticals. It is dense but not redundant, and the key purpose appears first.

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 zero-parameter list tool with an output schema, the description sufficiently explains what is returned. It could mention usage context or whether the hierarchy is static, but the output schema covers return structure.

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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter meaning because none exist.

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 ('Return') and resource ('complete step-by-step multi-tier judicial hierarchy for Ireland'), enumerates the tiers and sub-portals, and is clearly distinct from the sibling search tools.

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?

Provides no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as search_tiered_court_decisions. Usage is only implied by the tool name and return content.

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?

With no annotations, the description must carry the behavioral burden, and it does disclose the source system and the three supported court codes, which is real context. However it says nothing about authentication, rate limits, pagination or result ordering — and for a search tool whose caller needs to know how results are bounded, those gaps are notable. An output schema exists, so return-value shape need not be restated.

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 the resource and jurisdiction first and the court enumeration in a trailing parenthetical — no filler. Minor deduction because the court list is duplicated from the schema and the sentence becomes dense with nested parentheses.

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 three-parameter search tool with a full output schema and no annotations, the description supplies what the agent actually needs: jurisdiction, authoritative source, and the supported court codes. Return values are covered by the output schema, so the remaining omission (sibling disambiguation) is a routing concern rather than a completeness defect for invoking this tool.

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 all three parameters (query, court, limit) are already fully documented in the schema, including the court enumeration and limit bounds. The description adds no syntax hints, no advice on query construction, and only repeats the court code list verbatim, so the baseline of 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?

States a specific verb+resource (search court decisions and binding precedents) plus the jurisdiction (Ireland) and the exact data source (courts.ie), which is concrete and differentiating. It falls short of a 5 because it never distinguishes itself from the close sibling search_tiered_court_decisions, leaving the agent to guess which search surface to pick.

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: the agent can infer this is the tool for Irish case law and that the court list scopes the search. There is no explicit when-to-use versus search_tiered_court_decisions, verify_citation, or get_legal_document_markdown, and no stated exclusions (e.g. non-IE jurisdictions or non-binding material).

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?

No annotations are supplied, so the description bears the full burden of behavioral disclosure. It reveals useful provenance (irishstatutebook.ie, Oireachtas Open Data API, European/International registries), signalling multi-source aggregation, but says nothing about authentication, rate limits, result ordering, pagination, or partial-source failure behavior for a tool that fans out across several registries.

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 the jurisdiction and resource stated first and sources appended; no filler. The ampersand-joined source list is slightly cluttered but every clause carries information.

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 and all three parameters are fully documented, so the definition is callable as-is for a simple search tool. What remains missing is cross-tool orientation - when this beats search_case_law - which matters given five sibling tools in a legal research suite.

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 query, year, and limit are already documented in the schema with defaults and a 1-50 bound. The description adds no meaning on top of that - it never mentions that 'year' is an enactment-year filter or that the query accepts statute titles or numbers, though the schema already covers both.

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 ('Search Ireland (IE) national legislation') and enumerates the covered document types (statutes, acts, codes, regulations), which makes it functionally distinguishable from search_case_law. It stops short of explicitly naming the case-law sibling as out of scope, so differentiation requires inference.

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 when-to-use, when-not-to-use, or alternative routing guidance. Nothing tells the agent when to pick this over search_case_law, verify_citation, or get_legal_document_markdown, and there is no mention of prerequisites or jurisdiction limits (whether non-IE queries return empty results).

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?

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about whether the operation is read-only, how results are ordered or truncated, whether hits are excerpts or full text, or any auth/rate constraints. The Tier 1/2/3 vocabulary adds some conceptual context beyond the schema's enum strings, but that is a small fraction of what an unannotated search tool should disclose.

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 sentences, front-loaded with the verb and scope, and the tier taxonomy follows immediately. Minor redundancy in restating 'regional/cantonal/appellate' twice (once in the opening clause, once inside the Tier 2 gloss), but no filler sentences.

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 100% schema coverage, one required parameter, and an output schema carrying return structure, the description covers the conceptual model an agent needs. Remaining gaps are the unresolved Ireland-vs-Balkan jurisdiction mismatch and the absence of any sibling differentiation against search_case_law.

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 and the schema already documents all four parameters. The description contributes the Tier 1/Tier 2/Tier 3 framing and the pointer to list_court_hierarchy for sub_court values, but its geography claim conflicts with the sub_court examples in the schema, leaving the agent with contradictory signals about valid key values.

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 ('Search court decisions') plus the distinguishing filter dimension (judicial tier or specific court). However, it never contrasts itself with the sibling search_case_law, and the stated jurisdiction ('Ireland (IE)') is not reconciled with the schema's Bosnia-style sub_court examples ('kanton_sarajevo', 'okruzni_banja_luka'), which muddies what corpus is actually searched.

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 rather than stated: the description makes clear the tool is the one that filters by tier/court, and it points at list_court_hierarchy as the source of sub-portal keys, which is a useful routing hint. It gives no explicit when-to-use versus search_case_law, no note that tier defaults to 'appellate_regional' if omitted, and no 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that validation covers both format and live existence against official Ireland and ECLI/ELI registries, which is meaningful context, but it does not describe failure behavior, permissions, rate limits, or what 'live existence' entails.

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 a single front-loaded sentence with examples and no redundant restatement. Every clause contributes to purpose, scope, or validation behavior.

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 one-parameter verification tool with a complete input schema and an output schema, the description covers scope, registries, and purpose adequately. It omits sibling routing and failure semantics, but those gaps are less severe given the structured fields.

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% and the single citation parameter is fully documented with examples. The description repeats the same examples and adds no syntax or format rules beyond the schema, 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?

States a specific verb ('Validates') and resource ('legal citations') with Ireland scope and examples. It is distinguishable from the search/get/list siblings because it verifies rather than retrieves, though it does not explicitly name alternatives.

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 phrase 'to prevent AI-hallucinated citations' implies the tool should be used before relying on a citation, but there is no explicit when-to-use guidance versus search_case_law or search_legislation. No exclusions or routing conditions are stated.

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