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

No annotations are supplied, so the description carries the full burden. It usefully discloses the return format ('full Markdown text') and that input is an identifier or URL, but says nothing about pagination/size limits, cost or rate limits, or what happens with an invalid or ambiguous 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 well-formed sentence with no wasted words, and the resource and jurisdiction are front-loaded. It is perhaps too terse for a tool with no annotations, but nothing is redundant.

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 pagination is covered in the schema. However, with zero annotations and no usage guidance, an agent gets no signal about prerequisites, failure modes, or document-size limits before calling.

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 both parameters (page with its 5,000-character page sizing, and document_id_or_url with its ECLI/ELI/official ID semantics) are already documented. The description only echoes the identifier types, adding no meaning beyond the schema, so 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?

The description uses a specific verb ('Retrieve'), names the resource ('full Markdown text of a legislation document or court judgment'), the jurisdiction (Italy/IT), and the addressing schemes (URL or official identifier). This clearly separates it from the search_* siblings, though it never names an alternative 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?

There is no when-to-use or when-not-to-use guidance and no stated prerequisite that the identifier must first come from search_legislation or search_case_law (that hint lives only in the schema). An agent must infer the retrieval-after-search workflow entirely.

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 disclosure burden; it does indicate the tool is a read-only listing and names the scope (Italy only) and the content of the result. It does not state whether the data is static versus live, whether results are paginated, or whether sub-portals appear as nested entries. With an output schema present, the return shape is partly covered, but the operational behavior remains underspecified.

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?

It is a single front-loaded sentence with no filler prose, which is good. However, the parenthetical slash-lists ('Regional / Cantonal / County / Appellate Courts') pad the sentence with hedging synonyms while the tool is scoped only to Italy, so several of those terms earn no place. It could be tightened without losing 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?

For a zero-parameter reference tool with an output schema, the description need only say what the structure contains and how it should be used. It covers the contents adequately but omits the key connecting detail for this tool family: whether the tier/court identifiers returned are the inputs expected by search_tiered_court_decisions. That gap limits completeness given the sibling set.

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 takes zero parameters, so there is nothing for the description to disambiguate beyond confirming the absence of filters. The baseline of 4 applies. It is arguably useful that the description tells the agent the jurisdiction is fixed to Italy, implicitly explaining why no country argument exists.

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 gives a specific verb and resource: 'Return the complete step-by-step multi-tier judicial hierarchy for Italy (IT)', and it enumerates the three tiers plus sub-portals. That is enough for an agent to know it retrieves a static reference structure rather than documents. It does not name or contrast itself with the closest sibling, search_tiered_court_decisions, 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 when-to-use statement, no prerequisite, and no mention of the sibling tools. 'Return the hierarchy' describes the output, not the situation that selects this tool over searching court decisions. An agent must infer that this is a lookup/reference tool used before or instead of a search.

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 discloses almost nothing beyond subject matter. It does not state that this is a non-mutating retrieval operation, whether results are full text or metadata, how pagination behaves, or any rate/authentication constraints. Listing the supported courts is the only behavioral context offered.

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?

It is a single front-loaded sentence that establishes scope immediately, with no filler. The only inefficiency is mild redundancy: the list of courts appears in the prose and again inside the parenthetical, and is duplicated a third time in the schema.

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?

Because an output schema exists, return-value details need not be explained. However, for a search tool sitting among four related siblings, the description omits routing guidance and any note on how this differs from tiered-court or legislation search, leaving a meaningful gap in context.

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 are already documented in the schema, which sets the baseline at 3. The description echoes the court enumeration already present in the 'court' parameter description and adds no new syntactic guidance for 'query' (e.g., how ECLI vs keyword queries behave differently).

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 gives a specific verb ('Search') and resource ('Italy (IT) court decisions and binding precedents') and enumerates the covered courts, so an agent knows exactly what corpus is queried. It does not, however, explicitly distinguish itself from siblings such as search_tiered_court_decisions or search_legislation, leaving the boundary to be inferred from the name.

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 guidance, no exclusions, and no mention of the alternative tools (search_tiered_court_decisions, search_legislation, verify_citation) that an agent must choose between. The jurisdiction and court coverage is stated, but selecting this tool over its siblings remains entirely implicit.

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 burden, and it does add useful context by naming the upstream registry (normattiva.it) and the document types searched. It says nothing about whether results are metadata-only or full text, result ordering/ranking, rate limits, or authentication, all of which matter for a search tool with a limit cap. An output schema exists, so return shape need not be described.

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, and the jurisdiction and source are stated immediately. Slightly overstuffed with parenthetical synonyms and website names, but every element is informative.

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 an output schema and no annotations, the description covers what is searched and where, but leaves the agent guessing about result nature (full text vs. citation metadata) and about sibling selection. It is adequate but short of what a no-annotation tool needs.

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 the schema already documents query, year, and limit including the 1-50 range and default. The description contributes only indirectly, via the enumerated document types that hint at useful query vocabulary. 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?

The description gives a specific verb (Search) and a specific resource (Italy national legislation), then enumerates the covered document types (statutes, acts, codes, regulations) and names the source (Normattiva). This distinguishes it in substance from search_case_law, though it never says so explicitly, and the trailing 'European/International legal registries' clause blurs whether the scope is Italian-only or multi-jurisdictional.

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 word 'legislation' suggests this is for statutes rather than court decisions, which is enough for an agent to route away from search_case_law. There is no explicit when-to-use, when-not-to-use, or statement of which sibling handles case law, treatises, or citation verification.

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 carries the full behavioral burden. 'Search' implies a safe read operation and the description discloses the Italy-only scope and tier model, but it does not describe result ordering, pagination, permissions, or other operational behavior.

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 geographic scope and tier model front-loaded. Every clause contributes to selecting or invoking the tool.

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 the output schema and 100% parameter description coverage, the description supplies enough context to call the tool correctly: search scope, tier options, and how to obtain sub_court keys. The main omission is an explicit distinction from the generic search_case_law sibling.

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 all four parameters. The description adds useful context by mapping Tier 2 to appellate/regional/cantonal courts and linking sub_court to list_court_hierarchy, but most parameter meaning still comes from the schema.

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 and resource: search court decisions in Italy, filtered by judicial tier or court. It distinguishes the tool through tiered court filtering and names list_court_hierarchy for sub-portal keys, though it does not explicitly contrast itself with the sibling search_case_law.

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: use this tool when searching Italian court decisions by tier or specific court. It points to list_court_hierarchy for sub_court keys, but gives no explicit when-not guidance or comparison with search_case_law.

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. It usefully discloses that verification is against 'official Italy and ECLI/ELI registries' and that existence is checked live, but it does not say what happens on failure, whether lookups are network-dependent or rate-limited, or how partial matches are treated.

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 dense sentence with the core purpose front-loaded and no filler. It is slightly overloaded by packing jurisdiction, registries, and rationale into one clause, 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?

For a one-parameter tool with an output schema (so return values need not be explained), the description covers scope, sources, and intent adequately. The main residual gap is failure/edge-case behavior, which is minor given the tool's simplicity.

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% for the single 'citation' parameter, so the baseline is 3. The description's examples ('ECLI:IT:CASS:2024:1234CIV', 'Legge 241/1990') reinforce the accepted formats but add little beyond what the schema already documents.

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 format and live existence') and resource ('legal citations') with an explicit jurisdiction scope (Italy/IT) and concrete examples. It is clearly distinguishable from the sibling search_* tools, which retrieve documents rather than verify a given citation.

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 use case (checking a citation before relying on it), but there is no explicit when-to-use/when-not guidance and no named alternative among the siblings. Usage is inferable rather than stated.

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