Insolvenzmonitor

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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds the result contract instead: proceeding stage with date, case number, court, match quality, and the `ambiguous` flag. That is real context an agent cannot get from annotations or schema. It doesn't state behavior on zero hits or how limit interacts with multiple matches.

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 core question, then structured result and stage semantics. The stage enumeration is long but earns its place because there is no output schema. Minor redundancy between the register-number format in the description and in the schema.

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 no output schema, the description correctly carries the return-value burden and defines every stage label the agent will encounter. The gaps are edge behavior: no-criteria invocation (0 required params), empty results, and how `limit` truncates ambiguous match lists.

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 75%, so the baseline is already high. The description adds value by presenting the three filters as combinable ("and/or") and by reiterating the "HRB 12345" register format, but `limit` is never explained and there is no guidance on which combination gives the most reliable match.

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 sentence names a specific verb and resource: check whether a German company has insolvency proceedings. That is clearly separable from the siblings (stats, notices, customer checks). It stops short of naming which sibling to prefer, so it doesn't reach 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?

The description states the search criteria ("by name, register number and/or town") and advises that town "narrows ambiguous names", which implies usage. It never says when to use this over company_notices or insolvency_stats, or what to do when no criteria are supplied despite all params being optional.

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?

Annotations already declare readOnly, idempotent and closed-world, so the safety bar is low; the description then adds real behavioral context beyond them — API key requirement, plan-dependent batch size and history window (Trial: 5 customers, 24 months), and the fuzzy-match/ZIP-gating rule. It stops short of describing failure modes or how partial/ambiguous results are ordered across a batch.

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 the core operation and the return shape, then tucks the ZIP caveat and plan limits at the end. It is dense but every clause is informative; the return-field enumeration is slightly cluttered but still readable in a single pass.

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 no output schema present, the description carries the return-value burden and does so — status, matching companies best-first, confidence, match_basis, stage, and the `ambiguous` flag. Auth and quota constraints are also covered, leaving only error/partial-failure behavior unaddressed for a moderately complex batch 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 only 33%, and the description meaningfully compensates for the zip field by explaining that a name match only counts when the ZIP appears in the notice. However, `since` and `min_confidence` — including the 0.85 default that governs what counts as a match — get no explanation in the description, and neither does the `ambiguous` output interaction with confidence.

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 ('check a list of business partners') plus the matching mechanism ('same fuzzy matching as the Insolvenzmonitor monitoring'), which tells the agent this is a batch lookup rather than a single-entity lookup. It never names check_company as the single-record alternative, so sibling differentiation is only implied by the word 'list'.

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 conditional guidance for one parameter ('Send the 5-digit ZIP if known — with a ZIP, a name match only counts if the ZIP appears in the notice') and states plan-based limits. But it never says when to prefer this over check_company for a single customer, nor what happens when the batch exceeds the plan limit, so tool-selection guidance stays 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond them: results are newest-first, metadata-only (no full text), and include the proceeding stage. It doesn't mention pagination behavior or what happens at the limit boundary, which keeps it from a 5.

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, zero filler, with the scope, ordering and field list front-loaded and the sibling routing placed at the end. Every clause carries information an agent needs.

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 no output schema, the description usefully enumerates the returned fields and ordering, which is the key completeness gap for a list tool. The remaining hole is the undocumented limit/pagination parameter, which an agent calling this correctly would want to know.

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 only 50%: company_id is documented in the schema (pointing at check_company or the page URL), but the limit parameter has no description anywhere. The description says 'of one company' which loosely implies company_id, but never addresses limit, defaults, or maximum of 50, so it fails to compensate for the coverage gap.

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 ('notice history of one company') and enumerates the returned fields (date, category, case number, court, administrator, notice_id, proceeding stage). It also explicitly distinguishes itself from the sibling get_notice, so an agent can pick between them 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?

Clearly frames the tool as the list/metadata entry point and names the alternative ('Fetch the full text of a single notice with get_notice'). It lacks explicit when-not guidance (e.g., that other siblings like insolvency_stats cover aggregates), but the routing for the main ambiguity is spelled out.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real context beyond them: the content is German-language official text, calls are single-notice scoped, and an API key is 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?

Three short sentences, front-loading the core purpose, then use cases, then operational constraints. No sentence is redundant with another.

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 read tool with full annotation coverage and no output schema, the description covers purpose, content type, cardinality and auth. It only omits what the returned text looks like structurally, which is a minor gap since the description states it is the raw official full text.

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 the single notice_id parameter is already documented as coming from company_notices. The description adds no further detail on the identifier's format or example values, so the schema carries the burden and 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?

The description gives a specific verb+resource: the full official text of one insolvency notice, including its language (German) and cardinality (one notice per call). That clearly separates it from the sibling company_notices, which implies a listing, though the sibling is not 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?

"e.g. to read the administrator, deadlines or the creditors' meeting" tells the agent concretely what this tool is for, and "One notice per call" plus "Needs an API key" set call conditions. It stops short of explicitly routing the agent to company_notices when it lacks a notice_id, which the schema only implies.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description still adds real value by disclosing the data source ('official notices') and that only recently completed months are counted — a non-obvious temporal constraint. It stops short of describing result shape or ordering.

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 the subject and granularities front-loaded, followed by parameter behavior. The inline enum mapping is slightly repetitive but earns its place because the schema leaves that enum undocumented.

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?

There is no output schema, so the description is the only place to explain what comes back, and it only says 'figures' — not whether these are counts of opened proceedings, per-period values, or how the dimension/name selection reshapes the response. The parameter and scope coverage is solid, but the return-value gap is meaningful for a statistics 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 only 33%: `dimension` has no schema description and `months` only carries a default and bounds. The description compensates by mapping each enum value to its meaning (monat/bundesland/branche) and by defining `months` as the count of recent completed months, plus clarifying that `name` narrows to a single state or sector.

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 (corporate insolvency figures for Germany from official notices) and its three granularities, so an agent knows exactly what data it returns. It does not explicitly contrast itself with siblings like check_company or company_notices, but the resource is distinct enough that confusion is unlikely.

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 agent can infer it should call this to obtain aggregate insolvency statistics rather than company-level data. There is no explicit when-to-use/when-not statement and no mention of prerequisites or the sibling tools that would be preferred for per-company lookups.

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