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

No annotations are supplied, so the description must carry behavioral disclosure. It clearly identifies a read-only retrieval and the Markdown output format, but does not mention authentication, rate limits, error behavior, or pagination beyond what the schema states.

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?

Single sentence, front-loaded with the action and resource, with no redundant 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 an output schema and full parameter descriptions, the definition is nearly complete for a simple retrieval tool. It could be stronger by explicitly routing agents from search results to this fetch operation, but no critical calling information 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%, so both parameters are already documented. The description reinforces that document_id_or_url accepts a URL or official identifier, but adds no syntax, format, or pagination detail 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?

States a specific verb ('Retrieve'), resource ('full Markdown text of a legislation document or court judgment'), jurisdiction (North Macedonia/MK), and lookup key (URL or official identifier). This clearly separates it from sibling search tools that locate documents rather than fetch 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?

Implies use when you already have a document URL or official identifier, but does not explicitly state when to use this versus search_legislation or search_case_law, nor what to do if only a citation is available. The schema parameter note mentions IDs returned by search tools, but the description itself leaves routing 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; it discloses the jurisdictional scope (MK only) and the tier contents, which is real behavioral context. However, it says nothing about whether the hierarchy is static or reflects per-jurisdiction variation, nor about caching or freshness, which matters for a reference-data 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 no preamble or filler; the tier enumeration and synonym list earn their place by making the return contents predictable. It is long but dense, with only mild redundancy from stacking alternative court-name synonyms.

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 format needn't be explained, and with no parameters the surface area to document is small. The one residual gap is that MK-only scope is asserted without guidance on behavior for other jurisdictions, but otherwise the definition covers what an agent needs to call 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?

The tool takes zero parameters and the schema is fully specified (additionalProperties: false), so there is no parameter meaning for the description to add. Baseline 4 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 states a specific verb ('Return') and a concrete resource ('complete step-by-step multi-tier judicial hierarchy for North Macedonia (MK)'), then enumerates exactly what is inside each tier. An agent can distinguish it from search_tiered_court_decisions because this returns the taxonomy itself rather than 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 only implied: the read-only, zero-parameter nature makes it obviously a reference/lookup call, but the description never says when to reach for this versus search_tiered_court_decisions or search_case_law. No exclusions or prerequisites are stated, so the agent must infer that this is the setup step before tiered searching.

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 the data sources, that results include binding precedents, and which courts are covered, which is genuine behavioral context. It says nothing about ranking, full-text versus snippet results, coverage gaps, or rate limits that would help an agent predict output quality.

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, but the court list is repeated verbatim from the schema and the nested parentheses make the sentence dense and hard to parse. The redundant court enumeration does not earn its place twice.

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 the source/court scope is adequately covered. What is missing is disambiguation from the near-identical sibling search_tiered_court_decisions, which is the main thing an agent needs to route correctly among five legal sibling 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%, so all three parameters are documented in the schema, setting the baseline at 3. The description restates the supported court values already present in the court parameter description and adds no query syntax or matching behavior beyond what the schema provides.

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 ('Search ... court decisions and binding precedents') and names the concrete portals (sud.mk, vsrm.mk, ustavensud.mk) plus the courts covered. It does not, however, distinguish this tool from the close sibling search_tiered_court_decisions, so an agent cannot resolve the overlap from the description alone.

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 guidance about when to use this search versus search_tiered_court_decisions, get_legal_document_markdown, or verify_citation. The list of supported courts is scope information, not usage guidance, and no exclusions or prerequisites are stated.

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 no operational traits beyond naming the sources. It is unclear whether results are aggregated across the three named registries, how results are ranked or deduplicated, how the year filter interacts with search terms, or whether there are 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 the verb and jurisdiction first, which is efficient. The trailing list of domain names and registries is somewhat dense and adds breadth at the cost of readability, but no sentence 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?

An output schema exists, so return values need not be described, and the three simple parameters are fully documented in the schema. However, for a search tool spanning multiple distinct registries, the missing explanation of how sources are combined and what coverage to expect leaves a meaningful gap.

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 baseline is 3; the description adds no extra meaning about the query, year, or limit parameters. It does not explain, for example, whether 'year' matches enactment date strictly or whether query accepts statute numbers as the schema hints.

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 ... national legislation') and enumerates the document types covered (statutes, acts, codes, regulations), which makes the scope concrete. It does not explicitly contrast itself with sibling tools such as search_case_law, so an agent must infer that this tool covers statutes rather than 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 only implied by the resource type: an agent can infer it should call this when looking for statutes instead of case law. There is no explicit when-to-use, when-not-to-use, or statement about how it relates to search_case_law or verify_citation, and no prerequisites are mentioned.

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. It discloses the jurisdiction and the tier vocabulary but says nothing about result ordering/ranking, whether tier and sub_court interact or one overrides the other, or what happens when a tier yields no matches; the presence of an output schema offsets the omission of return format.

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 dense, front-loaded sentences; scope and jurisdiction come first, then the tier vocabulary. No filler, though the parenthetical court-name list is slightly verbose where a pointer to the tier documentation would suffice.

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 only four parameters, full schema coverage, and an output schema in place, the description covers what an agent needs to construct a call correctly, including where sub_court values come from. The remaining gap is competitive positioning against the near-identical 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 baseline is 3, and the description earns above that by mapping domain vocabulary to raw enum values (Tier 1 = first_instance, Tier 2 = appellate_regional covering Cantonal/Regional/County/Circuit, Tier 3 = supreme_constitutional) and by directing the agent to list_court_hierarchy for valid sub_court keys. It does not explain the precedence between tier and sub_court.

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?

Names a specific verb (search) plus resource (court decisions), jurisdiction (North Macedonia/MK), and the distinguishing axis (judicial tier / sub-portal court). However, the sibling set contains search_case_law, and the description never explains how this tool differs from it, so an agent cannot fully disambiguate from names alone.

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?

Implies usage via the tier enumeration and points the agent to list_court_hierarchy as the source of sub_court keys, which is genuinely actionable. It stops short of explicit when-to-use/when-not guidance, particularly against search_case_law and search_legislation, and gives no guidance on choosing between tier and sub_court.

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 does disclose that checks are against live external registries ('live existence'), hinting at remote lookups, but says nothing about failure semantics (does an unverifiable citation return a flag or an error?), latency, or rate limits — meaningful gaps for a network-dependent 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 delivers the core claim and scope immediately with no filler. The marketing-style label ('No-Hallucination Citation Verifier') and the closing 'prevent AI-hallucinated citations' clause are mildly redundant with the preceding text.

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 there is only one simple parameter. The description covers scope, targets, and example formats; the remaining gap is what a negative verification result looks like at the tool level, which the output schema likely covers.

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?

With a single required parameter and 100% schema description coverage, the schema already defines the argument; the description's added value is confirming that ECLI/ELI identifiers and statute gazette references are in scope, aligning with the schema examples. It does not add format tolerance rules (whitespace, transliteration, abbreviations) beyond what the schema shows.

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) and resource (legal citations), names the exact registry targets (North Macedonia official registries and ECLI/ELI), and gives concrete citation format 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 intent ('prevent AI-hallucinated citations') implies the use case — verifying a citation you already hold — but the description never states when to prefer it over search_legislation or search_case_law, nor any exclusions or prerequisites. Usage is inferred rather than stated.

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