agenten-tuer

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

The description states that an email is sent to the business itself, which is an external side effect, while the annotations set openWorldHint=false. This contradicts an external communication and is a serious inconsistency. The readOnlyHint=false annotation aligns with mutation, but the open-world contradiction dominates.

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 short sentences, front-loaded with the core action and effect. There is no filler or redundancy.

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 mutating tool that sends external email with four required parameters and no output schema, the description is too sparse. It omits permissions, delivery expectations, and most parameter meanings, and its open-world contradiction further reduces 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 only 25%: kontakt is described as 'E-Mail oder Telefonnummer', but kennung, name, and anliegen have no descriptions. The tool description adds only that kennung comes from betrieb_suchen, leaving three of four parameters semantically 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 action (Anfrage hinterlassen), the resource (Betrieb aus dem Hub) and the source of the identifier (kennung aus betrieb_suchen). It does not distinguish itself from the sibling betrieb_fragen, so a 5 is not justified.

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?

Implies usage after betrieb_suchen by pointing to kennung as the identifier source, but gives no explicit when-to-use, when-not-to-use, or alternative (e.g., betrieb_fragen).

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, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioural context beyond them: the answer is derived 'ausschliesslich aus dessen eigenen Angaben', i.e. no external sources are consulted, which tells the agent what the answer can and cannot contain.

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 no filler, and the identity/scope constraint is front-loaded. Efficient, though the parenthetical 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 two-parameter read-only tool with annotations and no output schema, the description covers the key precondition, scope, and source of the answer. It omits failure behaviour for an invalid kennung, which keeps it from a 5.

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 carry the parameter burden. It does explain that kennung originates from betrieb_suchen and that the tool handles a Frage (implying text is the question), but the text parameter's format and expected phrasing are left implicit. Partial compensation for an undocumented 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?

Names a specific verb (beantwortet) and resource (Frage zu einem bestimmten Betrieb), and explicitly ties the kennung parameter to betrieb_suchen, which separates it from siblings like betrieb_suchen or betrieb_anfrage. It is clear what the tool does, though it does not state what kind of answer is returned.

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?

States a clear precondition: the business must already be found and its kennung obtained from betrieb_suchen. This implicitly routes the agent to betrieb_suchen first. It does not name an explicit alternative or when-not-to-use case, so it falls short of 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds one genuinely non-obvious behavioral constraint, that only AKTIVE Tueren are returned, but says nothing about result count, ranking, or pagination. Valuable but thin beyond what the annotations supply.

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, front-loaded with the action and the scope constraint before the usage note. Slight verbosity in 'fuer einen Menschen', but no sentence is 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?

For a simple two-parameter read-only search with no output schema, the description covers what is searched, the active-only filter, and the intended caller. It leaves the result shape and any limit unstated, which is the main remaining gap.

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 100% and both parameters are documented in the schema ('Ort oder Region, optional', 'Betriebsname oder gesuchte Leistung'), so the baseline is 3. The description adds no matching semantics, e.g. whether text matches name only or free-text services, nor how ort and text combine.

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 concrete verb+resource ('Sucht einen Betrieb') plus a scoping qualifier ('im flowboxx-Hub, nur AKTIVE Tueren'), so an agent knows exactly what is being searched. It does not explicitly distinguish itself from near-name siblings such as betrieb_fragen or betrieb_anfrage, which is the only thing keeping it out of the top band.

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?

'Nutzen, wenn eine KI fuer einen Menschen einen bestimmten Betrieb oder ein Angebot in einer Region sucht' gives a clear triggering context for the tool. No alternatives are named and no when-not-to-use condition is given, so it stops short of 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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world write, so the safety profile is covered. The description adds that a human will follow up on the request, which is useful behavioral context, but says nothing about confirmation, error handling, or duplicate-submission behavior for a non-idempotent write.

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-loaded with purpose followed by usage and field clarification. No filler, though the final field note is somewhat redundant with 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?

For a simple contact-submission write with no output schema, the description covers purpose, trigger, and the two ambiguous text fields. It omits post-call expectations (confirmation, human response time) but is otherwise sufficient to invoke the tool 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description restates that kontakt is email or phone and that anliegen may include a company name - useful emphasis but essentially a repetition of the schema descriptions, so the 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?

States a specific verb+resource: it leaves a contact request for a human at flowboxx. An agent can tell it creates an inquiry rather than answering one. However it never names the close sibling betrieb_anfrage or flowboxx_frage, so differentiation must be inferred from the names.

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 a clear triggering condition - use when the user explicitly wants to make contact or leave a request - with 'ausdruecklich' acting as an implicit qualifier against casual chatter. It does not, however, name any alternative tool or state when not to use it, leaving the routing between it and betrieb_anfrage/flowboxx_frage unaddressed.

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, destructiveHint, and openWorldHint, so the bar is lower. The description adds meaningful behavior: it asks up to three fixed follow-up questions while required information is missing and returns three proposals without prices, appointments, or feasibility commitments. It does not explain the non-idempotent interaction state further.

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 dense German sentence that is front-loaded with the core purpose and then unpacks the process, output, and constraints. All clauses are informative, though the sentence is long and could be split for readability.

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, but the description explains that the tool returns a summary with three proposals (small, medium, large) from the service inventory. Annotations cover the safety profile, and the schema documents two of three parameters, so the description is largely complete for this conversational clarification 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 67%, with descriptions for antworten and session_id but none for brief. The description conceptually maps 'freien Kundenwunsch' to brief and 'Rueckfragen' to antworten, but adds no syntax, format, or key details beyond the 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?

States a specific verb (Klaert) and resource (freien Kundenwunsch) plus a clear process and output. However, it does not explicitly differentiate from siblings such as flowboxx_frage or flowboxx_anfrage, so an agent must infer the distinction.

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?

Implies usage for a free customer request that needs clarification while mandatory details are missing. It does not state when not to use the tool or name alternative siblings, leaving alternative selection 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?

Annotations already mark read-only, non-destructive, idempotent, closed-world behavior. The description adds response length, own-knowledge limitation, and an honest fallback instead of fabrication, though it omits auth or rate-limit details.

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, front-loaded with the core action and followed by fallback behavior. No filler or repetition.

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 one-parameter Q&A tool with rich annotations and no output schema, the description covers purpose, response length, knowledge boundary, and fallback. Nothing essential for correct invocation 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?

Schema coverage is 100% and already documents the sole 'text' parameter, including the 600-character limit. The description adds no parameter syntax or constraints beyond what the schema provides, so the 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?

States a specific verb 'Beantwortet' and resource 'einzelne freie Frage zu flowboxx', with scope constraints of 2-4 sentences and own knowledge. Clear purpose, but it does not explicitly differentiate from siblings such as flowboxx_anfrage or betrieb_fragen.

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?

Implies use for a single free question about flowboxx and notes fallback behavior for unknown topics. However, it gives no explicit when-to-use criteria or alternatives among sibling tools.

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. With no output schema present, the description earns credit by disclosing the shape of what comes back (area, service, audience, receipt link, status). It says nothing about volume, ordering, or freshness of the list, which keeps it out of the top band.

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 waste: the return content is stated first and the usage condition follows. Every clause carries 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 parameterless, read-only catalogue lookup with no output schema, the description supplies everything an agent needs: what is returned, in what structure, and the situation that calls for it. Annotations cover the remaining safety semantics.

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 and there is no parameter behaviour the description could add or omit. Nothing in the text contradicts the empty 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?

States a specific verb and resource ('Gibt die strukturierte Liste aller flowboxx-Leistungen zurueck') and even enumerates the returned fields (Bereich, Leistung, fuer wen, Beleg-Link, Status). It implicitly separates itself from the sibling query tools (flowboxx_frage, flowboxx_anfrage, flowboxx_bedarf) by framing itself as the catalogue of what flowboxx offers, but 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?

'Nutzen, wenn jemand wissen will, was flowboxx grundsaetzlich anbietet' gives a clear triggering condition for the tool. It stops short of naming alternatives or exclusions (e.g. when to prefer flowboxx_frage or flowboxx_bedarf instead), so routing against the sibling set is left partly 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?

Richly describes behavior beyond annotations: creates a draft first, requires email confirmation via kontakt_mail with 48-hour validity, only then becomes active and discoverable by other KIs, and requires zustimmung=true or nothing is created. This adds critical two-phase commit semantics not captured by the annotations (which only state non-read-only, non-destructive, non-idempotent).

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?

Four sentences, each informative and front-loaded with the core action first. Slightly dense but every sentence earns its place by explaining draft mechanics, the zustimmung guard, and intended usage. Minor room for tightening prevents a 5.

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 a complex creation tool with 10 parameters, no output schema, and annotations covering safety, the description supplies the essential behavioral contract: draft state, email confirmation flow, and the hard zustimmung requirement. It leaves some optional parameters implied, but the key agent-facing information is present.

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 60%, so the schema documents most parameters. The description adds meaning for zwei kritische Parameter: kontakt_mail (receives the confirmation email) and zustimmung (required true otherwise nothing is created). However, it does not compensate for the remaining undocumented parameters (ort, name, fragen, leistungen), so baseline 3 is appropriate.

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 (anlegen) and resource (ENTWURF im flowboxx-Hub für einen Betrieb), making the action clear. However, it does not explicitly distinguish itself from sibling tools like betrieb_anfrage or flowboxx_* tools, so it falls short of 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?

Provides clear context: 'Nutzen, wenn eine KI im Auftrag eines Betriebs diesen ansprechbar machen moechte.' This tells the agent when to use it, but does not name alternatives or state when not to use it, so it is a 4 rather than a 5.

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