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

No annotations are provided, so the description carries the full behavioral burden. It discloses important non-obvious behaviors: per-item errors (status: 'error') do not abort the whole request, the 999-item limit, and a request-level error dict for auth/transport/invalid requests. It also references the partner_warehouse semantic caveat. This is strong transparency, though it doesn't mention authentication requirements or rate limits.

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 purpose, then efficiently organized into error handling, Args, and Returns. Each section has a clear job with no redundant prose. The pointer to the schema for the partner_warehouse caveat avoids duplication while preserving important guidance.

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 3-parameter query tool with a nested items array and an output schema available, the description provides all necessary contextual information: input structure, request-level parameter scoping, return format on success and failure, and error resilience behavior. Nothing critical for an agent to call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the description adds value beyond the schema by clarifying that shipment_type and partner_warehouse apply to the entire request ('nicht pro Artikel'), which prevents a common misuse. It also summarizes the items list structure (material number, quantity, optional unit). Much of the parameter detail is repeated from the schema, but the request-level distinction and 999-item limit are genuine additions.

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 opens with a precise verb-plus-resource statement: 'Preis und Verfügbarkeit für bis zu 999 FEGA & Schmitt-Artikel abfragen.' It clearly delimits scope (max 999 items) and distinguishes itself from all sibling tools, none of which perform price/availability lookups. An agent can immediately understand what this tool does and why it exists.

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 provides clear usage context: use it to query price/availability for up to 999 articles, with request-level shipment type and optional warehouse. It does not explicitly name alternative tools or state when-not-to-use, but no sibling tool overlaps with this function, so the implicit guidance is sufficient. Lacks explicit exclusion criteria, hence not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so richly. It reveals that the tool performs two internal HTTP requests, that the 'documents' field is currently always empty, and that for articles with many variants/alternatives/cross-sell entries the completeness of the list is uncertain. These non-obvious limitations help the agent set correct expectations and avoid relying on incomplete data.

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 well-structured: the first sentence states the output content, the second adds caveats about implementation, empty documents, and potential incompleteness. All sentences carry relevant information and there is no filler, although the long list of fields makes it slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists and the description does a good job of listing returned fields and known limitations. However, it lacks a clear definition of the input parameter, and without explicit usage guidance an agent may not know whether to supply a webshop material number, an EAN, or an internal article number. The tool is simple, but the input semantics gap prevents full contextual 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?

The schema has 0% description coverage for the sole parameter, and the description does not compensate. It does not explain what format material_number should take, whether it is an internal article number, EAN, or supplier number, or how it maps to the output fields mentioned such as 'eigene Artikelnummer' or 'Herstellernummer(n)'. This ambiguity could lead to incorrect invocation.

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 opens with a specific verb and resource: 'Artikeldetails aus dem Webshop laden' (load article details from the webshop) and enumerates the exact fields returned, such as EAN, manufacturer numbers, category, own article number, technical attributes, images, cutting costs, and related article numbers. This clearly distinguishes it from sibling tools like web_search_articles or get_price_availability, which focus on searching or pricing rather than full article details.

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 usage context is only implied: the required material_number parameter and the phrase 'Artikeldetails laden' suggest this tool should be used when an agent already has a material number and needs detailed article information. However, there is no explicit statement of when to use this tool versus alternatives like web_search_articles, nor any exclusions or preconditions.

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?

There are no annotations, so the description carries the full behavioral burden. It clearly frames the operation as a read-only query ('abfragen'), explains the scope across warehouse locations, and discloses the empty-list behavior for specific cases. It does not cover invalid material numbers or authentication requirements, but for a simple lookup these are minor.

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 concise, front-loaded sentences. The first states the main operation and scope, and the second adds useful edge-case behavior without any 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 one-parameter read-only lookup with an output schema present, the description covers the purpose, scope, and empty-result semantics. Nothing essential for selecting or invoking the 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?

With 0% schema description coverage, the description partially compensates by tying the input to 'eines Kabelartikels', making it clear that the material_number identifies a cable article. The input schema already defines the parameter as a required string, and the sole parameter is self-explanatory enough that this level of semantic context is adequate.

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 precise action and resource: 'abfragen' of 'verfügbare Kabellängen ... eines Kabelartikels über alle Lagerstandorte'. It clearly distinguishes this tool from siblings because it is the only one focused on cable lengths.

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 context: this tool queries cable lengths across all warehouse locations. It also explicitly mentions when the result will be empty (non-drum articles or global out-of-stock), which helps the agent know when not to expect data. It does not name an alternative tool, 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?

There are no annotations, so the description carries the burden. 'Abrufen' indicates a read-only retrieval, and 'keine Preise' discloses a key output limitation. It does not discuss auth or side effects, but for a simple GET-like cart read this is reasonably transparent.

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?

One compact sentence with no filler. It front-loads the action and resource, and the parenthetical adds essential constraints efficiently.

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 one-parameter read tool with an output schema, the description covers what is retrieved, the quantity semantics, and the no-prices limitation, while the schema covers the active-cart behavior. 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?

The single optional cart_id parameter is already fully described in the schema, including the null/default behavior. The description adds no parameter-level meaning beyond what the schema provides, so the high-coverage 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?

The description uses a specific verb ('abrufen') and a clear resource ('Inhalt eines Warenkorbs'), then narrows the scope with 'Positionen mit Menge, keine Preise'. This differentiates it from sibling tools like web_get_cart_list and price-related 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?

It provides clear context: use this tool to retrieve cart contents with quantities, not prices. The schema adds that omitting cart_id targets the currently active cart. It does not explicitly name sibling alternatives, but the 'keine Preise' note signals a relevant exclusion.

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

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

With no annotations, the description carries the full burden. It communicates that this is a read/list operation returning all carts including the active one, which is useful. However, it does not disclose whether authentication/session context is required, how cart ordering works, or whether any implicit filtering applies beyond 'customer.'

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 entire description is one compact, front-loaded sentence: the action and resource come first, followed by output details and the active-cart distinction. There is no filler or redundant explanation.

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 zero-parameter read/list tool with an output schema, the description covers what the tool returns and its key distinguishing scope: all customer carts including the active one. It could add an explicit contrast with web_get_cart, but nothing essential is missing for an agent to invoke it 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?

There are zero parameters and schema coverage is 100%, so there is nothing for the description to clarify about parameters. The baseline for a zero-parameter tool applies, and omitting parameter details 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?

The description names a specific action ('auflisten') and resource ('alle Warenkörbe des Kunden'), plus the return fields (ID + Name) and the active-cart inclusion. The plural 'Warenkörbe' clearly separates it from the sibling web_get_cart without needing to open schemas.

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 implies the tool is for enumerating all customer carts and explicitly notes the active cart is included. However, it never says when to prefer this over the sibling web_get_cart or web_get_order_list, and offers no exclusions, so the agent must infer the use case from the name.

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

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

With no annotations, the description must disclose behavior itself. It usefully states that an empty response is expected and not an error, which prevents an agent from misreading a valid outcome as failure. No side effects or auth details are relevant for a zero-parameter read 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?

Two short German sentences: the first states the action, the second adds the essential non-obvious behavior. There is no repetition or 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 parameterless retrieval tool with an output schema, the description covers the key ambiguity (empty results are valid). It could be more complete by naming sibling alternatives, but that gap is minor because the tool is otherwise simple to invoke.

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 confirms this, so there is no semantic burden for the description to carry. The baseline for 0-parameter tools is 4.

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 uses a specific verb ('abrufen') and resource ('Tagesangebote'), clearly identifying what the tool returns. However, it does not differentiate from sibling tools like web_get_deal_campaigns or web_get_deal_articles, which could plausibly overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to choose this tool over the deal-related siblings. The only usage context is that an empty result is legitimate, which helps interpretation but not tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'abrufen' implies a read-only operation, and the workflow reference adds context. However, it does not explicitly state side-effect-free behavior, auth requirements, or empty/error cases, which would be more transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and object, with a concise parenthetical giving the critical dependency. Every word earns its place; 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 one-parameter tool with an output schema, the description adequately covers the resource, the parameter source, and the workflow. It omits pagination or limit details, but those are not essential for this simple retrieval 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?

With schema description coverage at 0%, the description compensates by telling the agent that campaign_id comes from web_get_deal_campaigns. This adds essential meaning beyond the bare string type, although it does not describe format or validation.

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 uses a specific verb ('abrufen') and a specific resource ('Artikel einer einzelnen Aktionsangebote-Kampagne'), clearly indicating this tool retrieves articles for one promotional campaign. It distinguishes itself from siblings like web_get_deal_campaigns (campaign list), web_get_article (single article), and web_search_articles (search).

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 parenthetical 'campaign_id aus web_get_deal_campaigns' explicitly points the agent to the upstream tool for obtaining the required parameter, establishing a clear usage workflow. It does not explicitly state when not to use this tool or name alternatives, but the context is sufficient for correct routing.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that the tool lists only active campaigns and returns only ID and title, which sets expectations about scope. It does not mention read-only status, but 'auflisten' implies a non-mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core purpose, the second states the limitation and the alternative. Every word earns its place, and the key distinction is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with an output schema, the description is complete: it covers purpose, scope, return contents, and sibling routing. Nothing needed 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?

The tool has zero parameters, so there is no parameter semantics to document. The baseline for 0 params is 4, and the description adds no unnecessary parameter information.

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 ('auflisten') and resource ('Aktive Aktionsangebote-Kampagnen'), and explicitly limits the output to campaign ID and title. It differentiates from the sibling tool web_get_deal_articles by declaring what it does not return.

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 explicitly says the tool only returns campaigns, not articles, and directs the agent to web_get_deal_articles when articles are needed. This makes the boundary between the two tools explicit and actionable.

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

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

No annotations are provided, so the description carries the transparency burden. It signals a read-only retrieval operation via 'abrufen' and scopes it to the customer account, but it does not disclose authentication requirements, behavior for an empty or missing favorites list, or explicitly confirm there are no side effects. For a simple getter with an output schema, this is adequate but not detailed.

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, compact German sentence with no filler. The key object and scope are front-loaded, making it easy for an agent to parse quickly.

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 zero parameters, the presence of an output schema, and the clear one-sentence purpose, the description is largely complete. It could add a note on when to choose this over web_get_cart_list or web_get_order_list, but that is not essential for a no-argument favorites retrieval 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?

The tool has zero parameters, so the empty schema is fully self-explanatory and description coverage is vacuously 100%. No parameter-level documentation is necessary, and the description correctly adds no misleading parameter detail.

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 uses the specific verb 'abrufen' and identifies a clear resource, 'die im Webshop-Kundenkonto gespeicherte Favoritenliste' (the favorites list stored in the webshop customer account). This distinguishes it from siblings such as web_get_cart_list, web_get_order_list, and web_search_articles.

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 context is implied: call this when the agent needs the customer's saved favorites list. The description does not explicitly contrast it with alternatives or state when not to use it, but the scoping to 'Webshop-Kundenkonto' gives reasonable contextual guidance for a simple no-parameter getter.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It does state what is retrieved and the quantity semantics, but it does not disclose anything about authentication requirements, error behavior, or whether the operation is read-only beyond the verb 'abrufen'.

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 compact sentence that front-loads the action and resource, with a parenthetical clarifying the returned quantities. Every word earns its place; there is no redundancy or 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 simple single-parameter read tool with an output schema, the description is largely sufficient: it identifies the exact resource and the key data returned. It could be slightly stronger by explicitly noting that it retrieves data for one order rather than a list, but the phrase 'einer einzelnen Bestellung' already conveys this.

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%, and the only parameter is order_number. The description implies that this parameter identifies the single order whose positions are returned, adding some context beyond the bare schema, but it does not elaborate on format or required value semantics.

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 uses a specific verb ('abrufen') and a clear resource ('Positionen einer einzelnen Bestellung'), and clarifies the returned data as ordered/delivered quantity per article. It clearly distinguishes from the sibling web_get_order_list, which is about orders rather than individual order positions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes it clear this tool is for retrieving line items of one specific order, so an agent can infer it should be used when an order number is known. However, it does not explicitly mention when not to use it or point to a sibling alternative such as web_get_order_list for listing orders.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose a meaningful quirk: status is best-effort and only reliable for one observed status type, otherwise null. However, it omits other behavioral aspects like list scope, pagination, or explicit read-only guarantees, so transparency is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences: the first declares the purpose and output fields, the second adds a critical reliability caveat. It is front-loaded, contains no filler, and every clause contributes meaningful 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 list tool, the description covers the core function and includes an important data-quality caveat. An output schema exists to define return values, so the description need not enumerate them. It could be more explicit about whether the overview covers all orders or a limited set, but the essential context 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?

The input schema has zero parameters and 100% schema description coverage, so there are no parameter details to clarify. A zero-parameter tool warrants the baseline 4 since the description appropriately focuses on the result and the status caveat instead.

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 ('Bestellübersicht abrufen' – retrieve order overview) and lists the included fields: order number, item, date, status. It is unambiguous and the 'Übersicht' framing implies a list view distinct from the sibling web_get_order, though it does not explicitly name that 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?

No guidance is given about when to use this tool versus alternatives such as web_get_order, web_get_cart, or the other list tools. The description only defines what the tool does, leaving the agent to infer selection from the tool name and context, which is insufficient.

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

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

No annotations are provided, so the description carries the burden of indicating behavior. The verb 'abrufen' and the tool name imply a read-only retrieval operation, and the description adds the scope 'reduzierte Ware'. However, it does not explicitly address side effects, permissions, or the effect of omitting deal_id beyond what the schema already says.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the resource, the action, and clarifying examples without any wasted words. It earns its place and is easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter and an output schema, so the core invocation is adequately covered. However, the description is missing sibling differentiation and usage context, which matters because several deal-related tools exist in the sibling list.

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 the deal_id parameter is already well described in the schema ('Opaque Kampagnen-ID', omit for standard default). The tool description adds no additional parameter meaning, so the baseline score 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?

The description states a clear verb ('abrufen') and a specific resource ('2. Wahl'/B-Ware-Artikel), and clarifies the meaning with examples like Retouren/Restposten. It does not explicitly contrast with similar siblings such as web_get_deal_articles or web_get_daily_deals, so 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?

The description explains what the tool retrieves but gives no guidance on when to choose it over alternatives like web_get_deal_articles or web_get_daily_deals. There are no conditions, prerequisites, or exclusions provided.

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

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

With no annotations, the description carries the full burden and does a good job: it explicitly discloses a key limitation—completeness/pagination for very large categories is unclear, and only the first response is returned. This is valuable behavioral context beyond a simple list operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. The purpose is front-loaded, and the critical caveat follows immediately. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is an output schema, the description need not explain return values. It covers what the tool does and the main behavioral caveat. It could be slightly more complete by mentioning an alternative for full coverage, but for a simple listing tool with one parameter it is sufficiently complete.

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 input schema provides no description for category_id (0% coverage), but the description compensates by defining it as a UWG category and giving a concrete example ('UWG_14_87'). This gives the agent meaningful guidance on the expected value format.

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: 'Artikel einer FEGA & Schmitt-Warengruppe auflisten' (list articles of a merchandise group), with an example category format. This clearly distinguishes it from sibling tools like web_get_article (single article) or web_search_articles (search-based).

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 implies when to use the tool—when you need articles by UWG category—and clarifies its scope. However, it does not explicitly mention alternatives or state when not to use it, leaving the agent to infer the choice compared to 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?

Since no annotations are provided, the description carries the full transparency burden. It discloses the key behavioral limitation: the tool returns only result tiles (article number, description, preview image, detail URL) and not prices or availability. It does not mention pagination or result limits, but the core behavior is clearly communicated.

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 compact and efficient: two sentences cover the purpose, accepted query types, output limitations, and the alternative tool. Every sentence adds value, and the core scoping information is front-loaded.

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 single-parameter search tool with an output schema, the description is largely complete: it explains what the query can contain, what the results look like, and when to use another tool. It falls slightly short of a 5 because it does not mention pagination, result limits, or empty-result behavior, though these are minor given the tool's simplicity.

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 input schema defines only a generic query string with 0% description coverage, so the description is essential. It fully explains the semantics of the query parameter by listing the four accepted input forms: article number, EAN, manufacturer part number, and free 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 opens with a specific verb and resource: searching articles in the webshop by article number, EAN, manufacturer part number, or free text. It also distinguishes the tool from get_price_availability by explicitly stating that it does not return prices or availability.

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 clearly states when to use this tool: searching for articles via identifiers or free text. It also names get_price_availability as the alternative for price and availability data, giving the agent direct routing guidance without ambiguity.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals the exact success response, the non-transactional nature of the operation, and importantly that the new value is not confirmed in the response—an easily missed behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two focused sentences: the first states the purpose and scope, the second provides response behavior and verification guidance. No filler or redundant restating of the tool name.

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 setter, this is complete: it explains what happens, what the response is, what is not confirmed, and how to verify. Authentication and error details are not essential for the agent to use 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 0%, but the description and parameter names together convey the mapping: material_number identifies the article, and own_article_number is the customer-specific label. It could add format or constraint details, but it gives enough meaning for correct invocation.

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: setting a customer-specific article number for an article in the webshop. It also distinguishes the operation from an order or booking, making its purpose unmistakable even among 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?

It explicitly says this is only labeling in the customer account and not an order/booking, which is a clear when-not. It also recommends verifying with web_get_article because the webshop does not confirm the value, naming a concrete alternative workflow.

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