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 real behavior beyond the schema: the 1-hour cache and how `obnovit=True` bypasses it. It remains silent on error/not-found behavior and does not explicitly state the operation is read-only, so it falls short of full transparency.

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 with the returned fields, then the parameter notes in a compact second line. The field enumeration is long but each item is informative; 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 not be described, yet the description usefully summarizes the payload shape anyway. Identifier formats and caching are covered; only usage routing and failure behavior are absent.

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: `rizeni` accepts a case number (spisová značka), a 32-hex detailId, or a detail URL, and `obnovit=True` bypasses the 1-hour cache. Both parameters gain meaning not present in 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 first line names the specific resource (header of an insolvency proceeding) and enumerates exactly which fields come back (debtor, status, case number, court, administrator, deadlines, last event date, event counts per section A–P). That is enough to distinguish it from siblings like isir_udalosti or isir_dokumenty, though 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?

There is no statement of when to call this versus isir_lustrace, isir_udalosti, or isir_tok_udalosti. The only conditional guidance is for the `obnovit` flag (bypass cache), which is parameter-level, not tool-selection 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 that the result is a flat list and that output is suited to bulk download/OCR, but says nothing about permissions, pagination, rate limits, or the caching/refresh semantics implied by the 'obnovit' parameter. Return-field enumeration does not count since an output schema exists.

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 that state the resource and its fields first, then the usage context and the one parameter format note. No filler; slightly compressed to the point where important details were dropped rather than 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?

The output schema present means return values need not be explained, but two of three parameters and all behavioral traits remain undocumented with no annotations as backstop. An agent cannot determine the expected format of the required 'rizeni' identifier or what 'obnovit' actually refreshes.

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 for all three parameters. It only clarifies one — "oddily: čárkou oddělené" (comma-separated sections) — and leaves the required 'rizeni' and the 'obnovit' flag (presumably a cache refresh) undocumented 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?

States a specific verb+resource combination: a flat list of all documents for a proceeding, and even enumerates the returned fields (ID, role, size, event, section, date, description). However it never names or contrasts itself with the sibling isir_hledat_v_dokumentech, so an agent must infer whether it is a full listing vs. a filtered search.

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?

"Vhodné jako podklad pro hromadné stažení/OCR" implies the intended context (bulk download/OCR pipeline), which is useful routing signal toward isir_stahnout_dokument. But there is no explicit when-not guidance and no alternative tool is named, so the agent must guess whether to use this vs. isir_hledat_v_dokumentech.

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 that each uncached document costs one ISIR request plus possible OCR ('desítky sekund na dokument'), describes matching semantics (case- and diacritics-insensitive, regex disables folding), and warns about cost on large proceedings. It omits auth requirements and whether results are cached/persisted, keeping it below the top score.

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 sentences, front-loaded with the action, then matching semantics, then a capitalized cost warning. No filler; each sentence adds decision-relevant information.

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 detail is unnecessary, and the description still summarizes the shape ('nálezy s kontextem'). For a 7-parameter, high-latency operation it covers cost, scoping and matching behavior well; only the parameter formats (section codes, ocr values) remain under-specified.

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, and it gives conceptual meaning for nearly every parameter: dotaz (search), rizeni (proceeding), oddily (sections), max_dokumentu (count), regex (regular expression), ocr ('podle potřeby OCR'), and context around findings. It does not document the oddily section-code format or the accepted ocr values beyond 'auto', leaving some format 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?

States a specific verb and resource ('fulltextové hledání napříč dokumenty řízení') plus the concrete mechanism (downloads up to max_dokumentu documents from selected sections and returns findings with context). This distinguishes it cleanly from siblings like isir_dokumenty (listing), isir_stahnout_dokument (single download) and isir_text_dokumentu (text extraction).

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 operating context and a scoping rule of thumb ('pro velká řízení zužte oddíly nebo max_dokumentu'), which tells the agent when to constrain usage. It does not explicitly route to or exclude sibling tools (e.g. when to prefer isir_text_dokumentu for a single file), so it stops short of full when/when-not 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?

With no annotations, the description carries the full burden. It usefully discloses the mutual-exclusivity rule for input combos and the jen_aktualni filter semantics, but says nothing about result limits (max_vysledku), matching behavior (bez_diakritiky, presna_shoda_jmen), permissions, or error/empty-result handling for a search 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?

Front-loads purpose, then uses a compact bulleted list for the input combos followed by the return shape. Efficient and easy to scan; only minor redundancy in restating the web-service name alongside the purpose.

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 10-parameter tool this covers the primary lookup paths and the return content well, and an output schema exists so return detail is not strictly required. The gap is the three undocumented control flags (max_vysledku, bez_diakritiky, presna_shoda_jmen), which an agent cannot invoke confidently without guessing.

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 10 params, so the description must compensate. It handles ico (8 digits), rc (with/without slash), spisova_znacka (two format examples), nazev_osoby + jmeno + datum_narozeni (YYYY-MM-DD) and jen_aktualni, but leaves max_vysledku, bez_diakritiky and presna_shoda_jmen entirely unexplained.

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 ('Lustrace v ISIR' against ISIR_CUZK_WS2) and names the exact output entity (list of proceedings with spisová značka, soud, dlužník, stav, detailId). It also distinguishes itself from siblings by noting detailId is 'pro další nástroje', positioning this as the entry lookup versus e.g. isir_detail_rizeni.

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 concrete entry guidance by enumerating the accepted input combinations ('Zadejte JEDNU z kombinací') and implies this is the first call that feeds downstream tools. However it never states when NOT to use it or names a specific alternative sibling, so usage context is clear but without explicit exclusions.

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 disclosure burden. It does add a real behavioral trait beyond the schema: the PDF is written into a local cache and the tool returns only metadata (path, page count, text-layer flag), not content. It stops short of covering idempotency or whether a cached copy is reused on repeat calls, which matters for a caching 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 dense sentences with no filler: the first states the action, side effect and return values; the second handles the routing disambiguation. The most decision-relevant information (what you get and what you do not) is front-loaded.

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 the return values need not be re-explained, and the description correctly covers the core behavior. However, with zero annotation coverage and 0% schema description coverage, the unexplained `znovu` parameter leaves a genuine gap an agent cannot resolve from any structured field.

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% and the description explains neither parameter. `dokument_id` is inferable from context, but `znovu` (re-download / force refresh) is completely opaque — nothing in the description or schema tells the agent what it toggles or when to set it.

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 (downloads the PDF of a document from ISIR) and states the exact outcome (saved into local cache, returns file path, page count, text-layer flag). It also explicitly distinguishes itself from the sibling that returns text, so an agent can tell the two apart without opening either 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 names the concrete alternative for the common confusion case: 'Text nevrací – použijte isir_text_dokumentu' (it does not return text – use isir_text_dokumentu). That gives an explicit routing condition between this tool and the text-extraction sibling, rather than leaving the choice 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 provided, so the description carries the full burden. It usefully discloses what the call surfaces (today's request count, limits, cache location, OCR availability), which lets an agent reason about rate limiting and service health, but it says nothing about permissions, freshness, or whether any state is mutated.

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 compact sentence listing three clearly delimited items; every clause earns its place and nothing is padded. Information is front-loaded with the rate-limiter status, the most likely reason to call 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?

With an output schema present, the description need not detail return values, yet it still summarizes them well. The only shortfall is the absence of usage or auth guidance, which is minor for a zero-parameter read-only status endpoint.

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. There is nothing for the description to disambiguate, and it correctly spends no words on parameter semantics.

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 resource (server state) and enumerates the concrete facets it reports: request-rate-limiter counts/limits, cache directory, and OCR availability. It is unmistakably distinct from the sibling tools (document retrieval, proceedings, events), though it never explicitly contrasts itself with them.

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 statement and no named alternative. The listed contents (rate limiter usage, OCR availability) imply a diagnostic/health-check use case, but the agent must infer that this is the tool to call before hammering the server or when OCR fails.

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 mostly succeeds: it discloses the OCR engine (Tesseract, Czech), attachment unpacking for PDF portfolios, the page-marker output format, and the JSON return shape. It omits any note on permissions/rate limits or the cost of forced OCR on large documents.

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?

Purpose is front-loaded, followed by pipeline behavior, then parameter guidance and return shape. Information-dense with little filler, though the OCR-mode and pagination blocks could be slightly tighter.

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 7-parameter extraction tool with no annotations and an output schema present, the description covers the pipeline, the tricky parameter modes, pagination, and even summarizes the return payload. It is nearly complete, missing only guidance on 'znovu' and on when not to use OCR.

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 for the non-obvious parameters: it enumerates the three 'ocr' modes with when-to-use guidance and explains the pagination params (strana_od/strana_do, offset, max_znaku). It leaves 'znovu' (re-process flag) and the required 'dokument_id' unexplained.

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 ('Plný text dokumentu ISIR') and immediately details the extraction pipeline (PDF download, text layer, OCR). This clearly separates it from download-oriented siblings like isir_stahnout_dokument and search-oriented ones like isir_hledat_v_dokumentech.

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 concrete usage conditions: 'force' for bad text layers, and pagination via strana_od/strana_do or offset + max_znaku for long documents. It does not, however, explicitly state when to prefer this tool over isir_stahnout_dokument or isir_hledat_v_dokumentech.

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 delivers the key behavioral trait: omitting od_id starts at the last ID and returns only the newest events, plus an enumeration of returned event fields. It omits any mention of auth requirements, rate limits, or what davek controls, 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?

Front-loads purpose and scope, then layers in return fields and the filter. Dense but every sentence carries information; the return-field enumeration is slightly verbose given an output schema 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?

An output schema exists, so return structure need not be spelled out, yet the description does describe returned fields anyway. Together with the usage routing and od_id semantics, the agent has enough to call it correctly; only davek remains undocumented.

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% for 3 parameters, so the description must compensate. It clarifies od_id semantics (ID > od_id; no od_id = newest only) and the jen_spisova_znacka filter format ('INS 1000/2024'), but leaves davek entirely unexplained.

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+resource (event stream of the whole registry) and pins the underlying web service (ISIR_PUBLIC_WS, WS_1). It explicitly distinguishes itself from the sibling isir_udalosti by stating this is not for single-proceeding queries.

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?

Directly states the intended use (monitoring changes) versus the excluded use (targeted queries on one proceeding) and names the alternative tool isir_udalosti for the latter. Also explains the od_id default behavior and the filter's purpose.

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 must carry the behavioral burden. It mentions that 'hledat' is case-insensitive and diacritics-insensitive via normalization, and that 'poslednich=N' returns the latest N events. However, it omits other behavioral aspects like whether 'obnovit' forces a refresh, pagination, rate limits, or authentication requirements. Output schema exists but is not referenced.

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 compact and front-loaded with the tool's purpose and key parameter explanations. However, the inclusion of '(záznamů)' and long phrasing about document types could be tightened slightly.

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 has 5 parameters, no annotations, 0% schema description coverage, and an output schema, the description is minimally adequate. It explains some parameters but misses others (rizeni, obnovit) and does not leverage the output schema. More detail on parameter usage and behavioral traits is needed for full completeness.

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 explains 'oddil' values (A/B/C/D/P), 'poslednich' as returning latest N, and 'hledat' as text filtering with normalization. But it does not describe 'rizeni' (required) or 'obnovit' (boolean refresh?), leaving two parameters 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?

The description clearly states it returns a list of events (records) for one section of proceedings, including document IDs. It distinguishes from siblings like isir_tok_udalosti by specifying 'jednoho oddílu řízení' and from isir_dokumenty by focusing on events rather than documents.

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 explains the 'oddil', 'poslednich', and 'hledat' parameters, implying when to use them. However, it does not explicitly state when to use this tool versus alternatives like isir_tok_udalosti or isir_detail_rizeni, nor does it mention prerequisites or exclusions.

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