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

With no annotations, the description carries the full burden, and it does disclose one important non-obvious behavior: adding a duplicate article increments quantity rather than erroring. That is genuinely valuable. It still omits permission/auth needs, what happens when no market is supplied (schema shows market is nullable/default null), and what the call returns.

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 with no filler; the core action and its target lead, with the delivery and duplicate-quantity details following. Slightly fragmented formatting (the delivery line dangles without a lead-in) but efficient overall.

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?

An output schema exists, so return values need not be explained, and the quantity accumulation note covers the main side effect. But for a mutation tool with zero annotations and 0% schema coverage, the missing market-parameter semantics and any auth/prerequisite context leave a real gap.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate. It does explain the 'delivery' enum values and the sku's origin, but says nothing about the 'market' parameter (nullable, default null) and only implies quantity's accumulation behavior. Two of four parameters remain effectively undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource (add an article to the basket of a market) and even names the upstream tool that supplies the sku, so the agent knows the precondition. It doesn't explicitly contrast with siblings like set_quantity or remove_from_basket, but the write-direction is unambiguous from the verb.

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 delivery sentence implies when each mode applies ('pickup' reserve-and-collect vs 'delivery' parcel), which is useful selection guidance. However there is no explicit routing against siblings such as set_quantity (for changing an existing line) or view_basket, and no stated prerequisites beyond the sku source.

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 behavioral burden. It never says whether clearing is reversible/undoable, what happens if the basket is empty, or whether this affects a shared or per-market basket — all essential for a destructive bulk mutation.

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 short, front-loaded sentence with no filler. It earns its place, though the trailing 'of a market' adds ambiguity rather than precision.

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?

An output schema exists so return values need not be described, but for a destructive bulk-clear operation with zero annotations and an undocumented optional parameter, the description leaves major gaps an agent needs to invoke it 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?

The single 'market' parameter has 0% schema description coverage and defaults to null, but the description never explains what the parameter means or what the null default does (e.g. current/default market). The only hint is the vague phrase 'of a market'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource: removing everything from the basket. The word 'everything' implicitly distinguishes it from remove_from_basket, though the sibling is never named and the awkward phrasing 'basket of a market' slightly muddies the object.

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

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

No when-to-use guidance at all. With siblings like view_basket, remove_from_basket, and add_to_basket, the agent has to infer that clearing an entire basket is the destructive bulk alternative to removing single items.

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 behavioral burden and does add real context: dimensions are numbers 'taken from what toom states', a missing dimension is absent (not zero), and stock reflects the selected market plus every market in `also_check`. It doesn't cover permissions or error behavior, but for a read-only comparison it is substantively informative.

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?

Leads with the action and scope, then explains the `characteristics` output and the dimension/stock rules. Every sentence carries information, though the middle clause about `characteristics` is slightly dense and could be tightened.

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?

An output schema exists so return values need not be fully spelled out, yet the description still usefully frames how dimensions and stock are derived. Combined with the coverage of the two optional params, an agent has enough to invoke correctly, missing only SKU format detail.

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 compensate. It clarifies `market` (the selected market governing stock) and `also_check` (additional markets whose stock is returned), and stresses the 2-6 article range for `skus`, but gives no format or syntax for the SKU strings themselves. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (compare) and resource (articles) with explicit scope ('2 to 6 articles side by side') and enumerates the comparison axes (price, brand, dimensions, stock, characteristics). This clearly distinguishes it from the sibling compare_markets and from single-article tools like get_article.

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 '2 to 6' constraint implicitly tells the agent the required cardinality, and the emphasis on 'side by side' implies use when a comparative view is needed. However, it never explicitly states when to pick this over get_article or compare_markets, leaving selection to inference.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses non-mutation ('without touching any basket'), that the underlying toom stock endpoint is queried, that quantities are capped at the requested amount, and that markets are ordered complete-before-partial and best-first.

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?

Front-loaded purpose sentence followed by tight, scannable paragraphs for defaults, article source, and result ordering. Some lines are telegraphic and fragmentary (code-formatted terms in prose), slightly reducing readability.

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

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

An output schema exists, so return values need not be spelled out, yet the description usefully adds the result ordering rule. Together with the documented input defaults, an agent has enough to invoke it correctly; only sibling differentiation is missing.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it documents the `items` shape with a literal example ({"sku": "...", "quantity": 2}), the `markets` default source, and the `from_market` fallback semantics. Left without any type/format note for `markets` entries themselves.

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 ('check articles against several markets') plus a key scope constraint ('without touching any basket'). However, it never differentiates itself from the sibling compare_articles, so an agent has to guess which of the two comparison tools fits a given request.

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 operational context: markets defaults to T00MY_HOME_MARKETS, and articles fall back to the from_market/current-market basket when `items` is omitted. It does not name an alternative tool or state when-not-to-use, so it stops short of explicit 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?

With no annotations, the description carries the full burden and does real work: it states the source basket is untouched, that the target is emptied when replace=True (making the call idempotent and avoiding double quantities), and that a per-article report is produced with availability, quantities, and price changes. The only gap is that it does not explain the meaning of a null from_market or an empty to_market.

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?

Front-loaded with the core action, then behavior, then the replace caveat. Every sentence adds information and none is redundant padding.

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?

An output schema exists, so return values need not be spelled out, and the description covers mutation semantics and side effects well. It is slightly incomplete on the two market parameters' defaults, which matters given 0% schema coverage.

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 compensate. It fully explains replace (True empties, False adds) but leaves to_market and from_market semantics – including their defaults and what a null from_market implies – to inference, so only one of three parameters is meaningfully documented.

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 gives a specific verb+resource+scope: copying one market's basket into a new basket in a different market. This distinguishes it cleanly from siblings like add_to_basket, clear_basket, and view_basket without needing to open any 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?

It frames the use case ('a market switch means building a new basket there') and clarifies the replace behavior, so an agent knows when this is appropriate. It does not explicitly name alternative tools or state when NOT to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that a throwaway anonymous basket is created, that real baskets are untouched, and that nothing is ordered or reserved — the critical side-effect profile for a tool that touches a basket-like resource. It stops short of stating whether this is safe to call repeatedly, any rate limits, or how 'short-lived' the session is.

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 rhetorical opener is front-loaded and the second sentence delivers the key safety disclosure immediately, so the important points come first. The prose is slightly chatty but each sentence carries either scope or behavior, so it earns most of its length.

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?

An output schema exists, so return values need not be described, and the behavioral side effects are covered. The gap is parameter documentation: an agent knows what the tool returns but not what to pass for sku/market/quantity, leaving it under-specified for 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?

Schema description coverage is 0% across three parameters (sku, market, quantity), so the description must compensate and does not: none of the three are explained, nor is the sku format or whether market defaults to a stored market (set_market exists as a sibling). The only indirect hint is that quantity affects the free-shipping threshold, which is not made explicit.

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 comparison output ('costs, lead times and stock for both, side by side') for the pickup-vs-delivery decision, which is more precise than the bare name 'delivery_info'. It does not, however, name or exclude the nearby siblings that look like they could overlap (plan_pickup, compare_markets, market_info), so an agent still has to infer the boundary.

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 by the opening question ('Pick up or have it delivered?'), so the agent can infer this is for a delivery-vs-pickup cost decision. There is no explicit when-to-use, when-not-to-use, or routing to an alternative sibling such as plan_pickup, which leaves the selection ambiguous.

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 fully carries the burden and does so well: it discloses the destructive side effect on the user's browser (importing REPLACES existing toom.de cookies, including basket/market choice), the security profile (anonymous token, no login, keep private), and the no-op-without-confirm behavior. This is exactly the behavioral context annotations would otherwise 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?

Purpose is front-loaded in the first sentence, followed by security and confirmation guidance. It is slightly verbose with parenthetical asides (cookie-manager example, 'no login, but still a token'), but every sentence carries actionable information rather than filler.

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

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

Output schema exists, so return values need no explanation. The description covers the mutation's side effects, privacy constraints, and the confirmation gate, which is everything an agent needs to invoke this safely. Nothing material 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%, so the description must compensate. It explains 'confirm' thoroughly (default false = nothing written; must be true after user agreement), but 'market' is only implied by 'a market's basket' and never explicitly described as selecting which market's session. Strong on one parameter, partial on the other.

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 (write/export) applied to a specific resource (the session cookies of a market's basket) and gives the intent ('to look at that basket in your own browser'), which implicitly separates it from view_basket. An agent can tell what this does 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?

It gives an explicit precondition ('Ask the user first') and a precise two-step workflow: without confirm=True nothing is written, call again with confirm=True only after explicit agreement. It does not name alternative siblings (e.g. view_basket) for in-server inspection, so it stops short of a full when/when-not 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, the description carries the full burden and does well: it discloses that stock is live and can change, that markets are queried one request each, that results are returned nearest first, and that nothing is reserved or added to a basket. It stops short of covering auth or rate-limit details.

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

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

The definition is front-loaded with the core question before the operational details, and each sentence carries useful content (scope, input formats, completeness flags, live-stock caveat). It is somewhat wordy but well structured and without 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 six-parameter tool with no annotations, the description covers inputs, nearest-first ordering, completeness flags, and live-stock caveats, and an output schema exists so return format need not be explained. Only auth/rate-limit context 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?

Despite 0% schema description coverage, the description actually documents all six parameters: `sku`+`quantity` or `items` (with an inline example format), `near`, `radius_km`, and `max_markets`. This adds substantial meaning beyond the bare schema, though units/semantics for radius_km rely on the parameter name.

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 opening question states a specific verb (find/pick up) and resource (an article) with clear scope (markets within a radius right now). It is readily distinguishable from siblings like find_markets or search_products, since the purpose is checking live stock of a specific article at nearby markets.

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 usage context (checking where an article can be picked up right now) and notes `near` is understood as in markets_nearby, but it never states when to use this tool versus alternatives like find_markets or search_products. Usage is implied rather than explicitly routed.

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 must carry behavioral context. 'Find' strongly implies a read-only search, but it does not disclose pagination behavior, permission requirements, or how limit/multiple-match results are handled.

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 with no wasted words. The lookup fields are introduced immediately after the verb and resource.

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 handles return values, and the description covers the core query semantics for a simple lookup tool. However, it omits limit semantics and does not help the agent differentiate this tool from nearby-market or market-info siblings.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully documents the meaning of the required query parameter by listing searchable fields, but it says nothing about the limit parameter beyond the schema default.

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 (find) and resource (markets), and enumerates the accepted lookup keys. It does not explicitly distinguish itself from siblings such as markets_nearby or market_info, so it falls short of a 5.

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

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

It lists possible query inputs but gives no when-to-use guidance, no conditions for choosing it over markets_nearby or market_info, and no exclusions. Usage is only implied.

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 behavioral burden and does so well: it discloses the trivalent return semantics (true only if it fits under every possible unknown, false only if it can never fit, otherwise null/'unklar'), states that unstated dimensions are never guessed, and specifies which dimensions are measured (door leaf, excluding frame/packaging). The main omission is any note on required authorization or market scoping.

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?

Purpose is front-loaded in the first clause, followed by the interpretive rules an agent actually needs. Sentences are dense but each carries a distinct rule (axis treatment, trivalent logic, dimension convention, margin/weight). Framing headers like 'Give the free space in cm' add slight verbosity without much cost.

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?

An output schema exists, yet the description still explains the return semantics (fits tri-state plus weight), which is genuinely helpful rather than redundant. Together with the dimension conventions and depth-axis rule, the definition is nearly complete for invocation; only allow_rotation and market scoping remain unexplained.

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% across 6 parameters, so the description must compensate and only partially does: it establishes the cm unit for all dimension inputs, explains that omitting max_depth_cm treats that axis as unlimited, and clarifies which physical dimensions of the article are meant. However, allow_rotation (which materially changes fit results and defaults to true) and market are never addressed.

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 combination — determining whether an article (identified by SKU) fits a given space — and illustrates the resource with concrete contexts (car load area, doorway, shelf). No sibling tool (search_products, compare_articles, find_article_nearby, delivery_info) overlaps this purpose, so an agent can route unambiguously.

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 opening parenthetical supplies clear usage contexts (car's load area, doorway, shelf), and the instruction to 'leave margin' plus the note that weight is returned 'for your own judgement' tells the agent how to act on the result. There is no explicit when-not guidance or named alternative, but for a single-purpose geometric check this is adequate context.

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 behavioral burden. It explains that `stock` is the available quantity capped at `quantity`, how `also_check` extends the stock check across markets, and how `availability` decodes toom's code. It also states 'Nothing is added to a basket', signaling no side effects. It does not cover authentication requirements or rate limits, but for a read-oriented tool this is substantial disclosure.

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 tool's purpose and proceeds logically through returned fields, stock semantics, and the no-basket disclaimer. Every sentence contributes, though the dense middle section could be slightly more scannable.

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 4-parameter read tool with an output schema and no annotations, the description is fairly complete: it explains purpose, return content, stock behavior, and the absence of basket side effects. It lacks error-handling context and format hints for `market`/`also_check`, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It gives meaning to all four parameters: `sku` as the 'toom article number', `market` as the 'selected market', `quantity` as a cap on returned stock, and `also_check` as a list of additional markets. While it does not specify the exact format for market identifiers, it adds meaningful semantics beyond the bare 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: 'Details of one article by its toom article number, plus stock in the market(s).' The scope is clear and an agent can tell it fetches a single product's details. However, it does not explicitly distinguish itself from siblings like search_products or compare_articles, so it falls short of a 5.

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

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

The description implies usage by requiring a specific article number, and clarifies 'Nothing is added to a basket', which helps an agent avoid mistaking it for a basket mutation. But there is no explicit when-to-use guidance, no mention of alternatives, and no prerequisites (e.g., how to obtain a valid sku or market).

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 carry the full behavioral burden, and it does add real value: the read-only reassurance ('Nothing is added to a basket'), the warning that also_bought is not curated and may include other sizes of the same article, and the role of the same_category marker. It says nothing about authentication, market defaulting, result limits, or whether results are cached — gaps that matter for a 5-param tool with zero annotation coverage.

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?

Front-loaded with the core purpose, then organized by kind label — easy to scan and no filler sentences. Slightly diluted by references to output-side fields (same_category, selling_points), which drift from the tool's own parameters.

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?

An output schema exists, so return-value documentation is not required, yet the description spends words on output markers instead of the undocumented limit/market parameters. For a read tool with no annotations, the behavioral and parameter picture is helpful but incomplete.

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

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

Schema description coverage is 0% across 5 parameters, so the description is the only source of parameter meaning. It explains kind's two values well and clarifies the only_other_categories=True interaction, but sku, limit, and market are left entirely undocumented (market's null default is never explained). Partial compensation, not full.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete resource — accessories and alternatives for a product, mirroring the product page — and enumerates the two result kinds (also_bought vs similar) with what each contains. An agent can tell it apart from write-oriented siblings (add_to_basket, set_quantity) thanks to the 'Nothing is added to a basket' line, though it never explicitly contrasts with search_products or compare_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?

Gives clear context for choosing between kind="also_bought" (real purchase data: screws, foam, fittings) and kind="similar" (same kind of article, other sizes/brands), and explains when only_other_categories=True is relevant. It stops short of an explicit when-not-to-use or alternative-tool route, so it stays just below 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, the description carries the full burden and does add real behavioral context: hours originate from toom's market list, a 00:00-00:00 entry means closed, holidays not entered by toom are simply unknown, and the `has` flags map to specific transport-relevant services. It does not say what happens when the market parameter is omitted, but the data-provenance and edge-case semantics disclosed are substantial.

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 first sentence front-loads the returned fields and the following sentences explain the hours semantics and service flags. It is tight and every sentence adds information, though the parenthetical German service names make 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?

An output schema exists, so the description is not obligated to describe return shape, and it still explains the notable quirks of that data (closed-day encoding, unknown-holiday caveat). The one substantive gap is the undocumented `market` parameter, which an agent must resolve before calling.

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 `market` parameter has 0% schema description coverage and the description never mentions it at all — no indication of accepted form (name, slug, ID), and no explanation of the null default. With low coverage the description is expected to compensate, and here it does not.

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 clearly enumerates what the tool returns for a market visit (open-now status, hours, closed days, services, pickup details), which is specific enough for an agent to know what it does. It does not, however, differentiate itself from siblings whose names suggest overlapping territory, notably delivery_info, plan_pickup and compare_markets, so the boundary is left to inference.

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

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

"Everything useful for a visit" implies the usage context (pre-visit lookup of a single market's status and services), but there is no explicit when-to-use/when-not statement and no routing to alternatives such as markets_nearby or plan_pickup. Usage is implied rather than stated.

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 reasonably well: it discloses that distance is straight-line (not routing), that results are nearest-first, that no geocoder is used, and what happens when the place has no toom market (falls back to a nearby market's postal code or coordinates). Return format and pagination behavior are left to the output schema.

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?

Compact and front-loaded: scope and ordering come first, then the `near` format contract, then the no-geocoder caveat. Only the missing opening verb slightly hurts readability; there is no filler.

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

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

For a read-only, location-based search whose output schema documents the return shape, the description covers scope, ordering rule, accepted input formats, and the fallback case well. The remaining gap is minimal guidance on how this differs from find_markets.

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 compensate. It does a thorough job on `near` (accepts id, name, postal code prefix, name/city words, or "lat,lon" coordinates) and implies the radius semantics of `radius_km`. However, `limit` and the units/behavior of `radius_km` are never addressed, leaving one of three parameters entirely undocumented.

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?

Effectively states the resource and its scope: markets within a given radius, ordered nearest-first by straight-line distance. The opening fragment lacks a verb ("toom markets within a radius"), but the intent is unambiguous. It does not explicitly contrast itself with siblings like find_markets or compare_markets.

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 never says when to pick this over find_markets, nor does it give prerequisites or exclusions. The closest thing to guidance is the explanation of accepted `near` formats, which is input semantics rather than usage 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 present the description carries the full burden and does so well: it discloses that apply=True builds (replaces) baskets in each stop's market ready for reservation, what all_at_primary_market means in the result, that stock is real per market, and how primary/fallback defaults are derived (selected market vs T00MY_HOME_MARKETS). The replace semantics are the key mutation risk and they are stated.

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?

Core purpose is front-loaded in the first sentence, then the algorithm and defaults follow in a logical order. It is dense and somewhat long, but nearly every sentence carries operational information; only the bulky-examples parenthetical is expendable.

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 six-parameter, zero-coverage, no-annotation tool with a mutation path, the description covers the workflow, defaults and result flag in enough depth to invoke correctly. Gaps remain around from_market and the items element format, which an agent must guess from the schema alone.

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

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

Schema description coverage is 0%, so the description must compensate and it only partly does: apply, bulky_skus, primary_market and fallback_markets are explained or have their defaults described. However items is only gestured at ("a list of articles") with no object shape, and from_market is never explained at all, leaving two of six parameters opaque.

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 (plan where to pick up a list of articles / the current basket) and immediately frames the strategy (primary market first, fallbacks second), which cleanly separates it from siblings like find_markets, compare_markets and markets_nearby. An agent can tell what this does 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 clear operational context: priority rules (1/2), when a fallback is eligible (only if small enough to transport without the special vehicle), how to flag bulky items, and how defaults are resolved. It never names an alternative tool or says when NOT to use this, so it falls short of explicit routing guidance.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses that nothing is sent, that the real form is captcha-protected and user-executed, and that no personal data is read or sent. It also enumerates what the tool returns (market stock, product link, phone number, ready-made text), which is unusually rich behavioral 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?

Front-loaded with the single most important fact ('Sends nothing') and organized logically. It is slightly long, with the German product-page label ('Auf Anfrage bestellbar') being marginal, but almost every sentence carries operational meaning.

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?

An output schema exists, so return structure need not be spelled out, and the safety/execution model is fully covered. The remaining gap is undocumented semantics for sku, market, and quantity, which the 0%-coverage schema does not compensate for.

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% across 5 parameters. The description explains two of them meaningfully — needed_by as free text with a concrete example ('Freitag, 16.10.') and note as added to the generated text — but says nothing about sku, market, or quantity.

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 ('prepare') plus the resource and scenario ('asking a market to order an article that is not in stock there'). This cleanly separates it from siblings like add_to_basket (in-stock ordering) or search_products, so an agent can route 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 trigger condition (article not in stock at that market) and explicitly says the tool 'sends nothing' and that the actual request is completed by the user on toom.de. It does not name a sibling alternative explicitly (e.g., add_to_basket when in stock), so it falls just 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?

No annotations provided, so the description carries full burden. It says 'remove' implying mutation and irreversibility, but doesn't state whether removal is permanent, whether it requires confirmation, what happens to the basket total, or whether it fails if the line_id doesn't exist.

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 terse sentence with zero waste. The key identifier and its source are 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 destructive mutation tool with no annotations and 0% schema coverage, the description is too thin. It doesn't cover the undocumented 'market' parameter, failure modes, or the mutation's irreversibility, leaving an agent under-informed.

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

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

Schema description coverage is 0%, so the description should compensate. It partially does by linking line_id to view_basket, but leaves 'market' (the optional parameter with anyOf string/null) completely undocumented in both schema and description.

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 (remove) and resource (basket line), and clarifies the identifier source (line_id from view_basket). Distinguishes adequately from siblings like add_to_basket, set_quantity, and clear_basket, though it doesn't explicitly contrast with clear_basket which also removes items.

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?

Only gives a hint about where the line_id comes from. No explicit when-to-use guidance, no mention of alternatives like clear_basket, add_to_basket to reverse, or set_quantity to modify instead of remove.

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 discloses the return shape (each filter's param and values, range filters expose min/max, price uses min_price/max_price) and explicitly flags that the category tree is not included. It omits auth/permission needs, pagination, or result-size limits, but for a read-only discovery call the coverage is solid.

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?

Front-loads what the tool returns, then the workflow. Efficient overall, though the second paragraph drifts into search_products' filter syntax and price arguments, which is useful routing but not strictly this tool's own description.

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?

An output schema exists so return values need not be spelled out, yet the description still adds the filter-to-search_products handoff and the category-tree exclusion, which the schema cannot express. The main gap is the unexplained 'market' input and lack of any scope/market-variant caveat for a tool with a market parameter.

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 2 parameters, so the description must compensate. It conveys that 'query' is the search term but never explains 'market' (or its null default), and the param/value and min_price/max_price references describe outputs and a sibling's arguments rather than this tool's inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource: it returns the filters available for a search term along with hit counts per value. This is clearly distinct from sibling search_products (which consumes filters) and from find_markets/get_related, so an agent can disambiguate it without opening another 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?

Explicitly says to use it to narrow a broad search down and gives the follow-up workflow (pass results into search_products(filters={param: [value, ...]})). It gives clear context but does not state when NOT to use it or note alternatives such as the category tree, which is excluded.

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 so richly: page-size/hit ceiling, exact-article-number redirect behavior, the meaning of each `availability` value (including the 'Auf Anfrage bestellbar' inquiry flow), AND/OR combination semantics for `filters`, and how `best_rated` discounts low-review items. This is far beyond restating the schema.

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?

Front-loaded with the core scope statement and examples before the per-parameter detail, and most sentences carry concrete information. It is dense and long, with some parenthetical asides that could be trimmed, but little is truly 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?

An output schema exists, so return-value explanation is not required, and the description still describes key hit fields (`on_offer`, `promotion`, `availability`). Given 11 parameters and 0% schema coverage, a few parameters (market, min_price) remain under-specified, keeping it from a 5.

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

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

Schema coverage is 0%, so the description must compensate across 11 parameters. It explains sort (with enum values), offers_only, availability, filters, and min_reviews well, and implies query/brands/max_price via examples, but leaves `market`, `limit` details, and `min_price` largely undefined. Strong but incomplete compensation.

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 (search toom.de products) and scopes it precisely: first result page only, max ~72 hits, capped by `limit`. It is clearly distinguishable from siblings like compare_markets (stock quantities) and search_filters (filter vocabulary), which it explicitly cross-references.

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?

Three worked natural-language examples map intent to parameter combinations, which is excellent guidance for a search tool. It also routes two related needs to siblings (compare_markets for stock quantities, search_filters for filter params/values). It stops short of any explicit when-not-to-use statement, so a 4 rather than 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the selection is a persistent default affecting search and basket, but says nothing about session scoping, what happens to an existing basket, or what occurs if the identifier is invalid or ambiguous.

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 tight sentences with the purpose front-loaded and the accepted input forms second; nothing is wasted. It could still be marginally tighter given how little it covers.

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?

An output schema exists, so return values need not be explained. For a single-parameter mutation with no annotations, however, the description should say more about persistence, error behavior, and prerequisite lookup tools to be fully actionable.

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% – the single 'market' string parameter is completely undocumented in the schema. The description compensates partially by stating that an id, name, or city is accepted, which is real value beyond the schema, but gives no format examples or disambiguation rules for the three accepted forms.

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 ('Select the market') and clarifies the effect: it becomes the default for search and basket. That is enough to distinguish it from a lookup tool like find_markets, though no sibling is named explicitly.

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

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

The description never says when to reach for this tool versus find_markets or market_info, nor does it state prerequisites such as resolving a market first. The intended use is only implied by the word 'default'.

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 behavioral burden, and it discloses very little. It does not say whether a mutation is reversible, what happens when quantity is 0 (does it remove the line?), what permissions are required, or whether the change is idempotent. For a mutation tool with zero annotation coverage this is a notable gap.

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

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

A single, front-loaded sentence with no filler; the verb and target are stated first. It is efficient, though its brevity borders on under-specification rather than true conciseness.

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?

An output schema exists, so return values need no explanation, but the tool is a mutation with no annotations, 0% parameter coverage, and only a hint about line_id sourcing. For a basket-mutating operation the description leaves too much of the calling contract unstated.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for line_id (sourced from view_basket) but says nothing about the semantics of quantity (bounds, zero behavior) and never mentions the 'market' parameter at all. One of three parameters is entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Change') and resource ('quantity of a basket line'), which cleanly separates it from add_to_basket and remove_from_basket. It does not explicitly name a sibling or state scope boundaries, but the operation is unambiguous.

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 '(line_id from view_basket)' implies the agent should call view_basket first to obtain a line_id, which is useful workflow context. However, there is no explicit when-to-use vs. when-not guidance (e.g., that this only adjusts an existing line rather than adding one).

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 behavioral burden. It does describe the shape of the response, but that duplicates the output schema, and it says nothing about whether the operation is read-only, what happens with an empty basket, or whether the market must be selected first.

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

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

A single front-loaded sentence with no filler; the resource comes first and the returned fields follow. It is efficient, though so terse that it omits needed context rather than being optimally structured.

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 covers the return-value question, and the description confirms the basket-content scope, so the core need is met for a simple read tool. However, with no annotations and no parameter documentation, the agent still lacks the behavioral and scoping details required to call it confidently.

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 'market' parameter, which defaults to null. The phrase 'of a market' loosely ties the parameter to the basket's scope but does not explain the expected identifier form or what a null/omitted market means (e.g. current session market).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource (the basket of a market) and its contents (lines with price, pickup/delivery availability, total), which is enough to separate it from the mutating siblings like add_to_basket, set_quantity, remove_from_basket and clear_basket. The read verb itself is only implied by the tool name rather than stated, so it stops short of a fully explicit verb+resource statement.

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

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

There is no when-to-use guidance, no stated prerequisites, and no reference to alternatives such as copy_basket or clear_basket. The agent must infer from the name alone that this is the read/inspect counterpart to the basket-mutation tools.

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