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

No annotations are provided, so the description must carry the behavioral load; it does disclose the return format (full Markdown text) and that access is by URL or official identifier. It says nothing about pagination limits beyond the schema's page parameter, error behavior for invalid IDs, jurisdiction coverage limits, or rate limits, leaving real gaps for a no-annotation tool.

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 action, resource, jurisdiction, and input form all present; no filler or redundancy.

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 an output schema present and full parameter documentation, the description covers the essential what and how. It could have added the sequencing context (call after a search tool to get the identifier) or pagination expectations, but nothing critical for correct invocation 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 description coverage is 100%, so both parameters are already documented, including the 5,000-character page sizing. The description only echoes the identifier formats (URL, ECLI/ELI-style official ID) already listed in the schema, adding no new meaning, 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 (retrieve) and a specific resource (full Markdown text of a legislation document or court judgment) plus the jurisdiction (Cyprus/CY), which clearly separates it from the search_* siblings and from verify_citation. It stops short of naming which sibling produces the identifier it consumes, 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?

Usage is only implied: because it takes an ID/URL 'returned by search tools,' the agent can infer it is the fetch step following search_legislation or search_case_law. There is no explicit when-to-use/when-not statement or mention of alternatives such as search_tiered_court_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?

With no annotations, the description carries the full burden. It does usefully declare completeness ('complete', 'all official court sub-portals'), which tells the agent to expect a full static reference rather than a partial result. However, it says nothing about whether the hierarchy is static or configurable, or about pagination or ordering beyond the tier numbering.

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 immediately names the resource and scope, followed by the tier enumeration. The enumeration is dense but each clause carries content the agent would otherwise have to open the output schema to learn.

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 covers what is returned and its jurisdiction. The only gap is any hint about how to use the result alongside the sibling search tools, which the description leaves implicit.

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; the description correctly signals a parameterless lookup. The enumerated tier labels also help the agent interpret the returned tier names, though no parameter meaning needs explaining.

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'), a specific resource ('multi-tier judicial hierarchy'), and a jurisdiction scope (Cyprus/CY), then enumerates the exact tiers returned. This clearly distinguishes it from search_tiered_court_decisions, which searches decisions rather than describing the tier structure.

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?

No explicit when-to-use or when-not-to-use guidance is given; the agent must infer that this is a reference lookup to run before tiered decision searches. The enumeration of tiers implies its role, but no alternative is named or ruled out.

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. It usefully discloses the data source and supported courts, but omits authentication needs, rate limits, ranking behavior, pagination, and other operational traits beyond the obvious read-only nature of search.

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 little waste. The court names are repeated in English and Greek, which is slightly redundant but still concise overall.

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 a fully described three-parameter schema and an output schema, the description supplies the jurisdiction, data source, and supported courts needed to understand the tool. It is slightly incomplete because it does not route the agent among sibling 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 description coverage is 100%, so the schema already documents query, court, and limit. The description adds jurisdiction and court coverage context but does not deepen parameter semantics 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 and resource: search Cyprus court decisions and binding precedents via the CyLaw Judgments Database. It identifies the jurisdiction and supported courts, but does not explicitly distinguish this tool from sibling search_tiered_court_decisions.

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 for finding Cyprus case law, but the description provides no explicit when-to-use guidance, exclusions, or comparison to alternatives such as search_tiered_court_decisions or search_legislation.

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 disclosure burden. It usefully notes the underlying external sources (cylaw.org and European/International registries), hinting at remote retrieval, but it does not state that the operation is read-only, describe latency/rate-limit behavior, or note coverage limitations or result ordering beyond what the output schema covers.

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 naming the action, jurisdiction, document types, and data sources with no filler. It is efficient, though the parenthetical source enumeration borders on verbose relative to the information content.

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-value structure needn't be explained, and the parameter set is small and well-documented. However, for a search tool with no annotations, the description omits matching behavior, language/coverage caveats, and result volume expectations that an agent would want before calling it.

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 each of the three parameters is already documented in the schema, and the description adds no syntax, format, or matching-behavior detail for query or year. Baseline 3 applies because the schema does the semantic work.

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+resource (search Cyprus national legislation) and enumerates the covered document types (statutes, acts, codes, regulations) plus the source portals. It does not explicitly name the sibling search_case_law or explain the boundary, but the 'legislation' framing makes the resource distinction inferable.

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 resource scoping to legislation, so an agent can infer this is the right tool for statutes rather than case law. There is no explicit when-to-use/when-not guidance, no mention of alternatives such as search_case_law, and no prerequisites noted.

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 behavioral load; it does establish that this is a scoped search across defined tier values and that sub_court keys must come from list_court_hierarchy. It says nothing about result caps beyond the schema, ranking, pagination, or that it is a non-mutating lookup, which are exactly the traits an agent needs from an unannotated tool.

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 scope, with no filler. There is mild duplication of the tier semantics that the schema's own tier description already states, but it is dense rather than padded.

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 does enough to make a correct call on tier and sub_court. It remains incomplete on sibling disambiguation against search_case_law and on the supported 'all' tier, both of which an agent would need for confident selection.

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 real meaning by mapping Tier 1/2/3 labels onto the actual parameter values (first_instance, appellate_regional, supreme_constitutional) and by clarifying how sub_court relates to list_court_hierarchy. It omits the 'all' value that the schema accepts, leaving a small gap.

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), resource (court decisions), jurisdiction (Cyprus/CY), and the distinguishing filter (judicial tier or specific regional/appellate court), and it enumerates the tier values. It stops short of differentiating itself from the sibling search_case_law, so an agent cannot fully resolve 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?

It provides implied usage context by describing what tiers exist and by routing to list_court_hierarchy when a sub-portal key is needed, which is genuinely useful. However, there is no explicit when-to-use guidance versus search_case_law, which is the most likely ambiguity for an agent choosing among search tools.

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, and it does disclose meaningful behavior: two distinct checks (format validation and 'live existence') against external official Cyprus and ECLI/ELI registries, which signals network dependency and possible latency. It does not mention failure modes, rate limits, or what an unresolvable citation yields, but the presence of an output schema covers the response shape.

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 tight sentence with the jurisdiction and examples front-loaded; nothing is redundant. The leading label 'No-Hallucination Citation Verifier for Cyprus (CY)' is slightly promotional but also serves as a scannable scope marker.

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 essentials: jurisdiction, accepted citation types, and that verification goes to live registries. The only material gap is what a failed or inconclusive verification looks like procedurally (e.g., registry unavailability).

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 schema already does the work. The description repeats the same example strings without adding format rules, accepted prefixes, or normalization guidance 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 uses a specific verb+resource ('Validates ... legal citations') and names the exact scope: Cyprus (CY), with concrete example formats ('ECLI:CY:AD:2024:10 or Cap. 149'). It is clearly distinguishable from siblings like search_case_law and search_legislation, which retrieve documents rather than validate an already-known 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 goal ('to prevent AI-hallucinated citations') implies the use case of checking a citation before relying on it, but there is no explicit when-to-use/when-not or routing to alternatives. An agent is left to infer that search_case_law is for discovery and verify_citation for validation.

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