isir

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

No annotations are provided, so the description must fully disclose behavior. It states the tool checks active proceedings and returns specific data, but it does not explicitly confirm it's read-only, mention rate limits, or explain any side effects.

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, efficiently front-loaded with action and return. Every sentence contributes essential 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?

For a simple lookup tool with one parameter and no output schema, the description fully covers purpose, input, and output format, including the 'no record' case.

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 input schema has 100% description coverage for the single parameter 'ico' ('Czech IČO — 7 or 8 digits'). The tool description adds no additional semantic value beyond what the schema already 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 clearly states the action (check insolvency), the input (IČO), the source (ISIR), and the output (spisová značka, date, phase, or 'no record'). It distinguishes from siblings by specifying it's for companies by IČO, not events or person 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?

The description implicitly tells when to use it (checking Czech company insolvency) and notes that 'no record' is informative. However, it does not explicitly state when not to use it or provide direct alternatives, though siblings are distinct.

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 full burden. It discloses that ISIR is an append-only feed, each call returns up to ~1000 events, uses pagination with since_id and last_id, and starting from 0 gives history back to ~2008. This fully describes the behavior.

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 concise at three sentences, each adding essential information: action, feed behavior, pagination hint, and use cases. No redundant or unnecessary words.

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 simple tool with one parameter and no output schema, the description covers purpose, usage, pagination, and feed nature. It is sufficiently complete for an agent to use correctly.

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 single parameter 'since_id' is well-explained in the description: it's the last seen event id, use 0 to start from beginning (~2008), and use last_id from response as next since_id. This adds significant value beyond the schema's 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 clearly states the tool pulls a batch of recent ISIR events, specifying the resource (insolvency register publications) and the mechanism (since an event id). It differentiates from siblings by focusing on polling events rather than checking specific records or searching.

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 explicitly states use cases: 'compliance monitoring or to back-fill an index.' While it doesn't say when not to use it, the context of siblings and the feed nature imply it's not for individual lookups, which provides adequate 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 burden. It discloses that the tool returns active insolvency proceedings and that DOB reduces false positives, but it does not mention read-only behavior, pagination, error handling, or authentication requirements.

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 three sentences long, front-loaded with purpose, and contains no redundant or unnecessary information. Every sentence adds value.

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?

While the description and schema cover parameters well, without an output schema, the tool lacks details on what fields are returned in proceeding objects. Authentication, error cases, and rate limits are not mentioned. For a KYC/DD screening tool, some more detail on output structure would be beneficial.

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?

All three parameters are described in the schema, and the description adds practical context: DOB is 'strongly recommended' with explanation of false positives, name accepts any case and Czech diacritics, and only_active has its default behavior clarified. This enriches beyond the schema's own descriptions.

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 the tool searches the ISIR for an individual person's insolvency proceedings, specifying the purpose in KYC/DD workflows. It differentiates from siblings by focusing on people (FO) vs companies (check_ico_insolvency) and event polling (poll_isir_events).

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 explicitly mentions screening statutory persons in KYC and DD workflows, giving clear context for use. It does not explicitly state when not to use or mention alternatives, but the sibling names provide implicit differentiation.

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