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

No annotations are provided, so the description carries the behavioral burden. It conveys a non-mutating status check ('Return whether'), implying no side effects, but does not specify what 'usable' means, whether it involves network access, or what happens on failure. Basic behavior is disclosed, but richer context is missing.

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

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

A single, compact sentence that immediately tells the agent what the tool does. No filler or redundancy; it earns its place entirely.

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 has no parameters and has an output schema, so the description's job is mostly to state purpose. It does that clearly. The only missing piece is usage context, but the dimensions cover that and the tool is simple enough that the description is nearly 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 tool has zero parameters, and the schema is trivially covered at 100%. With no parameters to explain, the description adds all necessary semantics by simply stating the intent.

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

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

The description states a specific action and resource: it returns whether a usable local Mercadona session is available. This clearly distinguishes it from the product and cart sibling tools, which focus on different operations.

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 guidance on when to use this tool versus the siblings or other actions. An agent must infer that a session check is a prerequisite for authenticated operations; the description provides no explicit when-to-use or when-not-to-use direction.

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 explicitly discloses that this operation reads without changing anything, which is the key side-effect guarantee an agent needs. It does not mention edge cases like an empty cart or unauthenticated state, but for a simple getter the essential behavioral trait is well covered.

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 zero filler. Every word earns its place: it states the action, the resource, the authentication context, and the non-mutating guarantee. This is exemplary conciseness without sacrificing content.

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

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

Given the tool's low complexity (no parameters, output schema present), the description is nearly complete. It covers purpose, target resource, authentication context, and read-only behavior. It could marginally improve by pointing to auth_status for authentication failures or update_cart for modifications, but nothing essential is missing for a correct basic invocation.

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

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

The tool has zero parameters, and the schema coverage is 100% by vacuity. The baseline for 0-parameter tools is 4, and the description needs to clarify no arguments or input requirements, which it effectively does by needing none. No additional parameter semantics are required.

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

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

The description names a specific verb ('Read'), a specific resource ('the current authenticated Mercadona cart'), and explicitly states 'without changing it', which distinguishes it from the sibling update_cart. There is no ambiguity about what this tool does.

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 use case: retrieving the current cart state read-only. However, it never explicitly names sibling tools or conditions, such as using update_cart when modification is needed or auth_status to verify authentication. Usage context is clear but exclusion/alternative guidance is only implicit.

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 disclose behavior. It only mentions 'normalized details' and 'opaque warehouse code', but does not state whether the operation is read-only, what happens if the product is not found, authentication requirements, or error handling. This is a significant gap for a 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?

The description is a single, front-loaded sentence with no wasted words. It communicates the action and resource immediately and the 'opaque warehouse code' adds necessary context without verbosity.

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?

Though an output schema exists, the description lacks essential behavioral context: no mention of read-only nature, error cases (e.g., product not found), or prerequisites like authentication. For a tool with no annotations, this is incomplete and could lead to misuse.

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 add meaning to parameters. It explains that the warehouse parameter is an 'opaque code', which is helpful, but does not clarify the format or constraints for product_id beyond the obvious. It partially compensates but leaves ambiguity.

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 ('Get') and resource ('one product'), and clarifies the output is 'normalized details'. It also notes the warehouse parameter is an 'opaque code', which distinguishes this from search or batch operations and makes the tool's scope explicit.

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 explicit guidance on when to use this tool versus siblings like search_products or search_products_batch. The phrase 'for one product' implies exact ID lookup, but it does not state that search tools are for finding products, nor any conditions for preferring this tool.

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. It does disclose one meaningful constraint ('never traverses the complete catalogue as a fallback'), which tells an agent not to expect exhaustive results. However, it says nothing about authorization (a sibling auth_status exists), result behavior on no matches, or rate limits, leaving notable gaps for a 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?

The description is tight and efficient, about four short sentences, and front-loads the critical constraint ('Search one concise Spanish product phrase; never send a full instruction') before any examples. Every sentence earns its place, with only minor redundancy in the example phrases.

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?

Although an output schema exists (so return values need not be described), the description leaves two of three parameters (warehouse, limit) entirely unexplained and omits any authorization context despite the auth_status sibling. For a search tool with zero annotation coverage, this is adequate but not 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?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains the query parameter format ('concise Spanish product phrase', product nouns, constraint examples like 'pepino holandés'), but it says nothing about the warehouse parameter or the limit parameter, which remain undocumented in both schema and description. It compensates for query 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?

The description states a specific action (search) on a specific resource (products) with a precise constraint: the query must be a concise Spanish product phrase. It clearly differentiates itself from the sibling search_products_batch by limiting itself to a single product phrase, so an agent can tell the tools apart without opening either 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?

Usage guidance is explicit: never send a full instruction, use product nouns with constraints (with concrete examples), route to search_products_batch for multiple products, and try several plausible Spanish phrases for conceptual requests. The sibling alternative and the condition selecting it are named directly.

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 discloses concurrency, independence, per-query failure isolation, and the need to inspect candidates before choosing an ID. It does not discuss authentication, rate limits, or read-only guarantees, but the search semantics and failure isolation are well beyond what the schema alone would tell an agent.

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 front-loaded: the main purpose appears in the first sentence, followed by focused operational guidance. Every sentence earns its place, with no redundant or vague 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?

The description provides enough operational context for correct batch invocation, especially around per-query key preservation and failure isolation. Since an output schema exists, the description does not need to define return values. The only meaningful gaps are the unelaborated warehouse parameter and the lack of an explicit 'use search_products for a single query' routing note.

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 explains the semantics of queries, key, and query phrase construction. However, the required warehouse parameter is never explained in the description, and limit behavior is only covered by the schema defaults. Compensation is therefore partial.

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: 'Search several concise Spanish product phrases concurrently and independently.' This clearly differentiates it from sibling search_products by emphasizing batch, concurrent search. It also adds purpose detail by telling the agent to inspect candidates before selecting a product ID.

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

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

The description gives concrete usage rules: one query per product/product family, preserve caller keys, do not submit an entire shopping instruction as a single query, and treat failures per query without discarding successes. It does not explicitly name the single-query sibling search_products as the alternative, but the batch/concurrent framing makes the intended context clear.

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

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

Annotations already flag the tool as destructive, so the description adds value by specifying what is destructive: the quantities are set to exact final values, not adjusted by deltas. It also communicates the need for explicit user authorization before invocation. It does not detail edge cases like item removal at quantity 0, but the core behavioral risk is disclosed.

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 sentence with no filler and the most important operational constraint (user confirmation) included. Every word earns its place.

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

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

For a destructive, 3-required-parameter mutation, this is too thin: the version-check parameter and operation_id are critical for safe invocation and are left to inference from their titles. The output schema relieves return-value documentation, but the description should still explain the concurrency precondition and how items map to final cart state.

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 description only weakly maps to the 'quantity' field via 'quantities.' The required 'expected_cart_version' and 'operation_id' parameters are completely unexplained, leaving the agent without guidance on concurrency or idempotency 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 names a specific action ('Set exact final quantities') and a clear resource context (cart items), which distinguishes it from sibling read/search tools like get_cart/get_product. The 'exact final' wording also signals overwrite semantics rather than an incremental update.

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 an explicit precondition: only call 'after the host obtains explicit user confirmation,' which tells the agent when it is allowed to act. It does not name specific sibling alternatives, but no sibling performs cart mutation, so the confirmation gate is the main routing guidance.

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