DutyKit

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

No annotations are supplied, so the description carries the full behavioral burden, yet it never states that the tool is a pure text generator (no mutation), whether 'firma' is inserted verbatim into the notice, or what the returned text looks like. For a compliance-drafting tool with zero annotation coverage this is a meaningful gap.

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 with the deliverable and the legal reference front-loaded; nothing is padded. It is efficient but so terse that it omits the parameter meaning entirely.

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 tool is simple (two params) and the description conveys the output artifact, so the core is covered without an output schema. It falls short on the required 'firma' parameter and on any hint about output structure or length, which matters for a legal notice template.

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 explain both parameters. It does partially compensate for 'sprache' by enumerating de, fr, en and lb, which the schema itself never does, but 'firma' is completely unexplained despite being the only required parameter, leaving the agent to guess whether it is a company name, a brand, or a placeholder key.

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 concrete deliverable (a suggested wording) and anchors it to a specific legal basis, AI Act Art. 50 Abs. 1, plus the four supported languages. An agent can tell this produces ready-to-use compliance text, though nothing distinguishes it from siblings like 'pflichten' or 'werbung_vorpruefen'.

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 when-to-use guidance, no mention of prerequisites, and no reference to the sibling tools that also touch AI Act obligations. The agent must infer that this is the drafting step rather than the obligation-lookup step.

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 implies a read/lookup operation but never states that it is read-only, what the response contains, whether results are paginated, or whether EU-wide obligations are merged with country ones (only implied by "inkl.").

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?

Extremely compact and front-loaded: the resource is stated first, then the parameter examples. Every fragment earns its place, though the telegraphic style and missing verb cost a bit of clarity.

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 annotations, no output schema, and 0% schema coverage, the description should explain what comes back (a list of obligations?) and confirm read-only behavior. It leaves the return shape entirely unspecified and covers only one of two parameters in depth.

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 does meaningful work for taetigkeit by enumerating valid values (website, online_handel, rechnung, werbung, ki_kontakt, gruendung) and explaining the empty default ("leer = alle"). It only partially covers land, giving example values DE/LU without stating whether other codes are accepted.

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?

"Pflichten für ein Land (DE, LU) inkl. EU-weiter Pflichten" names the resource (compliance obligations) and its scope (per-country plus EU-wide), so an agent can infer it's a lookup. However, there is no verb (get/list/retrieve) and no explicit statement distinguishing it from the sibling *_pruefen tools, which check things rather than list obligations.

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?

No when-to-use or when-not-to-use guidance and no mention of alternatives among the siblings (ki_hinweis, rechnung_vorpruefen, vat_pruefen, werbung_vorpruefen). The only usage hint is the parameter-level "leer = alle", which is about invocation, not tool selection.

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 exist, so the description carries the full burden. It usefully discloses that only DE is supported at present and encodes an actual validation rule ('steuersatz ODER steuerbefreiung_hinweis'), but it never states that the operation is non-mutating, what a check result looks like, or how findings are reported.

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 packed sentences with the scope constraint front-loaded and the required-field hint second; no filler. Slightly telegraphic phrasing ('Erwartet Felder wie') leaves the exact contract loose.

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 no annotations, no output schema and a free-form nested object, the description covers the essential contract: what is checked, under which law, and which fields the object should carry. Only the missing coverage of 'land'/'verantwortlich' and the shape of the result keep it below full marks.

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 schema says only that 'rechnung' is an open nested object. The description compensates by naming expected fields inside it (aussteller_name, rechnungsnummer, netto, steuersatz/steuerbefreiung_hinweis), which is genuine added meaning. It says nothing about the 'land' or 'verantwortlich' 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 states a specific verb and resource — 'Vorprüfung einer Rechnung auf Pflichtangaben' — and narrows scope to DE under § 14 Abs. 4 UStG, which is far more than the bare tool name conveys. It does not, however, differentiate itself from the sibling 'vat_pruefen', which an agent could plausibly confuse with this check.

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 word 'Vorprüfung' implies this is a pre-flight validation step, but there is no explicit statement of when to call it versus 'vat_pruefen', 'pflichten' or 'werbung_vorpruefen', and no exclusions. Usage must be inferred from the name and the legal reference.

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 at all, the description carries the full behavioral burden, and it only partially discharges it: 'live' and the VIES reference usefully signal an external, real-time network call that can be slow or unavailable. It says nothing about what is returned (validity flag, company name, address), failure modes, or cost/rate 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?

A single front-loaded sentence with no filler; the core action and the data source come first and the format example is inline. It is efficient, though the brevity leaves the gaps noted in other dimensions.

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 tool with zero annotations, no output schema, and an undocumented second parameter, the description is too thin: an agent cannot tell what the response contains or what 'verantwortlich' affects. The VIES reference and example ID are helpful but do not cover the tool's surface.

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 both parameters. The embedded example 'LU26375245' is genuinely valuable for ust_id — it conveys the country-prefix format that the schema does not — but the second parameter 'verantwortlich' is never mentioned or explained anywhere.

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 ('Prüft eine EU-USt-IdNr.') and adds the delivery channel ('live über die VIES-Schnittstelle der EU-Kommission'), so the agent knows exactly what operation this performs. It does not explicitly differentiate itself from the sibling tools (ki_hinweis, pflichten, rechnung_vorpruefen, werbung_vorpruefen), but the VAT-validation resource is obviously disjoint from 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 guidance, and no mention of alternatives or prerequisites (e.g. use before issuing an invoice, or what to do when VIES is down). The usage is only inferable from the verb 'prüfen' — an agent gets a hint of intent but no routing 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 exist, so the description carries the full load, yet it never says what the tool returns (boolean, verdict, legal reasoning?), that it is a read-only check with no side effects, or how the UWG outcome varies with the consent flag. The only behavioral signal is the legal framing and the implied jurisdiction (DE), which is useful but far short of what a compliance-judgment tool needs.

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?

It is short and front-loads the decision question, so nothing is padded. But the compression is excessive: mixed German/technical shorthand with semicolons and pipes reads as a fragment rather than a definition, and space saved is space the agent must reconstruct.

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 five parameters, three of them required, no annotations, no output schema, and zero schema descriptions, this one-line definition is not sufficient for correct invocation. Key inputs and the expected result are simply 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 coverage is 0% and 5 parameters exist, but the description adds meaning only for two of them (kanal, empfaenger), where it supplies enum values the schema lacks (email|telefon, verbraucher|unternehmen). The required parameter einwilligung_belegt is never mentioned, and bestandskunde and verantwortlich are 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?

The description states a concrete question the tool answers ("Darf ein Agent diese Werbung senden?") plus the legal basis (DE, § 7 UWG), which identifies a pre-send advertising compliance check rather than a generic validator. It is distinguishable from the sibling tools (invoice/VAT/duties checks), though it never says it returns a verdict, and the telegraphic style makes the purpose slightly harder to grasp than it needs to be.

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?

Use is only implied: you ask the question before sending advertising. There is no explicit statement of when to call it, whether it may be called repeatedly, or what to do when consent evidence is absent. The allowed channel/recipient values hint at scope but do not route the agent to or away from alternatives.

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