agenten-tuer

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds one genuinely non-redundant fact — the request is delivered by email to the business itself, an external side effect — but says nothing about irreversibility, repeat calls sending duplicate mails, or what the caller receives back.

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, well front-loaded: the action first, the routing constraint and delivery detail second. No filler, though the parenthetical hint could be integrated more tightly.

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 non-idempotent, externally-visible write with no output schema, the description should say more: it never states that all four fields are transmitted, whether a confirmation or reference is returned, or whether repeated calls create duplicate emails. Annotations plus the email-delivery note make it minimally viable but incomplete.

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% (only 'kontakt' has a description), so the description must compensate. It clarifies the origin of 'kennung' (from betrieb_suchen), which is real value, but leaves 'name', 'anliegen' and even 'kontakt' semantics (whose name/contact is this — the requester's?) unaddressed for a 4-required-parameter tool.

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 concrete verb and resource: it leaves a request ('Anfrage') directly with a business from the hub, and it ties the operation to the sibling betrieb_suchen as the source of kennung. It does not explicitly distinguish itself from the similar-sounding betrieb_fragen or flowboxx_anfrage, so it falls short of full sibling differentiation.

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?

It implies usage by noting that 'kennung' comes from betrieb_suchen, which tells the agent this is a follow-up to a search. However it gives no when-to-use/when-not guidance relative to betrieb_fragen or flowboxx_anfrage, and no prerequisites or exclusions.

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?

Goes well beyond the annotations by disclosing the full lifecycle: a DRAFT is created first, activation requires clicking a confirmation link mailed to kontakt_mail and is valid 48 hours, and nothing is created without zustimmung=true. This is exactly the behavioral context an agent needs for a mutating, non-idempotent entry tool.

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 tight sentences, front-loaded with the core action and then the constraints. Every sentence carries a distinct, necessary fact (draft state, confirmation mechanism, hard requirement, use case) with no filler.

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?

No output schema exists, and the description covers the essential behavioral outcome (draft until confirmed, not discoverable until active). Minor gaps remain regarding the optional arrays and any pricing/notification nuances, but the agent has what it needs to call this 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?

With schema coverage at 60%, the description adds real meaning beyond the schema: it explains that kontakt_mail drives the confirmation mail and that zustimmung=true gates the entire operation. It leaves the optional fragen and leistungen fields unexplained, but the critical parameters are clarified.

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: registering a business with contact details into the flowboxx customer list. It is clearly differentiated from read-oriented siblings like betrieb_suchen and betrieb_fragen, though no sibling is named explicitly. An agent knows exactly what action this performs.

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 final sentence gives an explicit when-to-use condition: an AI acting on behalf of a business that wants to become contactable. It does not name alternatives or state when-not to use it, but the use case is unambiguous.

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 openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond that: the answer is derived 'ausschließlich aus dessen eigenen Angaben', i.e. grounded only in the business's own data with no external inquiry. It does not cover failure behavior for an unknown kennung.

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 sentence with the key constraint (already-found business, grounded only in its own data) front-loaded and zero wasted words. The parenthetical is compact rather than filler.

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?

No output schema exists, yet 'Beantwortet eine Frage' adequately signals a textual answer. With only two params and full annotation coverage, the description supplies everything needed to invoke the tool correctly, minus edge-case handling for invalid IDs.

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 explain the origin and meaning of 'kennung' (from betrieb_suchen) but says nothing about the 'text' parameter beyond the implied 'Frage'; half the parameters remain semantically thin.

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 (eine Frage zu einem Betrieb) and explicitly routes the caller to the sibling betrieb_suchen for the kennung. It separates itself from the search tool, though it does not explicitly distinguish itself from the near-parallel flowboxx_frage.

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 phrase 'bereits gefundenen Betrieb (kennung aus betrieb_suchen)' makes the precondition clear: this tool is used after a business has been located. No explicit when-not or exclusions are given, but the usage context is unambiguous.

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, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: only ACTIVE doors/businesses are returned, warning the agent that results are filtered and potentially incomplete. It says nothing about result limits or return format, keeping it below 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, front-loaded with the action and scope, then the usage trigger. Every clause carries information and there is no filler.

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 search tool with no output schema and full annotation coverage, the description supplies scope, filtering behavior and a usage trigger — enough to call it correctly. Minor gaps remain around pagination or result-size expectations, but nothing essential 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 description coverage is 100% and both parameters are documented there ('Ort oder Region' and 'Betriebsname oder gesuchte Leistung'). The description loosely echoes this mapping ('einen bestimmten Betrieb oder ein Angebot in einer Region') but adds no format or matching semantics, so the baseline of 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 ('Sucht einen Betrieb im flowboxx-Hub') and adds a scope constraint ('nur AKTIVE Türen') that tells the agent what subset is searchable. It is clearly distinct from siblings like betrieb_anfrage or tuer_anlegen, but it never names an alternative explicitly, 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?

The second sentence gives an explicit usage trigger: use it when an AI is looking for a particular business or offering in a region on behalf of a human. That is a clear context, but there are no when-not conditions and no sibling alternatives named, so it stops at 4.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the agent knows this is a non-destructive, non-idempotent write confined to the flowboxx world. The description adds that the request is routed to a human, which is meaningful behavior, but says nothing about delivery, response timing, or whether the request can be withdrawn.

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 what the tool does before the usage condition and the field clarifications. No filler, though the parameter clarifications at the end could have been compressed since the schema already covers them.

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 mutation tool with full annotation coverage and no output schema, the definition covers what it does, when to invoke it, and how the free-text fields should be filled. What is missing is minor: how the gespraechsverlauf payload relates to flowboxx_bedarf and what the user should expect after submitting.

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 baseline is 3. The description restates the kontakt rule (e-mail OR phone, at least one) and the anliegen company-name allowance, both largely mirrored in the schema field descriptions, so it adds little genuinely new parameter meaning. The optional gespraechsverlauf parameter is not addressed in the description at all.

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: it leaves a contact request for a human at flowboxx. The action is unambiguous and distinct from a pure lookup tool, but it never names or contrasts against close siblings such as flowboxx_frage or betrieb_anfrage, which an agent could easily confuse with this one.

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 der Nutzer ausdrücklich Kontakt aufnehmen oder eine Anfrage hinterlassen möchte" gives a clear triggering condition and the word "ausdrücklich" usefully signals not to fire speculatively. It stops short of naming the alternative when the user only has a general question rather than a request (e.g. flowboxx_frage).

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 establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes beyond that with substantive constraints: it asks at most three fixed questions, returns exactly three proposals (klein/mittel/groß), and explicitly makes no promises about prices, dates, or feasibility — a real scope boundary.

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 sentence, but front-loaded with the core action and each clause earns its place (behavior, count limits, output shape, exclusions). 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?

With no output schema, the description usefully explains what comes back (a summary plus three proposals) and what is deliberately withheld. Minor gap: the exact trigger distinguishing the question-asking state from the summary state (presence of antworten) is left implicit.

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%: antworten and session_id are described in-schema, while brief carries no description. The description implicitly clarifies brief (freier Kundenwunsch) and the follow-up answer flow, but adds no syntax or format detail beyond what the schema already provides, 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+resource (klärt einen freien Kundenwunsch) and describes the actual multi-step behavior (fixed follow-up questions, then a summary with three proposals). However, it never names or contrasts with its siblings (flowboxx_anfrage, flowboxx_frage), so an agent must infer the boundary itself.

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 workflow is described (ask questions while mandatory data is missing, then produce proposals), which implies when the tool is appropriate. But there is no explicit when-not or routing guidance versus the very similar-looking sibling tools, so usage must be inferred.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavioral context: output length is bounded to 2-4 sentences, answers come only from internal knowledge, and unknown topics trigger an honest fallback rather than fabrication.

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, front-loaded with the action and its constraints, with no filler. Slightly compressed but nothing that fails to earn 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 read-only single-question tool with no output schema, the description covers the essentials an agent needs: bounded output length and honest-fallback behavior on unknown topics. An explicit pointer to flowboxx_anfrage for the alternative case is the main thing 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?

There is one parameter and schema description coverage is 100%, so the schema already documents 'text' with its 600-character limit. The description adds only the characterization of the input as a 'freie Frage'; baseline 3 applies since the schema does the heavy lifting.

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: answering a single free-form question about flowboxx, scoped to 2-4 sentences and to its own knowledge. The 'einzelne freie Frage' framing does distinguish it from plural-question siblings, but it never names flowboxx_anfrage, so differentiation is left to inference.

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 implied by 'eine einzelne freie Frage' (single vs. bulk) and by restricting answers to own knowledge, which signals a self-contained Q&A rather than a lookup. However there is no explicit when-to-use/when-not-to-use statement and no alternative named among the seven siblings.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: pricing/offer data (Preis, Lieferzeit in Werktagen, Verzugsregel, Kündigung) is only returned 'wenn der Betreiber Festpreise veröffentlicht hat', i.e. the response is conditional. No auth or rate-limit details are given.

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 verb and return payload, followed by the usage condition. The field enumeration is dense but each item earns its place since there is no output schema. No filler.

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 and no parameters, the description carries the full burden of describing the return value, and it does so by enumerating the record fields and the conditional offer fields. An agent knows what it will get and under what condition the price block appears.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies no input is required.

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 zurück') and enumerates the returned fields (Bereich, Leistung, für wen, Beleg-Link, Status) plus conditional pricing data. The usage clause ('was flowboxx anbietet und was es kostet') distinguishes it from the sibling anfrage/frage/bedarf tools, which handle requests, questions and needs rather than the catalogue itself.

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 an explicit triggering condition ('Nutzen, wenn jemand wissen will, was flowboxx anbietet und was es kostet'), which tells the agent when this tool applies. It does not, however, name the sibling tools it should be preferred over or state any exclusion, so it stops short of full routing guidance.

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