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

With no annotations, the description carries the full behavioral burden, and it does disclose two non-obvious traits: results are paginated at 100 per page with page starting at 0, and the court filter is applied locally within the current page rather than globally. This local-filter caveat is genuinely important for correct use. It does not discuss auth, rate limits, or read-only status, so it is not fully complete.

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 one-line purpose followed by a tight bullet ladder that front-loads the no-argument behavior and escalates by specificity. Every line carries information; there is 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?

An output schema exists, so return shapes need not be described, and the description does explain the hierarchical responses conceptually. Combined with the pagination and local-filter disclosures, an agent has enough to call it correctly, though permission/read-only context is absent for a no-annotation 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 0%, so the description must compensate, and it does: year, month, and day are explained as the drill-down controls, page as the 0-based pagination index, and court as an optional court code/name filter. The main gap is format detail for court (accepted code vs name form) and any valid ranges for month/day.

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 action (browsing) plus the exact resource and axis (official opendata API by publication date), and then decomposes the tool into an explicit drill-down hierarchy. An agent can immediately tell this is a date-hierarchical browser rather than a free-text search like search_decisions or a single-record get_decision.

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 maps every argument combination to the resulting view (no args -> years/counts, year -> months, year+month -> days, full date -> decision list), which tells the agent precisely how to walk the hierarchy. It stops short of naming when to prefer a sibling such as search_decisions or find_by_case_number, so no explicit exclusions 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 to lean on, the description carries the full behavioral burden and does so: it discloses the local-cache write side effect, the hard cap (max_decisions default 50, max 500), the per-item network cost (1 HTTP request per decision), and a politeness constraint on the public server. This is exactly the operational context an agent needs before triggering a bulk fetch.

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?

Three dense sentences: capability, follow-up workflow, and cost warning. Nothing is wasted and the cap and warning are front-loaded enough to be seen before invocation. Slightly dense packing of the parameters-as-search_decisions note costs it a point.

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. The description instead covers what an agent uniquely needs: that full texts are stored locally, the volume ceiling, the per-request cost, and how to retrieve results offline. Complete for a bulk-caching 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 coverage is 0% across 11 parameters, so the description must compensate. It only fully specifies max_decisions (default 50, max 500) and delegates the remaining ten filter parameters to search_decisions by reference. That delegation is a workable shortcut but forces the agent to cross-read another tool's docs, leaving semantics partially covered.

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: it downloads full texts of decisions into a local cache, and names the sibling it mirrors (search_decisions) and the one that consumes the result (cache_search). An agent can distinguish it from cache_fill_day, cache_search, and search_decisions without opening any schema.

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 clearly frames a workflow: fill the cache with search_decisions-equivalent filters, then search offline with cache_search. It stops short of stating when NOT to use it (e.g. single-decision fetch via get_decision, or cache_fill_day for day-scoped fills), so the routing is implied rather than explicit.

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 only that this writes into a cache from the opendata API and that max_decisions caps results, but says nothing about permissions, rate limits, overwrite/idempotency behavior, or what happens on partial failures.

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 tightly packed into one sentence with the core action front-loaded, followed by the optional court filter and the max_decisions constraint. Every clause earns its place with no filler.

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. However, for a cache-writing tool with no annotations and zero schema descriptions on five parameters, the description is only minimally complete: it covers the basic action and two parameter constraints but omits safety, idempotency, and error 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 description coverage is 0%, so the description must compensate. It usefully clarifies that court accepts a code or name and that max_decisions is a cap with default 100 and max 500, but year, month, and day receive no semantic detail beyond their names, leaving three required parameters under-specified.

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 ('Stáhne do cache všechna rozhodnutí') and scopes it to decisions published on a given day via the official opendata API. It does not explicitly differentiate itself from the sibling cache_fill, which likely has broader or different scope, so it falls short of a 5.

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: populate the cache for one day, optionally filtered by court. There is no explicit when-to-use guidance, no when-not-to-use conditions, and no alternatives named (e.g., cache_fill or browse_published), leaving the agent to infer context.

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 does well: it discloses the query grammar (AND/OR/phrase/prefix/NOT), diacritic-insensitive matching, and the snippet-with-»highlight« return shape. It omits any note on latency, limits, or behavior when the cache is empty, which is a modest gap rather than a serious one.

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?

Three compact sentences, front-loaded with what the tool is before moving to syntax and scope. The syntax sentence is dense but every clause is actionable; nothing is padding.

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 exposition, and the description still adds the highlight-marker format. Query syntax and the cache-scope precondition are covered; the missing pieces are `court`/`limit` semantics and an explicit pointer to the uncached-search alternative.

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 0% across three parameters, so the description must compensate, and it does so only for `query` (rich syntax guidance). The `court` filter and `limit` (default 20) are left entirely to the schema with no added meaning, so compensation is partial.

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 and resource (fulltext search over locally cached decisions) plus the underlying engine and diacritic handling. It implicitly separates itself from the remote-search siblings by stating it only searches already-downloaded content, but it never names search_decisions as the counterpart, so differentiation is inferential rather than explicit.

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 closing line scopes usage clearly: only content fetched via get_decision / cache_fill is searched, which tells the agent when this tool is applicable (cache must be populated first). It stops short of stating an explicit exclusion or naming the alternative tool to use for uncached material.

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 provided, the description carries the full burden. 'Stav' and the enumerated read-only metrics imply a safe inspection operation, but the description never states that it is non-destructive, requires no special auth, or whether it triggers any cache work. It does add concrete value by naming the four categories of information returned.

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 core purpose ('Stav lokální cache') leads and the returned metrics follow as a compact list. Slightly list-heavy but every element earns its place.

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 inspection tool with an output schema already present, the description need not explain return formatting. It is complete enough for correct invocation, with the only gap being the absence of any usage or safety context.

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 per the rubric the baseline is 4. The description correctly implies no inputs are needed, and there is no parameter ambiguity to resolve.

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 resource and scope: 'Stav lokální cache' (state of the local cache) followed by the concrete contents it reports (decision count, publication date range, most frequent courts, database location). This clearly distinguishes it from sibling cache tools like cache_fill or cache_search, though it never names them 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?

There is no explicit when-to-use or when-not-to-use guidance. The diagnostic/inspection intent is only implied by the word 'stats'; an agent must infer that this is for checking cache health rather than for retrieving decisions, and no alternative tool is referenced.

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 provided, the description carries the full disclosure burden. It usefully reveals the default output directory, the JUDIKATURA_MCP_EXPORT_DIR override, and the default filename scheme, but omits overwrite behavior, permission requirements, and error conditions for what is a filesystem write.

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 purpose sentence is front-loaded, and the remaining text is compact per-parameter explanation with no filler. Structure is efficient, though the inline 'param: meaning' style is dense.

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 the non-obvious parameters well. The main gap is the undocumented required uuid_or_ecli input and any failure/overwrite 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 description coverage is 0%, so the description must compensate, and it largely does: it enumerates format values ('docx' | 'txt'), explains out_dir's default and env-var fallback, and defines filename as extensionless with a default of court code + case number. Only the required uuid_or_ecli parameter is left undocumented.

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+resource ('Uloží plný text rozhodnutí jako soubor' – saves the full text of a decision as a file), which clearly distinguishes it from read-oriented siblings like get_decision or search_decisions. It does not explicitly name which sibling to use instead or when this differs from plain retrieval, so it's clear but not fully sibling-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?

The description provides no when-to-use or when-not-to-use guidance and does not reference alternatives such as get_decision. It functions almost entirely as parameter documentation rather than usage 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, the description carries the full behavioral burden. It does disclose one non-obvious domain trait — that case numbers are not globally unique and collide across courts — but says nothing about result limits, behavior on zero matches, or whether multiple decisions can be returned. An output schema exists, so return-shape explanation is not required.

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 tightly written sentences: the core operation and format come first, followed by the one caveat that matters. Nothing is redundant and no filler is present.

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 3-parameter lookup with an output schema, the description covers the key input (case number format) and the court caveat, but omits the semantics of limit and the outcome when multiple courts or multiple decisions match. Adequate but with clear gaps.

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 0%, so the description must compensate. It documents the required case_number format and the meaning/recommendation of court, which is genuine added value, but the third parameter (limit, default 10) is left completely unexplained in both schema and description.

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 (find a decision by case number) and pins down the exact expected format with two concrete examples ('20 C 98/2026', '8 Co 85/2026'). It is clear what the tool does, though it never explicitly contrasts itself with siblings like search_decisions or get_decision.

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 gives a useful conditional hint ('the same case number exists at multiple courts', so supply court), which is implied guidance for parameter choice, but it never says when to prefer this tool over search_decisions or get_decision, nor what happens if court is omitted or no match is found.

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 add real behavioral context: decisions are persisted to a local cache and refresh=True forces a fresh download. However, it does not say whether an uncached decision is fetched remotely (and how slow that is), what happens when the uuid/ECLI is not found, or how large the returned text can be.

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?

Three short, front-loaded lines with no filler; the purpose and identifier formats come first and the section/refresh details follow. The inline 'section: a | b | c' enumeration is compact and scannable, though the mixed Czech/English phrasing is slightly choppier than a single flowing sentence would be.

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 documentation is not needed, and the description covers all three parameters plus cache behavior. What is left thin is the failure path (invalid or unknown identifier) and the remote-fetch implications of completely uncached decisions.

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 0%, yet the description fully compensates: it explains the uuid/ECLI identifier with a concrete ECLI example, enumerates every legal value of section with Czech glosses for verdict/justification, and explains refresh's force-redownload semantics. All three parameters gain meaning beyond the bare 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 gives a concrete verb and resource ('Vrátí plný text rozhodnutí') plus the two accepted identifier forms (uuid or ECLI, with a worked ECLI example), which is highly specific. It never names or contrasts with siblings like search_decisions, find_by_case_number or export_decision, so the agent must infer the fetch-by-id vs. search/export split on its own.

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: an agent can infer this is the retrieval step that follows a search which produced a uuid or ECLI. There is no explicit when-to-use, no when-not-to-use, and no routing to alternatives such as export_decision or cache_search.

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 present, so the description carries the full burden. It implicitly conveys a read-only dictionary lookup and discloses a non-obvious trait — the filter is diacritic-insensitive — but says nothing about result size, ordering, 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?

Three short sentences with no filler; the resource identity, the filter semantics, and the cross-tool code usage are each front-loaded and earn their place.

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, return values need no explanation; for a one-parameter read-only lookup the description covers purpose, parameter behavior, example inputs, and how the output is reused elsewhere. Nothing an agent needs to call 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 description coverage is 0% (the single 'filter' param is bare), so the description must compensate, and it does: it defines the filter as a match on part of the name, notes diacritics are ignored, and supplies three concrete example values ('Ostrav', 'krajský', 'Praha'). This fully specifies the only parameter.

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 concrete resource and what it returns (a code -> name lookup table of courts, 'Číselník soudů (kód -> název)'), plus an optional partial-name filter. It is clearly distinguishable from siblings like list_keywords or search_decisions by domain, though it never explicitly names an alternative.

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?

Gives clear context for why the tool exists: the returned 'kódy' are consumed by the 'court' parameter of the other tools, which tells the agent when to reach for it. It stops short of explicit when-not-to-use or naming a sibling alternative.

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 usefully discloses filter matching semantics (partial name, diacritic-insensitive, with examples) and the return shape (code -> Czech name), but says nothing about the limit/truncation behavior or any permission 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?

Three compact sentences, front-loaded with the resource definition and then the parameter and return notes. Every sentence adds information; no filler.

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 lookup with an output schema already describing the return values, the description covers purpose, filter semantics, and downstream usage adequately. The only real gap is the unexplained limit parameter.

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 0%, so the description must compensate. It explains 'filter' well (partial, diacritic-insensitive substring matching with examples), but the second parameter ('limit', default 50) is never mentioned, leaving a silent truncation behavior undocumented.

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 concrete resource ('číselník klíčových slov') and its role as a classifier applied to decisions, which lets an agent distinguish it from search tools. It lacks contrast against the other list_* sibling (list_courts), so differentiation is partial.

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 downstream purpose: names and codes returned here feed the 'keywords' parameter of search_decisions, which is a clear routing context. It does not state when-not to use it or name any alternative lookup tool.

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 present, so the description carries the full burden. It does disclose a genuinely useful trait — that it relies on the undocumented API of rozhodnuti.justice.cz — but says nothing about rate limits, failure modes, or pagination behavior beyond the page/limit params. The return-value sentence duplicates the existing output schema.

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?

Front-loaded one-line purpose followed by a compact bullet-per-parameter list that is easy to scan, and the length is justified by 17 parameters. Minor waste in the trailing sentence describing the return payload, which the output schema already covers.

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 17-parameter, annotation-free search tool with an output schema, the description supplies the parameter semantics, input formats, and a hand-off to get_decision, which is nearly everything an agent needs. It stops short of covering error/rate-limit behaviour on the undocumented upstream API.

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 0% across 17 params, and the description compensates fully: it explains every parameter's meaning, gives the mode semantics (ALL/ANY/EXACT), enum-like values for types and affected, comma-separated multi-value syntax for court/keywords/types, date formats (YYYY-MM-DD), and concrete examples such as '§ 2991 z. č. 89/2012 Sb.' and '89/2012'.

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+resource ('Vyhledávání soudních rozhodnutí') plus scope (fulltext + filtry), and points to get_decision(uuid) as the follow-up for full text. It does not differentiate from siblings like find_by_case_number or browse_published, which also retrieve decisions, so the routing is only partially resolved.

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 through the parameter catalogue rather than stated: no explicit 'use this when…' or exclusion against find_by_case_number/browse_published, and it never tells the agent to resolve courts/keywords via list_courts or list_keywords even though it accepts codes. Adequate for a search tool but leaves alternative selection to inference.

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