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

With no annotations supplied, the description carries the full behavioral burden; 'Retrieve' usefully signals a non-mutating read, which is the main safety fact an agent needs. However, it does not mention that results are paginated in 5,000-character chunks (only visible in the schema), nor what happens for an invalid or unresolvable identifier.

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 with no filler, front-loading the action and the return format before the jurisdiction and input qualifiers. Nothing in it is redundant with the title and nothing 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?

This is a simple two-parameter read tool with a declared output schema and full parameter documentation, so the description need not explain return values. The only meaningful omission is any hint that paged retrieval may require repeated calls to assemble a long document.

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, establishing a baseline of 3. The description adds a little by clarifying that the identifier may be a URL or official identifier, reinforcing the accepted formats, but contributes no syntax or format 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 and resource: 'Retrieve full Markdown text of a legislation document or court judgment', scoped to Montenegro (ME), and names the input form (URL or official identifier). An agent can tell this is a fetch-by-reference tool rather than a search, though it never names the sibling search tools it complements.

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 'by its URL or official identifier' plus the schema note that IDs are 'returned by search tools' implies a search-then-fetch workflow, but the description itself gives no explicit when-to-use, no when-not, and no reference to alternatives like verify_citation. Usage is inferable rather than 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. "Return" and "List" imply a read-only, side-effect-free retrieval, and the content scope (tiers plus sub-portals) is disclosed, but there is no statement about permissions, static vs. live data, or completeness guarantees.

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, though the parenthetical slash-lists of court-type synonyms make it denser than necessary for routing purposes. Slightly overstuffed but every clause conveys scope.

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 already documenting return values, the description covers region, tier structure, and sub-portals adequately. Only the relationship to the sibling search tools remains unstated.

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 there is nothing for the description to clarify beyond the schema. The baseline for a parameterless tool applies, with no deductions warranted.

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?

Uses a specific verb ("Return") with a concrete resource ("complete step-by-step multi-tier judicial hierarchy for Montenegro (ME)") and enumerates the tiers returned. An agent can immediately distinguish this reference-listing tool from the search_* and get_* siblings.

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 tier enumeration suggests this is a lookup tool to consult before searching tiered decisions, but the description never states when to use it versus search_tiered_court_decisions or any other sibling. No exclusions, prerequisites, or ordering guidance are given.

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 corpus sources and supported courts, but it does not describe search behavior such as full-text versus metadata matching, ranking, date coverage, or read-only safety beyond what 'Search' implies.

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, but it is dense with parenthetical source names and repeats the supported-court list already present in the schema. It remains understandable, but the redundancy reduces efficiency.

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?

Because an output schema exists and schema coverage is complete, the description need not explain return values or parameters. It adequately identifies the legal corpus and courts, but it omits usage guidance and sibling-tool differentiation, leaving it only minimally complete for agent 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 description coverage is 100%, so the input schema already documents query, court, and limit semantics. The description largely duplicates the court list from the schema and adds no additional meaning about query syntax or filtering 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?

The description clearly states a specific verb and resource: searching Montenegro court decisions and binding precedents, with named sources and supported courts. It distinguishes case law from legislation, but does not distinguish it from the sibling search_tiered_court_decisions tool.

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 gives no explicit when-to-use guidance, no exclusions, and no comparison with alternatives such as search_tiered_court_decisions or search_legislation. Usage is only implied by the tool name and corpus 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 usefully discloses the underlying corpora (službeni list / Službeni list Crne Gore, Gov.me, European/International registries), which is real context an agent could not get from the schema, but it says nothing about result language, ranking, cost, or coverage gaps between sources.

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 verb and geography come first and the source list follows. It is dense but every clause is informative, so nothing 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?

With only three fully documented parameters and an output schema present, return values need not be described. The description supplies the jurisdictional and source scope, leaving only minor gaps such as result language and cross-source coverage behavior.

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 already carry their own descriptions (query, year, limit with bounds), so the schema does the heavy lifting. The description adds corpus scope but no additional meaning about how query keywords interact with year filtering or what statute-number formats are accepted.

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 (Montenegro national legislation), enumerating the covered document types (statutes, acts, codes, regulations) and the source registries. The resource itself distinguishes it from siblings like search_case_law, but no sibling is named explicitly.

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 scope 'Montenegro national legislation' implies when to use it, and by implication it is not for case law or court decisions. However, there is no explicit when-to-use/when-not statement and no routing to the sibling tools search_case_law or verify_citation, so selection is left to inference.

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 omits a meaningful default: tier defaults to 'appellate_regional', meaning an agent that omits tier silently searches only the appellate layer rather than all tiers. It also says nothing about the 50-result cap behavior or whether 'all' changes cost/latency; only the read-only nature is implicit in '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?

Two sentences, no filler, with the geographic scope and the filtering axis front-loaded. The tier enumeration is verbose but each item maps to a real parameter value, so it earns most of its space.

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 tool's surface is simple (four flat parameters). However, with no annotations and an undisclosed default tier, the definition leaves the agent without enough behavioral context to predict what a query will actually cover.

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 schema already documents tier, limit, query, and sub_court, and the description largely restates the tier vocabulary the schema defines. Its one genuine addition is telling the agent that sub_court keys come from list_court_hierarchy, which is real meaning beyond the schema's example values, but not enough to lift it above baseline.

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 Montenegro') plus the filtering axis (judicial tier or regional/appellate court). It clearly scopes itself geographically and structurally, but never contrasts itself with the closest sibling, search_case_law, so an agent must infer which one to reach for.

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?

Provides implied guidance by pointing at list_court_hierarchy as the source of valid sub-portal keys, which hints at a two-step workflow. It gives no explicit when-to-use versus search_case_law or search_legislation, and no when-not-to-use conditions.

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 that this is a live external lookup against official Montenegro and ECLI/ELI registries plus a format check. It does not state what happens when a registry is unreachable, whether a failed verification is distinguished from an unknown registry, or any latency/rate considerations. An output schema exists, so return values needn't be explained here.

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 verifier role and jurisdiction before the mechanism. Slightly dense with stacked qualifiers ('official Montenegro and ECLI/ELI registries'), 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?

For a one-parameter verification tool with an output schema, the description covers purpose, jurisdiction, and verification sources adequately. The remaining gaps (failure modes, registry availability, whether non-Montenegro citations are rejected) are real but minor at this complexity level.

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?

There is a single required parameter with 100% schema description coverage, and the schema already supplies the same example citation formats. The description reinforces the accepted citation types ('Rev.br. 123/24 or Službeni list CG br. 15/2024') but adds no constraints beyond the schema, 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') against a specific resource (legal citations) with an explicit jurisdiction scope (Montenegro/ME) and named registries. It is clearly distinguishable from the sibling search_* tools by being a verifier rather than a retriever, though it never names those siblings 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?

The stated goal ('prevent AI-hallucinated citations') implies the situation in which to use it, and the contrast with search tools is inferable from the word 'validates'. However, there is no explicit when-to-use/when-not-to-use statement, no mention of what to do if verification fails, and no named alternative such as search_case_law for finding a citation you don't yet have.

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