Cadorama

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

With no annotations, the description carries the full behavioral burden. "Vérifier" implies a read-only lookup, but nothing is said about what happens when the session ID is invalid or unpaid, whether the call has any side effects, or what status values can come back.

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, front-loaded with the core action, no filler. The second sentence is mild restatement but earns some place as the only usage hint.

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?

No output schema exists, so the description should say what a "statut" looks like (paid, pending, expired) and how failures surface. It covers neither, and with no annotations either, an agent has little beyond the name to reason about results.

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 parameter description already explains that sessionId comes from create_checkout. The description's "par son ID de session" is redundant with 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 and resource: verifies the status of a Stripe payment by session ID. This clearly separates it from create_checkout in spirit, but the description itself never names that sibling – the connection only appears in the schema's parameter description.

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?

"Utile pour confirmer si un utilisateur a finalisé son paiement" gives an implied usage context (post-checkout confirmation) but no explicit when/when-not rules, no prerequisites, and no mention of create_checkout as the upstream step. An agent must infer the workflow.

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 most of it: shipping is included and computed by the store, pickup is free, payment is by bank card, and the order is only created after successful payment. It stops short of failure behavior — out-of-stock items, price changes between link creation and payment, link expiry, or idempotency of repeated calls are all unstated.

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 and return value are front-loaded, and the mode/restriction details follow in a logical order. A few clauses restate what the delivery enum description already says (free pickup, no address), which is minor redundancy 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?

For a 3-parameter mutation tool with no annotations and no output schema, the description supplies the essentials: what it produces (a payable URL), what happens afterward (automatic order creation), and which products are out of scope. The main missing piece is error/precondition handling for a checkout flow.

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; the description nevertheless adds real meaning beyond the schema by clarifying that home-delivery shipping costs are INCLUS and calculated by the store, that retrait requires no address and is GRATUIT, and that the Point Relais alternative is priced in the response. Item quantity/productId semantics and the optional customerEmail are left entirely to the 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?

Opening sentence names a specific verb and resource: creating a secure Stripe payment link for a Cadorama cart. It immediately distinguishes this from read-only siblings like check_payment by stating the return is a URL the user must open to pay, after which the order is created automatically.

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 spells out both supported modes (home delivery in mainland France vs free in-store pickup with delivery: "retrait"), and explicitly names what cannot be ordered here — age-restricted, fresh/frozen preorder, and variant products must be ordered on the website. It also imposes a behavioral rule on the agent: warn the user about cheaper Point Relais or other lower-cost options before sending the link.

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. It does not disclose whether the operation is read-only, how results are ordered, how fresh the sales data is, or what permissions are needed. The word 'Lister' implies a read operation, but behavioral traits are largely 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 sentences, front-loaded with the core purpose. The second sentence is somewhat vague but adds a useful usage hint without bloat.

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 one-parameter list tool, the description covers the core purpose but omits return shape, ordering, and data freshness. With no annotations and no output schema, those gaps leave the agent with only a partial picture.

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

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

The schema has 100% coverage and fully documents the single optional limit parameter, including default and max. The description adds no parameter-specific meaning beyond what the schema provides, 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?

The description states a specific verb and resource: 'Lister les produits les plus vendus chez Cadorama'. It is clear what the tool returns, but it does not explicitly distinguish itself from sibling tools like get_new_arrivals or search_products.

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?

'Pratique pour suggérer ce qui plaît le plus aux clients' implies a recommendation use case, but there is no explicit guidance on when to use this versus get_new_arrivals or get_promotions. It provides context but no alternatives or exclusions.

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. 'Lister toutes' implies a read-only, complete enumeration of available categories, but the description does not mention return format, ordering, pagination, or any auth requirements.

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 immediately states the action, the resource, and the scope.

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, the description is minimally viable: it says what will be listed and the catalog scope. However, with no annotations and no output schema, it could add more context about the response shape or constraints.

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 parameter semantics are not a concern. The empty schema and lack of parameters mean the description does not need to explain any inputs, and baseline 4 applies.

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

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

The description uses a specific verb ('Lister') and resource ('catégories et sous-catégories') with clear scope ('catalogue Cadorama'). It does not explicitly contrast with siblings, but none of the listed siblings appear to be category-listing tools, so the purpose is still clear.

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 explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Usage is only implied by the verb 'Lister' and the resource being categories.

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

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

No annotations are provided, so the description carries the burden. 'Lister' implies a safe read and the 14-day admin-flag window is genuinely useful behavioral context, but it says nothing about ordering (arrival date? newest first?), whether the window is measured from creation vs. publication, or what happens past 14 days.

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 well-formed sentence with the core definition front-loaded; the parenthetical earns its place by defining the 14-day Nouveauté rule. Slightly dense but no waste.

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 read-only listing tool with one optional parameter, no output schema, and full schema coverage, the description supplies the essential domain rule (14-day admin flag). Missing only minor ordering/edge-case detail, which is not critical to correct 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?

Only one optional parameter (limit) with 100% schema description coverage including default and max of 50, so the schema does all the work. The description adds no parameter-level meaning beyond what is already 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?

Clear verb + resource ('Lister les nouveautés Cadorama') and it goes beyond the name by defining what counts as a nouveauté: products recently added and flagged by the admin for 14 days. That definition effectively separates it from get_best_sellers or search_products, 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 14-day definition implies when this list is appropriate versus a general product search, but there is no explicit when-to-use/when-not guidance or named alternative such as search_products or get_promotions. Usage is inferable 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?

No annotations are provided, so the description carries the burden. 'Obtenir les détails' clearly signals a read-only retrieval, and it usefully discloses the payload contents (description complète, toutes les images, gencode, poids, produits similaires), partially compensating for the missing output schema. It says nothing about auth requirements, error behavior when the ID is invalid, or response size.

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 the action first and the returned-fields list second. No filler; the parenthetical enumeration earns its place by substituting for the absent output 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 one-parameter read tool with no annotations and no output schema, the description supplies the essential compensating detail: what the response contains. Missing only edge-case behavior (invalid or unknown productId) to be fully 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?

Only one parameter, and the schema already documents it at 100% coverage including how to obtain the ID via search_products. The description merely restates 'par son ID' without adding format, validation, or example semantics, 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 ('Obtenir') and resource ('détails complets d'un produit Cadorama') with the lookup key ('par son ID'), and enumerates the returned content. It implicitly separates itself from search_products (query-based) via the ID requirement, though it never names the sibling 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?

Usage is only implied: use this when you already have a product ID. There is no explicit when/when-not statement, no mention of search_products as the alternative for discovery, and no prerequisite guidance beyond what the schema's 'obtenu via search_products' note carries.

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. 'Lister' implies a read-only listing, and the description usefully discloses the returned fields (prix barré, pourcentage de réduction, date de fin), but says nothing about ordering, pagination behavior beyond the limit param, or how expired promos 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?

Two short sentences with the purpose front-loaded and the return shape second. No filler, though the mixed language (French description against English tool and sibling names) is a small readability 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 single-optional-parameter read tool with no output schema, disclosing what is returned (struck-through price, discount percentage, end date) covers most of what an agent needs. Missing only ordering and pagination conventions.

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 'limit' parameter is documented in the schema with default, min and max. The description adds no meaning beyond that, 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?

States a specific verb and resource ('Lister les produits ... en promotion chez Cadorama') and scopes it temporally with 'actuellement'. It is clearly distinguishable from get_best_sellers and get_new_arrivals, but it never names them, so sibling differentiation is implicit rather than 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?

The word 'actuellement' implies this is the tool for live promotions rather than historical or upcoming ones, which is a useful usage cue. However, there is no explicit when-to-use/when-not guidance and no mention of the alternative tools an agent should pick instead.

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 burden and does useful work: it discloses that hours are live-read and current ('À JOUR, lus en direct'), that the midday break is included, and that real-time open/closed status is computed. It omits any statement about failure behavior or the response shape, but for a zero-parameter informational read there is little else an agent needs to know before calling.

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 that names the resource first and then lists contents; nothing is wasted or redundant. The parenthetical 'lus en direct, avec la coupure de midi' is dense but earns its place by clarifying data freshness. Slightly list-heavy for one sentence, but still tight.

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?

No input parameters and no output schema, yet the description enumerates the returned information field-by-field (address, hours, status, closures, phone, services, legal notices), which substitutes for the missing output schema. An agent knows both when to call it and what to expect back.

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 no parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline for a 0-parameter tool 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 ("Obtenir les informations") and resource ("magasin physique CADORAMA à Saint-Quentin") and enumerates exactly what comes back: address, live hours, open/closed status, exceptional closures, phone, services, legal notices. No sibling tool (check_payment, search_products, get_categories, etc.) overlaps with physical-store lookup, so the 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?

Usage is clearly implied by the enumeration of questions it answers ('statut ouvert/fermé en ce moment', 'fermetures exceptionnelles à venir'), giving the agent concrete triggers. It does not state explicit exclusions or point to alternatives, but the entire sibling set is product/payment-oriented, so there is little realistic ambiguity 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 burden; it does disclose the return payload (price, stock, direct link), which is useful. However it omits key behavioral facts an agent needs: default limit of 10 (max 50), that inStockOnly defaults to true so out-of-stock items are hidden unless overridden, result ordering, and behavior on zero matches.

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 padding, what-it-does first and what-it-returns second. 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 an 8-parameter, zero-required search tool with no annotations and no output schema, the description covers purpose and return shape adequately, and the rich schema fills in the rest. The main gap is that the notable default (inStockOnly=true, limit=10) is left only in the schema rather than surfaced as behavior an agent should consciously override.

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%, so the baseline is 3; the description goes slightly beyond by grouping the search facets (mot-clé, catégorie, sous-catégorie) into the tool's core behavior. It still adds nothing about exclude, minPrice/maxPrice, limit or inStockOnly, so it does not exceed the schema meaningfully.

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 (Rechercher) and resource (produits dans le catalogue Cadorama) plus the searchable facets, and the second sentence names what comes back (prix, stock, lien direct). It implicitly separates itself from get_product/get_best_sellers/get_new_arrivals, but never names a sibling 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?

Usage is only implied: the reader infers 'use this to find products by keyword/category'. There is no statement of when to prefer get_product over this, no note that it is the multi-result counterpart to the single-item tool, and no exclusion guidance.

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