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

With no annotations supplied, the description must carry behavioral disclosure, and it does contribute one key fact: the return is full Markdown text, not a citation or snippet. However, it says nothing about the fact that results are paginated in ~5,000-character pages (only visible in the schema), nor about truncation, completeness guarantees, or access 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?

A single sentence that front-loads the verb and resource, with jurisdiction and addressing method packed in without wasted words. Nothing is repeated and no preamble exists.

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 an output schema and fully documented inputs, this description covers the essential who/what/how. The only material gap is the absence of any hint about paginated retrieval, which a caller must discover from the schema to avoid stopping at page 1.

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, including the page size and the ECLI/ELI/official-ID forms. The description's phrase 'by its URL or official identifier' reinforces but does not extend the schema's meaning, so this sits at the baseline for fully documented schemas.

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 pairs a specific verb ('Retrieve') with a specific resource ('full Markdown text of a legislation document or court judgment'), and adds scope ('Hungary (HU)') plus the addressing mechanism ('by its URL or official identifier'). This makes it immediately distinguishable from search_legislation and search_case_law, which locate documents rather than return their full text.

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: 'by its URL or official identifier' and the schema note that the ID is 'returned by search tools' suggest this is a follow-up fetch after a search. There is no explicit when-to-use statement, no exclusion of alternatives such as verify_citation, and no stated prerequisite that the document must first be located.

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 behavioral burden. It clearly describes the returned hierarchy content, but it does not explicitly state that the operation is read-only, has no side effects, or requires no special permissions. For a zero-parameter listing tool this is adequate but not fully transparent.

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 immediately states the return value and then enumerates the tiers. Every clause contributes useful scope information without unnecessary wording.

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 tool's low complexity, zero parameters, and existing output schema, the description is largely complete: it identifies the jurisdiction, the hierarchy tiers, and the sub-portals. It could be stronger by adding a brief usage or read-only behavioral note, but no critical information is missing for invocation.

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 there are no parameter semantics to document. The baseline for a parameterless tool is 4, and the description does not need to compensate for missing schema details.

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 and resource: "Return the complete step-by-step multi-tier judicial hierarchy for Hungary (HU)." It enumerates the three tiers and sub-portals, making clear this is a hierarchy lookup rather than a search or document-retrieval tool like the sibling 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?

The description does not state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Usage is only implied by the purpose statement, with no explicit routing guidance.

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 the source databases and court coverage, but says nothing about authentication, rate limits, result ranking, or what 'binding precedents' means operationally. For a search tool with zero annotation coverage, this leaves significant 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?

It is a single sentence, but it is tangled: the parenthetical court list appears twice (once as 'Supported courts' and again as the source list), and the ampersand construction makes the sentence hard to parse. Front-loading the verb and resource is good, but the duplication costs it.

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 the input schema is fully documented, so the description needn't explain return values. However, it omits the differentiation from the closely named sibling search_tiered_court_decisions, which is the main thing an agent needs to choose correctly among five legal-research 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?

Schema coverage is 100% and all three parameters are documented in the schema, so the baseline of 3 applies. The description restates the court list already present in the court parameter's description and adds no new meaning about query syntax or limit behavior.

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 — searching Hungarian (HU) court decisions and binding precedents — and names the underlying sources (birosag.hu, eakta.birosag.hu). It clearly covers case law rather than legislation, though it never explicitly contrasts itself with the sibling search_tiered_court_decisions, which sounds like it searches a very similar corpus.

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 at all: no statement of when to prefer this over search_tiered_court_decisions, search_legislation, or verify_citation, and no prerequisites or exclusions. The only usage-adjacent content is the list of supported courts, which is already in the schema.

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 mostly does not meet it: nothing about authentication, rate limits, pagination, or how HU national results interleave with the 'European/International legal registries' mentioned at the end. The only behavioral signal is the source list, which is thin for a search tool with no safety annotations.

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; the resource and jurisdiction lead. The trailing clause about European/International registries is compressed to the point of mild ambiguity about whether those are separate corpora or included results.

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 no explanation, and all three parameters are documented in the schema. What remains unaddressed is the scope relationship between Hungarian national law and the European/International registries, plus the absence of any behavioral notes in lieu of annotations.

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 all documented in the schema itself. The description adds no additional meaning about search syntax, how year filtering interacts with statute numbers, or how limit affects ranking, 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 (Search) and resource (Hungary national legislation) with an enumerated scope (statutes, acts, codes, regulations) and names the source registries. The word 'legislation' implicitly separates it from the case-law siblings, but the description never explicitly draws that line.

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 sibling is named as an alternative. An agent must infer from the sibling names (search_case_law, search_tiered_court_decisions) that this tool is for statutes rather than judicial decisions.

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 disclosure burden. It does reveal the scoping model (HU-only, tier-filtered, or narrowed by sub-portal key), but says nothing about result shape, citation formats, pagination, or failure behavior when a sub_court key is invalid; 'Search' implies read-only, which is the main safety signal available.

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 compact sentences with the jurisdiction and search scope front-loaded, then the tier breakdown. The tier parentheticals partly restate schema enum text, a small redundancy, but nothing is padded or off-topic.

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 description covers jurisdiction, the three-tier filter model, and the cross-reference to list_court_hierarchy. It is nearly complete for a search tool, missing only how tier interacts with sub_court and the meaning of tier='all'.

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, but the description adds genuine meaning by mapping each tier label to concrete court types (Cantonal/Regional/County/Circuit) and by explaining that sub_court takes a key obtained from list_court_hierarchy — provenance the schema does not state. It does not clarify the precedence between tier and sub_court when both are set, which is the main remaining ambiguity.

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 opens with a specific verb+resource ('Search court decisions') and pins the jurisdiction to Hungary (HU), then enumerates the three judicial tiers. It does not explicitly distinguish this tool from the sibling search_case_law, so an agent must infer which search surface handles Hungarian tiered decisions versus general 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 by the tier enumeration and by the pointer that sub_court keys come 'from list_court_hierarchy', which hints at a discovery workflow. However, there is no explicit when-to-use/when-not guidance and no statement of how this differs from search_case_law or search_legislation, leaving the agent to infer routing.

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 carries the full burden and does disclose meaningful behavior: verification hits live external registries, not just a local syntax check, which tells the agent to expect network dependency and possible lookup failure. It stops short of describing failure modes, latency, or rate limits, which keeps it from a 5.

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 states scope and purpose with no padding. The 'No-Hallucination Citation Verifier for Hungary (HU)' framing is slightly promotional and the citation examples are repeated verbatim from the schema, which is minor waste.

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 an output schema, the description supplies the essential missing context: jurisdiction (Hungary only) and the external sources checked. Only the behavior on an unresolvable or malformed citation is unspecified, and the output schema likely covers that result.

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, so the baseline is 3. The description's examples of acceptable input forms (ECLI vs. Hungarian statute style) are useful but duplicate the example already in 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 names a specific verb pair ('Validates format and live existence') and a specific resource ('legal citations'), scoped to Hungary and ECLI/ELI registries. This clearly distinguishes it from siblings such as search_case_law and search_legislation, which retrieve rather than verify.

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 goal, 'prevent AI-hallucinated citations,' implies the use case (check a citation before relying on it), but there is no explicit when-to-use rule, no exclusion, and no pointer to a sibling for the search side of the workflow. Usage is inferable rather than instructed.

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