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

With no annotations, the description carries the behavioral burden. 'Retrieve' implies a read-only operation, but the description does not mention pagination behavior, error cases, or access constraints; the output schema reduces the need to explain return values.

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 definition is a single front-loaded sentence with no wasted wording. It efficiently conveys the action, resource, jurisdiction, and lookup method.

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 simple retrieval tool with full schema coverage and an output schema, the description is nearly complete. The only minor gap is that pagination is left entirely to the schema rather than mentioned in prose.

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 are already documented in the schema, including page size and accepted identifier formats. The description reinforces the identifier usage but adds no meaning beyond the schema and does not mention the page parameter.

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: retrieve full Markdown text of a legislation document or court judgment from Liechtenstein. It also specifies the lookup key (URL or official identifier), which clearly distinguishes it from sibling search/list/verify 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?

Usage is implied by saying the document is retrieved by URL or official identifier, suggesting it is used after a search tool returns an identifier. However, it does not explicitly name alternatives or state when not to use this tool.

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 the tool returns a complete hierarchy and sub-portals, implying a read-only retrieval operation, but it does not mention authentication requirements, rate limits, pagination, or whether results are static or dynamic. Because an output schema exists, the return shape need not be explained in prose, which limits the severity of these gaps.

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 that identifies the resource first and then enumerates the tiers. The parenthetical tier aliases are somewhat verbose, but they add useful disambiguation for an agent unfamiliar with Liechtenstein's court naming conventions.

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 zero parameters, no annotations, and an existing output schema, the description provides enough context for an agent to call the tool correctly. It specifies the jurisdiction and the exact scope of the returned hierarchy. The only minor gap is the absence of explicit guidance on using this tool rather than one of the sibling search tools.

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 does not need to explain parameter semantics, and it correctly avoids discussing inputs entirely.

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, 'Return', and a precise resource: the complete step-by-step multi-tier judicial hierarchy for Liechtenstein. It explicitly enumerates the tiers and official court sub-portals, leaving no ambiguity about what the tool produces.

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 by the tool name and description: an agent should call it when it needs the court structure of Liechtenstein. However, the description does not explicitly state when to use this versus siblings such as search_tiered_court_decisions or search_case_law, nor does it name any 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 supplied, so the description carries the full behavioral burden, yet it discloses nothing about ranking, full-text vs metadata matching, result ordering, rate limits, or authentication. It does at least imply jurisdiction scope (LI only) via the source sites, but an agent learns no operational traits from it.

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 the verb and scope leading and supporting detail trailing. The heavy nested parentheses make it dense, and the court list is duplicated in the schema, but there is no filler.

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 output schema covers return values and the schema covers all parameters, so the main gaps are routing guidance versus sibling search tools and any note on search behavior or result limits. For a search tool with no annotations, this is adequate but thin.

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%, with all three parameters documented in the schema including defaults, min/max, and the court value list, so the baseline is 3. The description mildly reinforces the court filter by enumerating OGH/StGH/VGH, but adds no meaning beyond 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 (Search) and a specific resource (Liechtenstein court decisions and binding precedents), and names the source systems (gerichte.li, Staatsgerichtshof) and the three supported courts. It is clear what the tool does, but it does not position itself against close siblings such as search_tiered_court_decisions or verify_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?

There is no when-to-use or when-not-to-use guidance at all. With siblings like search_tiered_court_decisions and search_legislation, an agent must guess which search tool to call, and nothing says when the optional court filter should be applied or what query forms are best supported.

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 supplied, the description must carry the full behavioral burden. It usefully discloses the retrieval source (Lilex/gesetze.li and legal registries), which hints at coverage and freshness, but says nothing about ranking, full-text vs title matching, authentication, or rate limits.

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 scope statement comes first. The only weakness is that the appended registry phrase adds ambiguity rather than 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 simple three-parameter read operation with a fully described schema and an output schema, the description supplies enough for correct invocation. The main remaining gap is routing guidance relative to the case-law and citation-verification siblings.

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. The description adds only indirect context by listing the kinds of legal instruments the query matches, without clarifying matching syntax or what the year filter applies to.

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 Liechtenstein (LI) national legislation') and enumerates the document types covered (statutes, acts, codes, regulations), which distinguishes it from the case-law siblings. It also names the underlying source (Lilex / gesetze.li), though the trailing 'and European/International legal registries' slightly muddies the stated national scope.

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 domain scope implies when to reach for this tool versus search_case_law or verify_citation, but there is no explicit when-to-use, when-not-to-use, or named-alternative guidance. An agent must infer the routing decision from the resource type alone.

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, but the tool is evidently a read-only search and an output schema exists, so return shape need not be described. The description does add real context by disambiguating what 'appellate_regional' covers (Cantonal/Regional/County/Circuit). It says nothing about result ordering, default tier behavior, or that no state is mutated, so the behavioral picture is only partially filled in.

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 resource and jurisdiction, then the filtering options. Every clause carries information; no filler or restatement of the title.

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, the description covers enough for correct invocation. The only notable gap is precedence between tier and sub_court, and the schema's sub_court examples ('kanton_sarajevo', 'kanton_tuzla') appear to be Bosnia-based while the description claims Liechtenstein, which could mislead an agent.

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 a 3 is the baseline, but the description earns above that by explaining the tier taxonomy in prose and by pointing out that sub_court values come from list_court_hierarchy. That is meaning an agent would not get from the schema alone. It does not explain how tier and sub_court interact when both are supplied.

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 in Liechtenstein (LI)') plus the filter axis (judicial tier / regional-cantonal-appellate court). It names the three tiers it exposes, so an agent knows the scope precisely. It stops short of distinguishing itself from the sibling search_case_law, so it is clear but not sibling-differentiated.

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 by the enumeration of tier and sub_court options, and it routes the agent to list_court_hierarchy for valid sub-portal keys, which is genuinely useful guidance. However, there is no explicit statement of when to prefer this over search_case_law or search_legislation, 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?

With no annotations, the description carries the full disclosure burden. It usefully reveals that verification queries official Liechtenstein and ECLI/ELI registries (i.e., a live network lookup, not a local format check), but says nothing about failure behavior, latency/rate limits, or what an unverifiable vs. malformed citation yields.

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 tool's purpose before the registry detail. Slightly redundant in restating the title ('Citation Verifier') and packing two ideas (format vs. existence) into one clause, but nothing extraneous.

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 single-parameter tool with a full input schema and an output schema, the description covers jurisdiction, source registries, and intent. The main residual gap is how partial or ambiguous citations are handled, which matters for a verifier but is a minor omission here.

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?

Only one parameter, and schema description coverage is 100%, so the schema already documents it. The description's examples of acceptable citation forms add modest meaning beyond the schema's identical example, 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?

States a specific verb ('validates format and live existence') and resource ('legal citations' for Liechtenstein), plus concrete citation examples ('LES 2024, 15', 'LGBl. 2024 Nr. 10'). This is clearly distinct from the sibling search_* and get_* tools, which retrieve documents rather than verify a reference.

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 reference before relying on it), but there is no explicit when-to-use, when-not-to-use, or named alternative such as search_legislation for finding citations you don't yet have. Guidance is inferable but not stated.

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