mcp-leclerc-drive

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

Goes well beyond the annotations by disclosing partial-failure behavior ("Un échec n'arrête pas les suivants"), the one exception (a Leclerc Drive block), additive rather than replacing semantics, per-item ordering, and what is returned (each add's result plus the final cart). For a non-idempotent mutation tool this is exactly the operational context an agent needs.

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

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

A single tight sentence carries the batch limit, insertion order, additive semantics, failure policy and return shape with no filler. The most decision-relevant facts (batch, cap, additive) 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?

Covers failure handling, batching and return shape for a non-idempotent mutation with annotations present and no output schema, which is most of what an agent needs. The remaining gap is that it never mentions the store-selection prerequisite implied by the set_store/get_store 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 coverage is 100%, so product_id, quantity, minItems/maxItems and the 30-item cap are already documented in the schema. The description only reinforces ordering and the cap, adding little parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a precise verb+resource pair ("Ajoute plusieurs produits au panier") with the batch semantics and a hard cap (30 au plus) up front. That verb and the "plusieurs" scope distinguish it cleanly from the single-item sibling add_to_cart without having to open 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?

The additive semantics ("chacun en plus de ce qui est déjà au panier") and the batch cap imply when this tool is the right choice for bulk adds. However, it never explicitly says to use add_to_cart for a single item, nor does it state prerequisites such as selecting a store (set_store) before adding.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false; the description reinforces the non-idempotent trait concretely by explaining that additions accumulate onto existing cart contents. It does not mention the per-call ceiling (max 99) or what happens when the cart limit is hit, which the schema only partially covers via the `maximum` constraint.

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

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

Two short sentences, both load-bearing: the first defines the additive behavior, the second routes to the sibling. No restatement of the title or schema.

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

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

For a two-parameter mutation with annotations covering the safety profile, the definition covers the one genuinely ambiguous aspect (delta vs. absolute quantity). The only gap is the absence of an output schema combined with no mention of what is returned (updated cart, line item, confirmation), which would help an agent chain calls to get_cart.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema text: 'quantity' is a delta to add rather than a target value, which the schema's 'Nombre d'unités à ajouter' only implies. The reference to product_id being the `id` field from search_product is supplied by the schema rather than the 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 and resource (adds N units of a product to the cart) and immediately clarifies the semantics: 'en plus de ce qui y est déjà' — additive, not setting. This distinguishes it from update_quantity by name, so an agent can choose 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?

Explicitly names the alternative and the condition that selects it: 'Pour fixer une quantité exacte, utilise update_quantity.' The when-not case (wanting an exact quantity) is stated rather than inferred, which is exactly the routing an agent needs.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value by disclosing the sort order (distance), the returned fields, and the service-type values (drive/relais/livraison). It omits result count, radius, or pagination behavior, which matters for a geo search.

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 covering search criteria, sort order, and the return payload, with the primary purpose front-loaded and zero filler.

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

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

For a one-parameter read tool with no output schema, the description adequately covers inputs and enumerates the returned fields. The remaining gap is operational: no indication of how many stores come back or the search radius, which an agent might need to reason about 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 description coverage is 100% and the single parameter already documents 'Code postal ou ville' with examples. The description restates the same meaning ('code postal ou une ville') without adding format, validation, or fallback behavior, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('Recherche les drives E.Leclerc') plus the scope ('proches d'un code postal ou d'une ville, triés par distance'), which is enough to distinguish it from get_store or search_product. It even links forward to the set_store sibling by noting the returned identifier is meant to be passed to it.

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 clearly establishes the triggering context (locating nearby stores from a postal code or city) and implicitly positions itself as the lookup step before set_store. It stops short of naming alternatives or stating when not to use it, so no exclusions are covered.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them; it adds that the full cart contents plus total are returned. It does not cover edge cases such as an empty cart or whether the total includes taxes, so added value is modest.

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

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

A single short sentence with no waste, and the resource and returned scope are front-loaded. Every clause 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 zero-parameter read tool with no output schema, the description conveys what is returned (cart contents and total), which is the key missing structured information. It could go further on empty-cart or error behavior, but the core is covered.

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, so the baseline is 4. Nothing more is needed for parameter semantics, and the description correctly implies no filtering is required.

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

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

States a specific verb+resource ('Affiche le contenu complet du panier') plus the scope of what is returned ('avec le total'). The read-only verb implicitly distinguishes it from mutating siblings like add_to_cart, remove_from_cart and update_quantity, 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?

No explicit when-to-use or when-not-to-use guidance. Usage is only implied by the read nature of the verb relative to the mutating siblings, leaving the agent to infer the appropriate 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the returned field names (id, hôte), with no note on what happens if no store is selected — a plausible edge case for a zero-param getter.

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

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

A single short sentence that front-loads the action and immediately states what is returned. No filler, no redundancy with the title.

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 trivial zero-param read with readOnly annotations, the description covers purpose and return shape, which is most of what an agent needs. It stops short of describing behavior when no store is selected, the one gap that matters here given there is no output schema.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about 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?

The description gives a specific verb+resource pair ('Affiche le magasin actuellement sélectionné') and names the returned fields (id, hôte). The word 'actuellement sélectionné' implicitly scopes it away from siblings like find_stores or set_store, though those siblings are never named.

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

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

Usage is only implied: the phrase 'actuellement sélectionné' suggests this reads current state rather than searching or changing it, letting an agent infer find_stores/set_store are the alternatives. There is no explicit when-to-use or when-not-to-use statement.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, covering the safety and repeat-safety profile. The description adds 'complètement' (full removal vs. partial), but says nothing about behavior when the product is absent or effect on cart totals.

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?

Single front-loaded sentence with no waste, but it is very terse even for a simple tool and could carry one more clause about outcome or edge case at negligible 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?

For a one-parameter tool with full schema coverage and annotations declaring destructiveness and idempotency, the definition is nearly complete. Only the not-in-cart behavior is unaddressed, which is minor here.

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

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

Schema coverage is 100% and product_id is documented, including its derivation from search_product's id field. The description adds no parameter detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (retire/completely removes) and resource (un produit du panier). The word 'complètement' helps distinguish it from adding or quantity updates, 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?

No explicit when/when-not guidance or named alternatives. 'Complètement' implicitly distinguishes it from update_quantity, leaving the agent to infer the choice between removal and quantity adjustment.

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 only declare readOnlyHint and openWorldHint, so the description carries real weight and does add value by disclosing the exact return payload — including the price-per-unit field and the cart-ready id — which is critical with no output schema. What's missing is any mention of result limits, pagination, or empty-result behavior for a live external catalog.

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

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

Two sentences, zero filler. Scope constraint is front-loaded and the return-value clause directly sets up the next call rather than padding the 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?

For a single-parameter read tool with no output schema, the description covers purpose, store dependency, and return fields — enough to call it correctly the first time. It stops short of explaining pagination or what happens when the selected store has no catalog loaded.

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

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

Schema coverage is 100% and the schema's own description already gives an example query ("lait demi-écrémé bio"), so the schema does the heavy lifting. The tool description adds nothing about the query parameter itself (no matching behavior, no accent/plural handling), so baseline 3 is correct.

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 ("Recherche des produits dans le catalogue Leclerc Drive") plus the scope constraint ("du magasin sélectionné") and even enumerates what comes back (libellé, prix, prix au kilo/litre, disponibilité, id). Sibling names confirm the distinction: all other tools are cart/store operations, so an agent can immediately tell this is the discovery step.

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

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

The phrase "du magasin sélectionné" signals the prerequisite that a store must be chosen first (find_stores/set_store) and that results vary by store. It also links forward in the workflow by noting the returned id is what add_to_cart needs. No explicit when-not or alternative is named, 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?

The annotations already declare this as a non-readonly, idempotent, non-destructive operation. The description adds useful behavioral context beyond the annotations by explaining that the store choice is remembered for future sessions and depends on the server's Chrome window connection.

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 three tight sentences with no wasted language. The core action is front-loaded, followed by the required id source and the environment constraint.

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 mutation tool with full schema coverage and annotations, the description covers the essential behavior, persistence, and environment dependency. It could say more about error handling or the optional host workflow, but those gaps are minor because the schema documents the host 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 100%, so the schema already documents both store_id and the optional host parameter thoroughly. The description reinforces that store_id should come from find_stores, but it does not add meaningfully more detail about parameters than the schema provides.

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: it selects the active store and persists that choice for future sessions. It also ties the tool to find_stores, which helps distinguish it from discovery tools like find_stores and get_store.

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 clearly directs the agent to use the id returned by find_stores, establishing the intended workflow. It also adds the important constraint that shopping only works on the drive where the server's Chrome window is connected, though it does not explicitly state when not to use the 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?

The annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the crucial detail that a quantity of 0 deletes the line from the cart — the concrete destructive outcome the hint only gestures at. It does not cover permissions or behavior when the product is absent from the cart, which keeps it short of a 5.

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

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

A single sentence with the core action front-loaded and the edge case in parentheses. Nothing is wasted and nothing essential is buried.

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

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

For a two-parameter idempotent cart mutation with full annotation coverage and no output schema, the definition supplies everything needed to call it correctly. Only the case of updating a product that is not in the cart is left 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 coverage is 100% and both parameters carry their own descriptions, including the 0-means-remove semantics, so the description adds no meaning beyond the schema. The baseline of 3 applies when the schema does the heavy lifting.

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

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

The description names a specific verb and resource ('Fixe la quantité exacte d'un produit dans le panier') and clarifies the special case that a value of 0 removes the item. This sets it apart from add_to_cart and remove_from_cart in practice, though it never names those siblings 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 parenthetical '(0 le retire)' implies when this tool substitutes for remove_from_cart, but there is no explicit guidance on when to prefer this over add_to_cart or remove_from_cart. The agent must infer the routing from the verb 'Fixe' alone.

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