Helfer & Profi

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

With only hint-level annotations (readOnlyHint=false, destructiveHint=false), the description carries real weight and delivers: it discloses that the user's name, contact, location and message are transmitted to a third party, that the provider replies directly to the user, and that consent is mandatory. It does not mention rate limits, reversibility, or what happens on failure, leaving a few gaps.

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, each carrying distinct information: what the tool does, the consent precondition, the data flow and follow-up, plus a constraint. Front-loaded with the action and free of 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 an 8-parameter, no-output-schema mutation tool, the description covers the essential contract: consent gating, transmitted fields, and result behavior. It omits finer points such as handling of phone/text_only preferences and error cases, but the schema descriptions largely cover those.

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 already 88%, so the baseline is 3, but the description adds genuine meaning: it lists which fields (Name, Kontakt, Ort, Nachricht) actually travel to the provider and clarifies that provider_id must come from search_providers. That is useful semantic framing beyond the per-property descriptions.

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 (anfragen) and resource (Anbieter aus dem Verzeichnis), and explicitly ties provider_id to search_providers, which distinguishes it from sibling tools like register_provider or provider_reviews. An agent can identify the operation and its input source without opening the 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?

Gives a clear precondition ('Nur nach Zustimmung des Nutzers') and points to search_providers as the way to obtain provider_id, establishing the intended workflow. It stops short of naming alternatives or stating when-not-to-use conditions, so it is strong but not exhaustive.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses the real behavioral consequences: publication is immediate or moderated depending on settings, a double opt-in link is sent to contact, and the request is deleted if not confirmed within 48 hours. That 48-hour auto-deletion and the moderation gate are exactly the kind of non-obvious traits an agent must know before calling.

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?

Six short sentences, front-loaded with purpose and the consent precondition, then the confirmation flow. The confirmation-link sentence bundles several facts (48h, deletion, visibility, offer delivery) but each fact is distinct and none is 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 13-parameter, 4-required mutation tool with no output schema, the description covers the full lifecycle from submission to confirmation and follow-up offers. The one gap is that it never says what the call returns (e.g., a job identifier), which matters since no output schema exists.

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 already 92%, so the schema carries most parameter meaning. The description still adds value beyond it by specifying that contact must be an email address and, crucially, that a relative's address should be used if the user has none — a fallback rule absent from 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?

The first sentence names a specific verb and resource ('Gesuch für den Nutzer aufgeben'), so the creation role is unambiguous against read-oriented siblings like get_job or search_jobs. It does not, however, explicitly contrast itself with submit_offer or the other write-path siblings.

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?

A hard precondition is stated up front: 'Nur nach Bestätigung durch den Nutzer', which tells the agent not to call it on its own initiative. It gives clear context but no explicit exclusions or named alternatives for the other job-related 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?

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), it explains that name, contact and message are forwarded to the entry owner, that the owner replies directly to the user, and that there is a hard cap of one request per entry per day. Those delivery, privacy and rate-limit facts are exactly what the annotations cannot convey.

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 compact sentences, front-loaded with the action and the consent precondition, followed by delivery behavior and the rate limit. Every sentence carries a constraint an agent would otherwise get wrong.

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 write-side request tool with no output schema, it covers permission, recipient, delivery channel, rate limit and content rules. It does not say what a successful or rejected submission returns, which is a minor gap given there is no output schema to describe that.

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 83%, so the schema already documents most fields; the description still adds the origin of ding_id (from dinge_suchen) and reinforces the consent requirement, which is the highest-risk parameter. The optional phone parameter is not mentioned in the description, a small remaining 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 concrete action and target: requesting contact with the person behind an entry, and it explicitly ties ding_id to dinge_suchen, which separates it from pure search tools. It does not distinguish itself from the sibling contact_provider, which also sounds like a contact/request flow, so an agent may still hesitate between the two.

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 gives a clear precondition ('Nur nach Zustimmung des Nutzers'), a rate limit ('Höchstens eine Anfrage je Eintrag und Tag') and a content restriction ('Keine Internet-Links'). What is missing is an explicit statement that the entry must first be found via dinge_suchen, and no explicit comparison with contact_provider.

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 description adds substantial behavior beyond the annotations: which fields become public, what must not appear publicly, the email confirmation link with 48-hour validity and deletion on failure, 60-day visibility after confirmation, and 30-day visibility without photos for art=suchen. It discloses the full lifecycle and communication flow, which the annotations alone do not provide.

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 dense but front-loaded with the core purpose and constraints. Every sentence carries relevant rules or lifecycle information, though the paragraph packs several distinct concerns and could be slightly easier to scan.

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 complex create-listing tool with 10 parameters and no output schema, the description covers the essential workflow, visibility, consent, confirmation, expiry, and contact behavior. It does not repeat every schema detail, but it provides the contextual information an agent needs to call the tool correctly and safely.

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%, so the schema already documents all parameters. The description still adds useful meaning by emphasizing public visibility rules for titel, beschreibung, ort, and kurzname, and by clarifying the email confirmation workflow tied to kontakt. It does not explain every parameter, but it adds meaningful constraints beyond the schema text.

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 action: creating a listing for lending, giving away, or searching, including the art=suchen variant. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as dinge_suchen, so sibling differentiation is only implicit.

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 gives clear usage conditions: only on the user's explicit request, only after confirmation, only free of charge, and only for pickup. It does not name alternative tools or explain when to use those instead, 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 and destructiveHint=false, so the safety profile is known. The description still adds useful context beyond that: results are 'sichtbare Einträge (ohne Kontaktdaten)', meaning contact data is withheld, and it explains that distance-sorted results appear only for Umkreissuche and that each entry carries up to three photos plus a shareable link.

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 dense paragraph, but it is front-loaded with the scope and then the result fields, followed by filter semantics. Every sentence carries operational detail, though the run-on packing of field definitions makes it slightly harder to scan than a structured list would be.

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 six parameters, no output schema, and no annotations covering return values, the description comprehensively documents the response shape (id, art, kategorie, titel, beschreibung, ort, kurzname, seit, km, fotos, link) and the sorting behavior for Umkreissuche. Nothing essential for calling or interpreting this search tool 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 schema covers 67% of parameters, and the description meaningfully adds to it: it defines art values (verleihen = to lend, verschenken = gifted, suchen = seeking), clarifies that ort with only digits means a PLZ prefix while otherwise it is a place name, and states that umkreis_km (1–200) must accompany a 5-digit PLZ. It does not add anything for q or max_results, and kategorie is explained mainly in the schema itself.

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: listing visible entries in the Verleihen & Verschenken category, and it enumerates the result fields. It distinguishes itself implicitly from the singular ding_holen by describing a plural, filtered list, but it never names a sibling tool.

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 the enumeration of filters (q, art, ort, umkreis_km) and the remark that Umkreissuche requires a 5-digit PLZ. However, there is no explicit guidance on when to use this tool instead of siblings like ding_holen or ding_anfragen, and no stated 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?

Beyond the readOnly/non-destructive annotations, it discloses that contact data is omitted and that ok=false signals a vanished entry. That is useful behavioral context for a read operation; auth/rate-limit details are absent but annotations already lower the burden.

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 tight sentence with no filler, front-loading the resource and privacy note before the example. Every element 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 read-only lookup with annotations and no output schema, it covers visibility, contact-data omission, and the not-found response. Adequate for correct invocation, with minor gaps around the full success response.

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% for the single required id parameter. The description partially compensates by linking it to the #ding=12 fragment in shared links, but does not state id format, valid range, or behavior for invalid ids.

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 (fetch a single visible entry) and resource (ding), plus privacy scope 'ohne Kontaktdaten' and a shared-link example. It implicitly distinguishes itself from plural search siblings via 'ein einzelner', though it does not name an alternative tool.

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 concrete usage context, e.g. from a shared link ending in #ding=12, which implies when to call it. However, it does not explicitly say when to use this versus dinge_suchen or other lookup tools, nor state prerequisites.

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/destructive=false and closed-world, so the safety bar is met. The description adds genuine behavioral detail beyond that: contact data is withheld, an empty list is returned when the entry is no longer visible, and shared jobs return the group card with search_jobs-shaped fields.

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 the core purpose, then edge-case behavior. The URL fragment is illustrative rather than wasteful, though the phrasing 'Leere Liste' inside a single-item getter takes a moment to parse.

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 covers the return shape (empty list on invisibility, group card for shared jobs, fields matching search_jobs) and the notable omission of contact data. Nothing essential for a correct call 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 0% for the single required job_id, so the description must compensate. It only implies the value format via the '#gesuch=12' URL fragment, giving a usable hint about what the integer represents but not stating it directly.

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: fetching a single visible Gesuch, explicitly without contact data. The reference to search_jobs and the shared-link example distinguish it from the list-oriented sibling, though the title 'Einzelnes Gesuch' already carries most of this.

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 one concrete usage scenario (resolving a job from a shared link like …/#gesuch=12), which implies when to reach for it, but never states when to prefer search_jobs instead or what to do when the id is unknown. Usage is inferable rather than prescribed.

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 description discloses rich behavioral details beyond the annotations: a confirmation email link valid for 48 hours, automatic offer delivery afterward, public visibility limited to location, quantity, and note, and that each household decides and pays independently. It also notes that the response is always the same even if the user has already joined, which is useful idempotency context.

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 front-loaded with the core action and then adds only relevant prerequisites and outcomes. Despite being a single paragraph, every sentence contributes useful information without 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?

Given the moderate complexity, high schema coverage, and annotations covering the safety profile, the description provides enough context for an agent to call the tool correctly. It covers prerequisites, side effects, visibility rules, and response behavior, and no output schema is needed.

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 high at 86%, so the schema already documents most parameters. The description still adds meaningful context: it reinforces that the location must share the request's postal code and clarifies which fields become public, enhancing the schema's parameter descriptions.

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 action: the user joins a shared request identified via group_ok=true from search_jobs. It names the resource and the resulting behavior, making it clearly distinguishable from siblings such as create_job or search_jobs.

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 gives clear prerequisites: the request must come from search_jobs with group_ok=true, the user must have the same postal code, and consent is required. It does not explicitly name an alternative tool for cases where these conditions are not met, but the usage context is strong.

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, non-destructive and closed-world, so safety is covered. The description adds the important scope constraint that only reviews from brokered customers are returned, which the agent could not derive from annotations. It does not mention pagination despite max_results.

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 short sentence with no filler, front-loading the resource. It is concise but perhaps too short for a 2-parameter tool with no documented 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?

No output schema exists, so the description should at least say what a review contains or how results are ordered/limited. With 0% parameter coverage and no output schema, the definition leaves the agent under-informed about both inputs and returns.

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 load, but it says nothing about provider_id or max_results, including the 1-200 cap on results. The agent gets no guidance on what provider_id refers to or how max_results affects the response.

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 resource (published reviews of a provider) and clarifies scope (only from brokered customers). It does not explicitly distinguish itself from the sibling submit_review, which is the write counterpart, but the verb 'Bewertungen veröffentlicht' implies retrieval.

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 no when-to-use guidance, no exclusions, and never mentions submit_review as the alternative for submitting a review. The agent must infer that this is the read-side of the review flow from the name alone.

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?

Beyond the annotations, it discloses important behavior: the registration appears only after operator review, name/location/services become public, contact details must stay in contact, and trader_info is publicly displayed. It also explains conditional display of “Pflegekasse möglich” and the need for explicit rule confirmation, which is valuable operational context.

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 dense but front-loaded: purpose and adult-only restriction come first, followed by review/publicness constraints and then conditional requirements. Despite being a single German paragraph, every sentence carries relevant registration constraints 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 an 11-parameter registration tool with no output schema, the description covers the essential workflow: adult-only registration, operator review, public versus protected fields, commercial versus private classification, trader_info obligations, and Pflegekasse conditions. The remaining schema-level details, such as consent, are already fully documented in the schema.

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%, so the schema already defines all parameters in detail. The description still adds useful cross-parameter semantics, especially which fields become public, where contact data belongs, and how is_trader, trader_info, pflegekasse, and pflegekasse_regeln interact.

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 action and resource: registering as a provider, with the key restriction that only adults may register. It is clearly distinct in practice from sibling tools such as contact_provider, but it does not explicitly name alternatives or draw that contrast.

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 gives clear usage context: use this to register a provider, only for adults, ask beforehand whether the user is commercial or private, and apply trader_info or Pflegekasse rules conditionally. It does not explicitly state when to use a sibling tool instead, so it falls short of full alternative-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?

Annotations already declare a safe, non-destructive write operation in a closed world. The description adds useful context: the report is tied to DSA Art. 16, and providing a contact email triggers an automatic confirmation of receipt—a behavioral side effect not captured by 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?

A single, front-loaded sentence with a colon-separated list of target types. Every clause adds value—legal basis, valid targets, and contact behavior—with zero 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 four-parameter reporting tool with annotations but no output schema, the description covers purpose, legal context, target types, and the contact-email side effect. What happens after submission (moderation flow, anonymity) is not described, but that is a minor omission for correct invocation.

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 clarifies the enum values for target_type (especially 'ding' as an entry under Lending & Giving) and reiterates the contact email behavior already in the schema. However, target_id (an integer) remains completely undocumented in both schema and description, leaving a notable gap at 50% schema coverage.

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 ('melden') and resource ('rechtswidrigen Inhalt') and references the legal basis (Art. 16 DSA). It also enumerates the valid target types, making it unmistakable what the tool does and how it differs from all siblings (none of which are reporting tools).

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 purpose implies when to use it (to report illegal content), but there is no explicit guidance on when not to use it or on alternatives. A sibling like 'contact_provider' could appear related, yet the description does not clarify the boundary between reporting content and contacting a provider.

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 this as a read-only, non-destructive, non-open-world tool. The description adds meaningful behavioral context: results exclude contact data, radius results include distance_km and are distance-sorted, and shared requests appear once.

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 purpose is front-loaded and topics are ordered, but the description is a dense semicolon-separated block. Clauses about parameters absent from the schema reduce efficiency and add noise.

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 does useful work by explaining privacy, distance sorting, group result shape, and heating-oil units. It still leaves gaps around max_results and creates confusion by describing filter parameters the agent cannot pass.

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?

Adds useful semantics beyond the schema for location (digits as PLZ prefix vs city name) and radius_km (requires a 5-digit PLZ, results include distance). However, max_results is undocumented, and the description references filters such as youth_ok, budget_eur, price_type, group_ok, and kind that are not present in the input 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: searching open 'Gesuche' without contact data. The resource distinguishes it from provider search, though it does not explicitly name search_providers as the alternative.

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 clear usage rules for location and radius searches, including the 5-digit PLZ requirement for radius search, and points to join_job for shared requests. It lacks explicit when-not guidance versus search_providers or get_job.

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 a safe read-only, closed-world operation, so the bar is lower; the description still adds real behavior: only activated (freigeschaltete) providers are returned, geo results carry distance_km and are sorted by distance, and the pflegekasse flag is explained in business terms (Entlastungsbetrag, private helpers, Baden-Württemberg).

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?

Short and front-loaded: resource description first, then parameter behavior. Some sentences merge result-shape details with filter semantics, making it slightly dense to parse, but nothing 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?

With no output schema, the description helpfully reveals result fields (Durchschnittsbewertung, distance_km, sorting, pflegekasse marker), which is what an agent needs. The gaps are max_results semantics and any note on empty-result behavior.

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 80%, so baseline is 3; the description goes beyond the schema by explaining what q can be (keyword or PLZ prefix), how near and radius_km combine into a radius search, and what pflegekasse/nur_pflegekasse actually mean commercially. Only max_results is left unexplained in both places.

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?

Opening line names the resource precisely (freigeschaltete Anbieter mit Durchschnittsbewertung) and the tool's action is unambiguous as a search. It does not explicitly contrast itself with siblings like provider_reviews or contact_provider, though the names make the split fairly obvious.

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?

Concrete guidance on the two modes: keyword/PLZ-prefix via q, or radius search via near plus radius_km (1–200), and the result ordering under each mode. It lacks explicit 'use this instead of X' routing to siblings such as contact_provider or provider_reviews.

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 key side effect: the offer is emailed automatically to the client (and to all households in shared jobs), plus the consent gate and the 'no internet links' content rule. It stops short of saying whether offers can be withdrawn or edited afterwards, which matters for a mutation 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?

Three compact sentences with the action front-loaded, followed by delivery behaviour and constraints. No filler, though the 'no internet links' rule sits a little detached at the end.

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 10 parameters, no output schema, but full annotations, the definition covers the essential behaviour: who receives the offer, consent requirement, shared-job specifics. Missing only post-submission behaviour (confirmation, editability), which is a minor 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 coverage is already 90%, so the baseline is 3. The description adds a rule not stated in the schema alone: shared jobs require separate_contracts=true, and it enumerates the core payload (name, contact, price, message) in context.

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 ('Als Anbieter ein Angebot zu einem Gesuch abgeben') and implicitly distinguishes it from create_job/join_job by framing it as the provider-side response to an existing job. An agent knows exactly what action is performed.

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 concrete preconditions: only after explicit user consent, and separate_contracts=true for shared jobs across multiple households. It does not explicitly contrast with sibling tools, but the context is clear enough to select correctly.

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-destructive write in a closed world, so the safety profile is covered. Beyond that, the description adds genuinely useful behavior: the code is single-use ('einmalig') and originates from a completed placement, which the agent needs in order to set expectations. It still says nothing about moderation, publication timing, or what happens with an already-consumed code.

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, and the critical prerequisite (the code) is stated immediately. It is arguably too terse for a review-submission tool, but nothing 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?

With 5 parameters, 3 required, and no output schema, the description covers the gating prerequisite but omits the outcome: whether the review is published immediately, moderated, or tied to the consent flag. An agent can call the tool correctly, but cannot set the user's expectations about what happens next.

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 80%, so the schema already documents most parameters; the baseline is 3. The description adds the code format (XXXX-XXXX) beyond the schema's generic 'Bewertungscode', but stays silent on stars, comment, consent, and reviewer_name, so the added value is limited.

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 action (submitting a review) and names the required artifact (the one-time review code in XXXX-XXXX format), so the agent understands what the tool consumes. It does not, however, differentiate itself from the sibling provider_reviews, which also concerns reviews.

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 rather than stated: the code is described as one the customer received after a placement ('nach einer Vermittlung'), which tells the agent this is a post-transaction, customer-facing action. There is no explicit when-to-use vs. alternative guidance, e.g. how this relates to provider_reviews or what to do if the customer has no code.

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