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

With no annotations, the description carries the full burden; it does disclose the output format (Markdown) and the geographic/jurisdictional scope, which implies a read-only fetch. However, it says nothing about pagination of long documents, truncation limits, failure modes for unavailable identifiers, or authentication, so the behavioral picture is only partial.

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: verb, output form, resource type, jurisdiction, and lookup key all land immediately. Nothing is redundant or buried.

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 two-parameter fetch tool with a full output schema and 100% schema coverage, the description covers what is returned and how it is addressed, so return-value explanation is rightly omitted. The remaining gap is the absence of any hint that long documents require the page parameter or that identifiers come from the search 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 both parameters (document_id_or_url and the page offset with its 5,000-character chunking) are already documented in the schema. The description restates the accepted identifier forms but adds no format examples, precedence rules, or interaction between identifier and paging beyond what the schema supplies.

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 ('Retrieve'), a precise resource ('full Markdown text'), and explicit scope ('legislation document or court judgment from Latvia'), plus the input forms it accepts. An agent can readily distinguish this fetch operation from the search-oriented siblings, though no sibling is named directly.

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 phrase 'by its URL or official identifier' suggests the agent must first obtain an identifier (presumably from search_legislation or search_case_law), but the description never states when to call this versus those tools or what preconditions apply. No exclusions or alternative routing are provided.

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, and "Return" plus a pure content enumeration makes clear this is a side-effect-free read of a fixed reference structure. It does not say whether the hierarchy is static or changes over time, which is the only material behavioral gap for a zero-parameter lookup.

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?

One front-loaded sentence with the country and return scope up front; the slash-separated synonyms (First Instance / Trial / Municipal / District) earn their place by helping an agent map local terminology. It is dense but not padded, though the trailing "and all official court sub-portals" is the vaguest element.

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?

A parameterless reference tool with an output schema needs only to say what the returned structure covers, and this description does exactly that down to the individual tiers. Return formatting is already handled by the output schema, so nothing an agent needs is missing.

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 the baseline is 4 and there is nothing for the description to disambiguate. It correctly spends no words on inputs.

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?

"Return the complete step-by-step multi-tier judicial hierarchy for Latvia (LV)" names a specific verb and resource, then enumerates the exact tiers returned. Nothing about this overlaps with the search_* or verify_citation siblings, so an agent can place it immediately.

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 explicit statement of when to call this versus alternatives, no mention that it is a static reference lookup, and no hint that its tier vocabulary feeds search_tiered_court_decisions. Usage is only implied by the zero-parameter, enumeration-style description.

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 does disclose provenance (official court portals) and the exact scope of courts searched, which is genuinely useful behavioral context. It omits any statement about permissions, rate limits, latency, or result ordering — and being a read-only search, the safety profile is at least implied but never confirmed.

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 leads with the action and jurisdiction, which is efficient. It is slightly dense with parenthetical source and court lists that partly duplicate the schema's court enum, but nothing is wasteful enough to obscure the core purpose.

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 all parameters are schema-documented. The remaining gap is sibling disambiguation and operational context (result ordering, whether precedents are ranked) — adequate for a simple three-parameter search but not fully 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 description coverage is 100%, so all three parameters (query, court, limit) are already documented in the schema, establishing the baseline of 3. The description adds no meaning beyond that — it does not explain acceptable query syntax such as ECLI formats or how the court filter interacts with the free-text query.

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 Latvia (LV) court decisions and binding precedents') and names the concrete sources (eli.tiesas.lv, at.gov.lv, Satversmes tiesa) plus the covered courts. It does not, however, distinguish itself from the sibling search_tiered_court_decisions or search_legislation, so an agent cannot tell from the text alone which search tool 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 implied by the jurisdiction and source scoping — an agent can infer this is the tool for Latvian case law. But there is no explicit when-to-use, no exclusion conditions, and no routing to the closely related search_tiered_court_decisions or verify_citation siblings.

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 burden; it does add useful provenance by naming the underlying portals, which tells the agent results are authoritative official sources. However, it does not state that the operation is read-only, whether there are rate limits, or how results are ranked, so behavioral coverage remains partial.

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 scope stated first. The parenthetical '(Latvijas Vēstnesis)' and the dual portal list add length without much decision value, but nothing is wasted outright.

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 the three parameters are simple. Still, the description leaves ambiguity about whether the tool covers only Latvian law or also EU/international instruments, and offers no guidance on how to phrase a query, which matters for a legal search 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 query, year, and limit are already documented in the schema; the description adds no extra meaning such as query syntax, wildcard behavior, or how the year filter interacts with statute numbers. Baseline 3 applies when the schema does the heavy lifting.

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 (Search) and resource (Latvia national legislation: statutes, acts, codes, regulations), which clearly separates it from case-law siblings like search_case_law and search_tiered_court_decisions. It stops short of explicitly naming a sibling or stating a boundary, so it is clear but not fully 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?

It says where the search runs (Likumi.lv, European/International registries) but gives no when-to-use guidance, no exclusions, and no pointer to alternatives such as search_case_law for court decisions or verify_citation for checking a reference. The agent must infer routing from the resource noun 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, so the description carries the full behavioral burden, and it covers what is searchable and that results are filtered by tier. It discloses nothing about result volume behavior, pagination, cost, or ordering beyond the schema's limit parameter, and read-only nature is only implied by "Search." Adequate for a query tool but thin given the total absence of annotation coverage.

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 action and the resource, with no filler. The nested parentheticals around tier names are dense but each one disambiguates a value an agent must choose between, so the length is earned.

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 described, and all four parameters are documented in-schema; the description supplies the tier taxonomy and the pointer to list_court_hierarchy that complete the picture. The one gap is the unresolved Latvia-versus-Balkan-court-key tension, which an agent would want resolved before choosing a sub_court value.

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 already 100%, so the baseline is 3 — but the description earns above baseline by expanding the tier vocabulary into plain-language court types ("Tier 2 (appellate_regional — including Cantonal/Regional/County/Circuit courts)") and by directing sub_court lookups to list_court_hierarchy. That mapping is genuine meaning the schema alone does not convey.

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?

Opens with a specific verb+resource ("Search court decisions") and scope (Latvia, LV), and the tier enumeration makes the retrieval target unambiguous against siblings like search_legislation and search_case_law. Minor deduction: the schema's own sub_court examples (kanton_sarajevo, okruzni_banja_luka) are Balkan, not Latvian, which conflicts with the stated country and could leave an agent unsure what jurisdiction it is actually querying.

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?

Explicitly tells the agent the two retrieval modes — aggregate by tier (first_instance / appellate_regional / supreme_constitutional) or drill into one court — and points at list_court_hierarchy as the source of valid sub-portal keys, which is real routing guidance. It stops short of saying when NOT to use this tool (e.g. when search_case_law or search_legislation is the better call), so the sibling boundary is only implied.

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 burden: it does disclose that the check is a live lookup against official Latvia and ECLI/ELI registries (i.e., network-dependent, non-deterministic availability) plus a format validation step. It does not say what happens on lookup failure, whether unverifiable registries produce a soft or hard result, or any auth/rate constraints.

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?

One sentence, front-loaded with the jurisdiction and purpose, with no filler. Minor deductions for duplicating the schema's example string and for a malformed quotation in that example, which slightly muddies readability.

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 an output schema, the description covers scope (Latvia only), the sources consulted, and the intent. It could say more about what 'live existence' means when a registry is unreachable, but nothing essential to invoking it correctly is missing.

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 schema already documents the type and gives the same example. The description repeats rather than extends that example and adds no format rules (e.g., accepted ECLI syntax variants). 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 a specific resource ('legal citations ... for Latvia') and scopes it to LV/ECLI/ELI registries. This clearly separates it from siblings like search_case_law and search_legislation, which retrieve documents rather than verify a supplied 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 stated motivation ('to prevent AI-hallucinated citations') implies when to call it, but there is no explicit when/when-not guidance and no sibling is named as an alternative. An agent must infer that this is a post-generation check rather than a discovery tool.

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