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

No annotations exist, so the description carries the full burden. It does disclose one genuinely valuable trait — that processing continues when a line fails — which tells the agent to expect partial success rather than atomicity. It says nothing about authentication, cart-state preconditions, whether successful lines persist after a failure, or any rate limits, leaving substantial behavioral ground uncovered for a mutation tool.

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

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

The three telegraphic fragments are front-loaded and free of filler, and the item shape is surfaced immediately after the purpose. The trade-off is under-specification rather than verbosity, and the mojibake in "groupé" slightly harms readability. Nothing wasteful, but equally nothing polished.

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 legitimately omitted and the partial-failure note covers the main edge case. Still, for an unannotated batch mutation with a completely undescribed input schema, the description should specify required item fields and whether failed lines leave the cart partially modified.

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% and the schema itself only declares `items` as a loosely typed array of free-form objects, so the description is the sole source of item structure. It supplies the exact field set {product_id, offer_id, seller_id, quantity}, which is real added value, but omits which fields are required versus optional, their types, and acceptable quantity ranges.

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 phrase "Ajout groupé" plus the tool name make it clear this is a batch add-to-cart operation, and the item shape confirms the resource. However, it never explicitly contrasts itself with the singular sibling add_to_cart, so an agent must infer the distinction from the name alone. Purpose is understandable but only minimally differentiating.

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 statement of when to prefer this over add_to_cart, update_cart_line, or any other cart sibling, and no prerequisites or preconditions are given. The only usage-adjacent information is the partial-failure clause "Continue si une ligne échoue," which describes runtime behavior rather than selection 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 exist, so the description carries the full burden. It does disclose the non-obvious accumulative semantics (rather than overwriting the line), which is genuinely valuable, but it says nothing about failure modes (out-of-stock, invalid offer/seller pairing), permissions, or whether a new line is created when the product is absent.

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 clauses, front-loaded with the effect and followed by the sourcing hint; nothing is redundant. Slightly undermined by the garbled encoding ('unités', 'déjà ') which hurts machine 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?

A cart-mutating tool with no annotations, no output schema, and 0% parameter coverage needs far more: what happens to an existing line, what errors surface, and what the three required IDs mean. The description leaves most of that for the agent to guess.

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 none of the four parameters are documented in the schema. The description only clarifies `quantity` (additive, default implied by schema) and vaguely points at search_products for the IDs; it never explains the product_id/offer_id/seller_id triple or why all three 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?

States a specific verb and resource ('Ajoute `quantity` unités') and adds the key qualifier that the quantity accumulates onto what is already in the cart, which separates it from update_cart_line. It does not explicitly name that sibling, so differentiation is only implied.

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

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

Gives one concrete sourcing rule ('IDs issus de search_products'), which tells the agent where to get the three required IDs. There is no guidance on when to prefer add_many_to_cart or update_cart_line, nor any exclusions or preconditions.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that scheduling and payment are not handled automatically, but it does not clarify whether the tool creates a checkout session, whether it has side effects, or what permissions are needed.

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

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

The description is two short sentences with no wasted text. The key limitation about manual scheduling and payment is placed after the resource name, though the first sentence is somewhat under-specified.

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. However, for a zero-parameter checkout tool with no annotations, the description should more clearly state whether it generates a link or merely retrieves one, and what the user is expected to do next.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with the tool taking no 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 says "Lien du panier" (cart link), which identifies the resource but does not state a clear action such as generating or returning a checkout link. It is more specific than the bare tool name but still leaves the exact operation vague.

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 note that scheduling and payment are handled manually by the user gives implied context, but there is no explicit guidance on when to use this tool versus siblings like view_cart or status. No alternatives or preconditions are named.

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 provides almost nothing: it does not say whether removal is reversible, what happens if line_id does not exist, whether the cart must be non-empty, or whether an updated cart is returned. For a mutation tool with zero annotation coverage this is a significant 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 short sentence with no filler and the action front-loaded. Its brevity is efficient but shades into under-specification for a mutation tool.

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 a mutation tool with no annotations, no output schema, an undocumented required parameter, and six sibling tools, the description does not supply enough for an agent to call it confidently or predict the result.

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% and there is exactly one parameter, line_id, whose meaning the description only weakly implies via 'une ligne du panier'. It never says whether this is a database ID, a SKU, or a positional index, nor how to obtain it (presumably from view_cart).

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 verb + resource is specific: it removes a single line from the cart, which implicitly distinguishes it from add_to_cart, add_many_to_cart and update_cart_line. It stops short of naming those siblings explicitly, so it lands at 4 rather than 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?

There is no guidance on when to use this instead of update_cart_line (e.g. quantity-to-zero) or view_cart, and no stated preconditions. The agent must infer the routing from the tool name alone.

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

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

With no annotations, the description carries the full burden. It does disclose a genuine behavioral trait beyond the schema: the tool auto-paginates when limit > ~34. It does not state that this is a read-only operation, whether results are ranked/filtered server-side, or anything about errors or rate limits.

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

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

Purpose is front-loaded in the first clause, which is good, but the second sentence is a long field enumeration that overlaps with the existing output schema, and the mojibake encoding ("sélectionné") degrades readability. Some of the field notes (effective_unit_price_eur, promo.min_qty interaction) do earn their 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?

An output schema exists, so the explicit field list is largely redundant; meanwhile the gaps that matter — query semantics, result ordering, and how the "selected Drive" context is established — are unaddressed. Adequate for a simple two-parameter search, but not thorough.

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. The limit parameter gets meaningful treatment via the "~34" pagination threshold, but query — the required parameter — has no explanation of matching semantics (substring? fuzzy? brand names?). 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?

"Cherche des produits (prix du Drive sélectionné)" gives a specific verb plus resource and an important scope qualifier (prices come from the currently selected Drive). It does not explicitly name why you would use it versus the cart siblings, but the search-vs-mutate distinction is self-evident from the name.

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 closing note that product_id/offer_id/seller_id are "pour add_to_cart" hints at the search-then-add workflow. There is no explicit when-to-use/when-not statement, no guidance on query formulation, and no mention of what to do if no results are returned.

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 does disclose what the response contains (connection state, consentId, intercepted headers), which implies a read-only inspection with no side effects, but it never states that explicitly and gives no indication of what happens when no session exists or what the header data means.

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 padding, and the resource is front-loaded. It is slightly undermined by mojibake encoding ('État', 'interceptés') and by the cryptic closing phrase, which costs a little 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?

With no annotations and no output schema, the description is the only source of information about what comes back, and it gives just a three-item summary. 'Headers API interceptés' is unexplained, so an agent cannot anticipate the shape or reliability of the returned data.

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 nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The description's mention of returned fields is a small bonus rather than a parameter explanation.

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 says the tool returns session state ('État de la session') and names concrete fields: connection status, consentId, and intercepted API headers. That is more informative than the bare name 'status', but there is no verb and the purpose is expressed as a data listing rather than an action, leaving the intent only implied.

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 statement of when to call this, no prerequisites, and no reference to alternatives. The sibling tools are all cart operations and none are related, so no routing guidance was strictly possible, but the description offers no usage context at all.

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 at all, the description carries the full burden, and it does disclose one important behavior: quantity=0 removes the line. That is genuinely beyond the schema. It is silent on permission/auth requirements, what happens for negative quantities, out-of-stock or quantity-cap behavior, and error responses — significant gaps for a cart mutation tool.

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

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

Two short sentences, no filler, and the delete-by-zero rule is placed immediately after the core action so it is not buried. Sized appropriately for a simple two-parameter mutation.

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 2-parameter write tool with no annotations and no output schema, the description covers the essential calling semantics and the main side effect. It still leaves the agent without error behavior, edge-case handling for quantity, and the rationale for choosing this over remove_from_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 description coverage is 0%, so the description must compensate, and it does reasonably well: line_id is sourced to view_cart and quantity is defined by its effect, including the 0-to-delete special case. It omits any range, sign, or upper-bound constraints on 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?

The description names a specific verb+resource ('Fixe la quantité d'une ligne') and adds the key semantic twist that a quantity of 0 deletes the line, which an agent could not infer from the name alone. It stops short of distinguishing itself from the sibling remove_from_cart, which overlaps with the quantity=0 behavior.

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 usefully tells the agent where line_id originates ('issu de view_cart'), implying the required call sequence before this one. However, there is no explicit guidance on when to use this versus remove_from_cart or add_to_cart, leaving the overlap for the agent to resolve.

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 disclosure burden. The field list implies a read-only operation, but it never says so explicitly, and it omits behavior for an empty cart, currency/rounding of totals, or whether cagnotte values are live or cached.

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 sentence, front-loaded with 'Contenu du panier' before the field enumeration. The inline field list is dense but every item maps to a value the agent will receive.

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?

There is no output schema, so the description must describe the return value, and it does this thoroughly, including the meaning of cagnotte_total_eur. Without annotations it could say more about read-only safety and empty-cart behavior, but for a zero-parameter read tool this is close to sufficient.

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 nothing for the description to compensate for; the baseline of 4 applies. The parenthetical field list documents the return shape instead, which is supplementary rather than 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 it returns the cart contents and enumerates the returned fields, which lets an agent distinguish this read operation from mutating siblings like update_cart_line and remove_from_cart. It never uses an explicit verb such as 'view/read/return', so the purpose is inferred from the field list rather than stated outright.

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 no guidance on when to call this versus add_to_cart, update_cart_line, or checkout_link, and no precondition such as requiring a cart session or authentication. Usage is only implied by the field listing.

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