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

The description discloses key behavioral aspects beyond annotations: the offer is valid for 48 hours, price-stable, and the purchase itself is done by the human via bestell_url, not by the tool. It also highlights the confirmation requirement, indicating that calling the tool has real consequences. Since annotations are all false and provide no behavioral hints, the description carries the burden and does so effectively, though it could mention idempotency or side effects more explicitly.

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 sentence followed by a critical warning and variant notes. It front-loads the core function and outputs, then the important usage constraint, then the configurations. There is no fluff; every clause earns its place, making it concise and well-structured for quick scanning.

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 5 parameters and no output schema, the description covers the essential context: outputs (quote_id, bestell_url), the 48-hour validity, the human-triggered purchase, and the confirmation requirement. It explains the main variants but does not fully detail all parameter interactions (e.g., when to combine plz with umkreis_km versus using bundesland). The schema provides some of this info for plz and bundesland, so the description is adequate but not exhaustive for a tool with this complexity.

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 description adds meaning to umfang ('nur_email' variant) and bundesland (example 'Bayern'), clarifying their purpose. However, it does not explain idListe (the required parameter), plz, or umkreis_km beyond what the schema already provides. With schema coverage at only 40%, the description partially compensates but does not fully document all parameters, leaving the agent to infer the relationship between plz+umkreis_km and the other variants.

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 ('erzeugt' – generates) with a specific resource ('Angebot' – offer), and specifies the outputs (quote_id, bestell_url). It also mentions validity and price stability, making it distinct from sibling tools like branchen_suchen or liste_details, which are query/list tools. The verb and resource are unambiguous.

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 an explicit prerequisite: 'Nur nach ausdruecklicher Bestaetigung des Nutzers aufrufen' (only call after explicit user confirmation), which is crucial for a mutating action. It also explains variants like umfang='nur_email' and bundesland='Bayern', providing context for when to use those configurations. While it doesn't explicitly state 'when not to use', the tool's purpose is clearly unique among siblings, so the absence of alternative routing is not a major gap.

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 readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful detail about the returned data and the intended workflow, but does not disclose behaviors like pagination, response size, or failure modes. This is acceptable for a simple search tool but not exceptional.

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 two sentences with no filler. It front-loads the core action, then lists output fields and workflow placement. Every sentence 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 simple two-parameter search tool, the description covers the purpose, output fields, and workflow. The only notable omission is the 'land' parameter's semantics, but the enum values de/at/ch make it reasonably inferable. No output schema exists, so listing the returned fields is valuable and largely sufficient.

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 50%: 'q' is documented in the schema, and the description reinforces it with examples. However, the 'land' parameter is only an enum in the schema and is not mentioned in the description, leaving its meaning and default behavior undocumented. The description does not compensate for this 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?

The description states a specific verb and resource: 'Findet Adresslisten zu einem Suchbegriff' and lists the exact returned fields. It also distinguishes itself from siblings by declaring it is 'immer der erste Schritt vor Details oder Angebot'.

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 clear workflow guidance: this tool is the first step before details or offer creation, which implicitly routes the agent away from liste_details and angebot_erstellen. It does not name alternatives explicitly, but the context is sufficient.

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 readOnlyHint=true provided in annotations, the safety profile is already declared, lowering the bar. The description adds useful context — that the content is authoritative legal text to be reproduced verbatim to the user ('korrekt wiedergeben') and is machine-readable. No contradiction with annotations; the description aligns with a safe read operation.

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 compact sentences with zero filler. The first defines the resource and its scope; the second states the trigger and the expected handling. The most important routing information ('vor einer Kaufempfehlung') is front-loaded in the second sentence, and every word 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 parameterless, read-only tool with no output schema, the description covers the content scope and the usage trigger adequately. It could ideally specify the output structure beyond the single adjective 'maschinenlesbar', which is why it is not a 5, but 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?

The tool has zero parameters and a fully closed schema (additionalProperties: false), so there is nothing for the description to document. The 0-parameter baseline of 4 applies; the description cannot and need not compensate for undocumented parameters.

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 identifies a specific resource (purchase and usage terms) and lists concrete content dimensions — B2B-only, VAT, revocation, UWG/GDPR data-use limits — and the verb 'abrufen' (retrieve) makes the action explicit. It is clearly distinguishable from the siblings, which concern creating offers, searching industries, listing countries, and list details. It loses a point only because the resource type is implied rather than stated outright as an object.

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 an explicit trigger condition: 'Vor einer Kaufempfehlung abrufen und dem Nutzer korrekt wiedergeben' (retrieve before a purchase recommendation and relay correctly). This tells the agent when to invoke the tool and how to handle the result. It does not name alternative tools or state when not to use it, which keeps it from a 5.

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?

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: the data source, the DACH/on-request split, the inclusion of counts, and the data status. It does not describe the exact output format, but for a zero-parameter listing tool this is acceptable.

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 that immediately states the action and resource, then adds the most important constraints (DACH vs. on-request, counts, data status). Every clause adds information; there is no filler or repetition of the title.

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 parameterless list tool, the description adequately conveys what the agent will get: a list of countries, availability, counts, and data status. It could specify the output structure more explicitly, but the absence of an output schema is mitigated by the simple, overview-like nature of the operation.

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 has zero parameters, so the input schema fully covers parameter semantics. With 0 params, the baseline is 4, and the description does not need to explain parameter behavior beyond what the schema already states.

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 ('Listet') and a specific resource (countries with B2B firm addresses from firmenliste.net), and it clarifies scope (DACH vs. ~40 other countries on request). This clearly differentiates it from sibling tools like liste_details or branchen_suchen, which cover other aspects of the same data source.

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 makes clear this is the tool for getting an overview of available countries and their purchasable lists, including counts and data status. It does not explicitly name alternatives or state when not to use it, but the scope and availability constraints are specific enough for an agent to select it appropriately.

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 readOnlyHint=true, and the description adds useful behavioral context: the optional plz+umkreis_km combination triggers a live count of only companies in the radius, and all prices are net prices plus German VAT. No contradiction with annotations.

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, information-dense sentences, front-loaded with the core purpose and followed by essential details. Every clause adds value and there is no filler or repeated schema content.

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 carries the burden of describing returns and does so by enumerating expected result components plus the radius variant. It lacks an explicit statement of default behavior without plz, but is otherwise nearly complete for a read-only detail 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 already documents idListe and plz; the description goes further by explaining that plz and umkreis_km work together as a radius search and affect the live count and price. It does not add much detail for umkreis_km beyond schema min/max, but the combination semantics are valuable.

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 identifies a specific operation ('Detailansicht einer Adressliste') and enumerates concrete outputs: field counters, federal state distribution, contained fields, and package prices. This clearly differentiates it from sibling tools like branchen_suchen or angebot_erstellen.

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 clear context for when to use the tool: to retrieve list details and prices, optionally with a PLZ/radius variant for live company counts. It stops short of explicitly naming alternative sibling tools or saying when not to use it.

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