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

No annotations are provided, so the description carries the behavioral transparency burden. It discloses the mutation semantics ('adds or updates'), the authentication requirement, and the return value ('updated cart totals and summary'). It does not discuss failure behavior or explicitly state that the quantity replaces rather than increments an existing item, but the essential side effects are 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?

The description is front-loaded with the main verb and resource, and each sentence adds a distinct piece of information: action, parameters, tracking, return value, and auth requirement. It is slightly verbose and could be tightened, but it is not redundant.

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 covers the action, auth requirement, and return information, which is important given no output schema. However, it does not address the sibling `add_item_to_cart_by_ean`, error/unauthenticated behavior, or clarify whether `counter` sets or increments quantity, leaving some ambiguity for a mutation tool.

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 schema already documents each parameter. The description adds grouping and context, such as 'basket service (store/drive)', 'sub-basket type (e.g. drive click-and-collect)', and 'tracking context', but it does not significantly expand beyond the schema definitions.

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

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

The opening sentence names a specific action ('Adds or updates') and resource ('product item in the authenticated user's cart on Carrefour France'), and the description adds EAN, quantity, basket service, and sub-basket type. However, it does not distinguish this tool from the sibling `add_item_to_cart_by_ean`, so it stops short of full sibling differentiation.

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 clear usage context: this is for adding or updating cart items under an authenticated Carrefour session, with optional tracking context. It does not provide explicit when-not-to-use guidance or name an alternative such as `add_item_to_cart_by_ean`, so it earns 4 rather than 5.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It states that it adds a product and returns updated cart totals and summary, but it does not disclose side effects like overwriting existing cart state, failure behavior, or whether an invalid EAN could partially modify a cart.

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 sentences, front-loaded with the primary action, and economical. Every phrase adds value: the EAN method, the required service IDs, the tracking context, the return value, and the authentication note.

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 moderate complexity of the tool, the description covers the main purpose, parameters, return value, and authentication prerequisite. It could be more complete by mentioning what happens if the EAN is invalid or session expired, but the provided information is sufficient for a competent selection decision.

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 each parameter has a clear description. The tool description adds the real-world meaning of basketServiceId and subBasketType with an example ('drive_clcv' for drive click-and-collect), and the tracking context for pageType/pageId, which complements 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?

The description uses a specific verb ('Adds') and clearly states the resource (authenticated user's cart on Carrefour France), the key identifier (EAN), and required context (basket service ID, sub-basket type). It distinguishes itself from the sibling `add_item_to_cart` by specifying the EAN-based method and the Carrefour France scope.

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 clarifies that it requires an authenticated Carrefour session, which helps the agent know when this tool is applicable vs. needing `carrefour_refresh_session` or `carrefour_browser_login`. It does not explicitly name sibling alternatives, but the EAN-specific phrasing and authenticated-session requirement provide useful 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?

No annotations are provided, so the description carries the behavioral burden. It discloses that the operation modifies the cart, associates the code with a facility and sub-basket, requires an authenticated session, and returns success or error. It does not mention potential replacement of an existing promo code or idempotency, but the core behavior and side effect (applying to cart) are clearly communicated.

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 short, front-loaded, and contains no fluff. Each sentence contributes: what the tool does, how the promo is associated, what the response returns, and the authentication requirement.

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 low-complexity mutating tool with three fully documented parameters and no output schema, the description provides enough operational context: action, target, association details, success/error behavior, and session requirement. A more complete description could mention behavior when a promo is already applied, but the current version is sufficient for safe 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 input schema already documents all three parameters with examples and 100% coverage, so the description does not need to add much. It reinforces the context for facilityServiceId and subBasketType, but does not add substantially new semantic meaning beyond 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?

The description uses a specific verb ('Applies') and identifies the exact resource ('promotional/discount code' to the 'authenticated user's cart on Carrefour France'). It also clarifies the association with a facility/service and sub-basket type, making it clearly distinct from read-only sibling tools like get_advantage_codes or get_cart.

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 clear context for use: applying a promo code to a cart, with an explicit authentication requirement. It does not explicitly name alternatives or when-not-to-use cases, but the context is sufficient to guide selection among the sibling tools.

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 for behavioral disclosure. It mentions the output includes 'highlighted text, plain text, and corresponding search links', which gives some transparency about the response structure, but it does not disclose potential side effects (e.g., whether it triggers sessions), error conditions, rate limits, or required authentication. The description adds value beyond the schema but lacks depth for a network read operation.

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 sentences with no wasted words. It front-loads the purpose and includes essential response details, making it concise and well-structured. Every sentence 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?

The tool has 3 parameters, 100% schema coverage, and no output schema, but the description does not explain the return format in detail (e.g., whether it returns an array of objects with fields for highlighted/plain text and links). It mentions the response includes these elements, which is helpful, but lacks details on pagination, default behavior, or error handling. Given the simplicity, a score of 3 is adequate but not outstanding.

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 schema already documents all three parameters (q, maxResults, productCard). The description adds little beyond stating that 'q' can be empty or partial text, which is already implied by the schema. It does not explain the interaction between 'maxResults' and 'productCard' or their impact on the response, but the baseline of 3 is appropriate because the schema handles the parameter details.

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 ('Retrieves') and resource ('search autocomplete suggestions for a query on Carrefour France'), distinguishing it from sibling tools like 'search_products' and 'get_products_by_query' by focusing on autocomplete/typeahead behavior. It clearly indicates the purpose is to power a search bar autocomplete feature.

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 provides clear context for when to use the tool ('for powering a search bar autocomplete/typeahead feature'), but does not explicitly mention when not to use it or contrast it with alternatives like 'search_products' or 'get_products_by_query'. The context is sufficient for typical selection, but exclusions are missing.

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?

Beyond the apparent side effects (a browser is displayed), the description provides important stateful behavior: the SSO cookie that can renew itself is retained in the server profile. Also captures the login anti-automation behavior (Turnstile won't validate). No annotation variables to fill side effects.

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?

Five sentences describe the entire procedure, constraints and persistence. No filler, no redundancy, and every sentence adds new information.

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-param tool with no output schema, the description sufficiently covers the important user-relevant context: the profile session stays in the profile, the login cannot be automated. It is not overly complex; no output structure needed.

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 input schema is an empty object, no parameters; the schema already captures all required details. Baseline of 4 applies due to high schema coverage and no parameters requiring additional elaboration.

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?

Description uses a specific verb+resource ('Opens a browser window on the server profile so you can sign in to carrefour.fr') and names the exact target site. It also describes the complete login workflow (captcha, emailed OTP, close window, session keeps). This distinguishes it from siblings like carrefour_session_status or get_cart.

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?

Description clearly states the context: manual login needed on carrefour.fr. It says that automation cannot be performed: Turnstile refuses to validate in a controlled browser. It does not explicitly name alternative tools, but conveys the appropriate scenario.

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 of disclosing behavior. It states 'delete' which implies a destructive action, but does not detail side effects such as whether the server session is invalidated, if authentication is required, or if this is reversible. The description is transparent about the primary action but lacks contextual behavioral details.

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

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

The description is a single sentence, concise and front-loaded. It conveys the essential purpose without any fluff, making it highly efficient for an agent to parse.

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 tool with no parameters and no output schema, the description is largely complete. It explains exactly what action is performed. However, it could benefit from mentioning that clearing cookies may log out the user or affect the session state, but given the simplicity, it is nearly adequate. A slightly richer context would elevate completeness, but it is not critically incomplete.

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

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

The tool has no parameters, and the schema is empty with 100% coverage. The description does not need to explain any parameters, and the baseline for zero parameters is 4. The description adds no irrelevant parameter info, so it is appropriate.

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

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

The description clearly states the action ('Delete') and the resource ('locally stored Carrefour cookies'). It easily distinguishes from siblings like carrefour_set_cookies (sets cookies) and carrefour_refresh_session (refreshes session), as it specifically describes deleting local cookies.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that this is likely for logging out or clearing a session, nor does it exclude any usage scenarios. Without context, an agent may not know when to select this over carrefour_set_cookies or carrefour_refresh_session.

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?

Without annotations, the description carries most of the transparency burden. It does disclose the source cookie and the fact that automatic refresh/retry is normally handled elsewhere. It stops short of mentioning failure modes or what happens if the stored IAM SSO cookie is invalid, but for a zero-parameter maintenance tool it is reasonably informative.

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

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

Two sentences are used, each earning its place: the first states what it does and how, the second explains why it should rarely be called. No filler, no redundancy.

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 parameterless session-refresh tool, the description fully covers its purpose, mechanism, and expected usage frequency. Missing output schema is not an issue because the tool is a side-effect operation rather than one with a meaningful return payload.

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 100% covered by the empty properties definition. Baseline for 0-parameter tools is 4, and the description adds meaningful context by identifying the specific cookie mechanism without needing to describe any parameters.

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 explicitly states the action as 'Force a renewal of the www.carrefour.fr session' and notes the source (stored IAM SSO cookie). It clearly distinguishes this from sibling tools like carrefour_clear_session or carrefour_browser_login.

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 directly addresses when not to use it: 'Rarely needed by hand' and explains that authenticated requests already refresh and retry on their own. This gives clear guidance that the tool is only for exceptional forced manual renewal.

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 transparency burden. It discloses the core behavior (local status check, optional verification) but does not explicitly state that this is a read-only operation or describe the verification's network/auth implications beyond the schema's parameter description.

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 communicates the tool's purpose without waste. It is concise, grammatically clear, and contains no redundant information.

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 tool with one optional parameter and no output schema, the description is mostly adequate: it conveys the primary function and the optional verification mode. It does not specify what the return value looks like, but 'Report whether' implies a boolean/status result, which is sufficient given the tool's low complexity.

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 one parameter (verify) is already fully documented in the schema. The tool description only adds the phrase 'optionally verify it against the site,' which adds little beyond the schema's more detailed explanation of the authenticated request.

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

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

The description clearly states the tool's function: report whether a Carrefour session is stored locally, with an optional site verification. This is a specific verb+resource combination that distinguishes it from session-management siblings like carrefour_refresh_session and carrefour_clear_session.

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 makes the intended use clear: check local session presence and optionally validate it. It does not explicitly name alternatives or exclusions, so it falls short of a 5, but it provides enough context for an agent to know when this status-check tool is appropriate.

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 states 'store' and implies a session-setting operation, but it doesn't disclose whether this overwrites existing cookies, whether it's persistent, or any side effects. The description is not misleading, but it lacks detail about behavioral nuances.

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 sentences long, front-loaded with the purpose and formats, and the second sentence gives practical acquisition instructions. Every sentence serves a purpose with no fluff.

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 single parameter, no output schema, and no annotations, the description is complete. It explains what to pass, accepted formats, how to obtain the cookies, and why it's needed. No additional information seems necessary for usage.

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 covers 100% with a clear description of the 'cookies' parameter. The tool description adds value by listing accepted formats (header string, JSON object, JSON array) and providing concrete examples ('a=1; b=2') and sources (Playwright, EditThisCookie, DevTools), enriching 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?

The description clearly states what the tool does: 'Store your www.carrefour.fr session cookies' with a specific verb and resource. It explains the purpose ('so the other tools can act on your account') and distinguishes from sibling tools like carrefour_clear_session and carrefour_refresh_session by focusing on storing cookies.

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 clear context on when to use it (to enable other tools to act on your account) and provides practical guidance on obtaining cookies via DevTools. It doesn't explicitly mention when not to use it or alternatives like carrefour_browser_login, but the context is sufficient.

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. It discloses that authentication is required and that it returns created list details. However, it does not mention potential side effects (e.g., whether it overwrites existing lists, rate limits, or error conditions). For a creation tool, this is adequate but not rich; it could state that it does not modify existing lists or require specific permissions beyond authentication.

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 concise, two sentences, and front-loaded with the primary action. It includes essential return information and authentication requirement without unnecessary fluff. Every sentence adds value.

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 simplicity (one parameter, no output schema), the description is fairly complete. It explains the return details and authentication requirement. However, it could mention error scenarios or prerequisites (e.g., session validity) more explicitly, but for a simple creation tool, it is sufficient. The lack of output schema is compensated by listing the return fields.

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 already provides 100% coverage for the single parameter 'title' with a clear description. The tool description adds minimal extra meaning beyond restating that it accepts a title. Since schema coverage is high, baseline 3 is appropriate; the description does not add syntax or format details beyond what 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 clearly states the tool creates a new shopping list (memo-list type) for the authenticated user on Carrefour France, specifying the resource and action. It distinguishes from siblings like get_shopping_lists and get_shopping_list by focusing on creation, and mentions the return details (ID, type, slug, item count, last updated date, EANs).

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

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

The description implies usage when the user wants to create a new shopping list, and notes the requirement of an authenticated Carrefour session. It does not explicitly mention alternatives or when not to use, but the context of sibling tools (e.g., get_shopping_lists) makes the purpose clear. A slight deduction for not explicitly stating exclusions or alternatives.

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 honestly states the auth requirement and clarifies what specific KPI codes measure, including exclusions like delivery fee discounts. However, it does not mention error behavior, invalid-code handling, or the response structure beyond saying each KPI 'returns a value'.

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

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

The description is front-loaded with purpose and remains focused. The known-code list is somewhat long but earns its place by adding operational value. Minor redundancy exists with the schema's property description, but overall it is not bloated.

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 simple one-parameter shape and no output schema, the description covers purpose, usage, auth requirements, and key code semantics. It could be more complete by describing the exact response format or invalid-code behavior, but it is sufficient for a straightforward read-only KPI retrieval tool.

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 already documents the single 'codes' parameter at 100% coverage, but the description adds meaningful semantic detail by enumerating known codes 14, 15, and 16 with specific meanings and exclusions. This goes beyond the schema's generic 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 uses a specific verb ('Retrieves') and identifies a clear resource: loyalty and financial KPI metrics for the authenticated user's Carrefour France account. It also distinguishes this tool from sibling loyalty tools by emphasizing numeric KPI codes and dashboard display usage.

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 provides a clear use context: displaying account performance indicators on the loyalty/fidelity dashboard. It does not explicitly name alternative tools or state when not to use this tool, but the intended scenario is well conveyed.

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 implies a read-only operation by stating 'retrieves' and 'returns', and explicitly mentions the authentication requirement. However, it does not state that no data is modified, nor does it disclose error conditions 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?

The description is a single dense sentence listing many return fields with examples. It is informative but somewhat run-on; splitting into structured bullets or shorter sentences would improve readability without losing 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?

Since there is no output schema, the description compensates well by listing the return fields (code value, dates, reward amount, type, label, new customer flag, validity slot, T&C). It also states the authentication requirement. Lacking are any notes on pagination, result limits, or error handling, but for a simple list retrieval, this is nearly 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 has zero parameters and the schema is empty, so description covers all necessary semantics implicitly. Baseline for no-parameter tools is 4, and no additional parameter explanation is needed.

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?

Description clearly states the tool retrieves advantage/promo codes for the authenticated user on Carrefour France, with a list of specific return details. This distinguishes it from sibling tools like get_loyalty_coupons by focusing on 'advantage codes'.

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 notes it requires an authenticated Carrefour session, which implies when to use, but it does not explicitly exclude or compare to similar loyalty/coupon tools. No alternatives are mentioned, and there is no guidance on when not to use.

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 transparency burden. It conveys that this is a retrieval operation, states the authentication requirement, and notes the optional refresh behavior. It does not specify potential side effects of refresh or error responses, but covers the main behavioral traits needed for safe invocation.

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, with the core purpose in the first sentence and supporting return details/session requirement in the following sentences. Every sentence adds useful information without repetition or 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 simple read tool with one optional parameter and no output schema, the description is complete: it names the resource, identifies the user/session context, details the returned cart components, and mentions the optional refresh. No critical selection or invocation context is missing.

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

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

The schema already fully documents the single optional 'refresh' parameter, so the description's mention of optionally forcing a refresh does not add significant meaning beyond the schema. Baseline of 3 is appropriate given 100% schema description coverage.

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 'Retrieves the current shopping cart contents and summary for the authenticated user on Carrefour France,' using a specific verb and resource. It clearly distinguishes from sibling tools like get_last_orders and get_shopping_list by focusing on the active cart and listing cart-specific data elements.

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 clear context: use this to get the current cart for the authenticated Carrefour France session, optionally refreshing data. It does not explicitly mention when not to use it or name alternatives, but the scope is obvious enough for effective selection among siblings.

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 transparency burden. It explicitly frames the operation as read-only ('Retrieves', 'Returns') and explains the contextual vs generic response behavior with examples. It does not discuss auth or rate limits, but for a non-mutating retrieval tool this is a minor 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?

The description is compact and well-structured. Every sentence earns its place: the first states the core action, the second gives output examples, and the third identifies the primary use case. No redundant 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?

Given the tool's moderate complexity, all required parameters are documented, and the description covers the return value categories (contextual and generic preprompts) even without an output schema. It could explicitly state response formatting or pagination, but the overall description is sufficient for 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?

Schema coverage is 100%, placing the baseline at 3, but the description adds meaningful context: examples of page titles, clarification that GTIN applies only to product detail pages, and concrete examples of contextual vs generic modes. This helps an agent choose parameter values correctly.

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 ('Retrieves') and identifies a precise resource: contextual and/or generic pre-suggested questions for the Carrefour AI chat assistant. It clearly differentiates from siblings like search_products or get_personalized_recommendations by focusing on chat preprompts and navigation context.

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 states when to use the tool: for populating chat suggestion chips on search results or product pages, based on the user's navigation context. It does not explicitly exclude alternatives, but the use case is clear and well-scoped.

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. It discloses the authentication requirement ('requires an authenticated Carrefour session') and outlines the output structure (zones with product lists and delivery type). However, it does not mention whether the operation is read-only, potential side effects, error handling, or response pagination. It covers key behavior but lacks depth.

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 concise and well-structured: two sentences plus a parenthetical. The first sentence states the core action and scope, the second describes the output, and the parenthetical adds a key requirement. No redundant fluff—every sentence 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?

Given there is no output schema, the description provides sufficient detail about the expected return (recommendation zones with products and delivery type) and highlights the authentication prerequisite. For a retrieval tool with two parameters, this covers the essential context. It could benefit from mentioning whether results are localized, but it is sufficiently complete for an agent to use it effectively.

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 input schema describes both parameters (facility_id and basket_service) with examples and explanations. The description does not add new details about these parameters beyond the schema context, but since schema coverage is 100%, the baseline of 3 is appropriate. The description does reinforce that these two parameters define the checkout context, but that's minimal added value.

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

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

The description clearly states the verb 'Retrieves' and resource 'product recommendations during checkout on Carrefour France for a specific facility/store and basket service type.' It distinguishes from siblings like get_product_recommendations by explicitly focusing on the checkout context and mentioning multiple recommendation zones (frequent purchases, personalized, promotions), which makes its scope unique.

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 provides a clear usage context: 'Useful for displaying cross-sell or upsell suggestions to the user at checkout.' This implies when to call the tool (during checkout) and its purpose, but it does not explicitly mention exclusions or alternatives like 'for non-checkout recommendations, use get_product_recommendations.' Given the sibling tools available, this is a minor gap.

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 discloses the requirement of an authenticated session, and implies this is a read-only operation (retrieves) with no side effects. It adds context about the return values (days, availability cells, collaborative delivery type). However, it doesn't specify behaviors like whether it uses cached data, rate limits, or what happens when no slots are available. It also doesn't mention whether it refreshes the session or mutates state, but the parenthetical about authentication is a positive.

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 sentences long and packs in the purpose, return value, use case, and authentication requirement. No wasted words. It loses one point because the structure of 'Retrieves X. Returns Y. Useful for Z. (requires authentication)' is somewhat choppy but still highly efficient.

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 tool with 1 param, no output schema, and no annotations, the description is quite complete. It tells the agent what it does, what it returns, when it's useful, and the auth prerequisite. It could add more about failure modes or response structure, but compared to typical sibling tools ity knows a lot. The absence of output schema puts some burden on the description to describe the return, which it does at a high level.

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 is well-documented in the schema itself, including an example format ('0678-150-149'). The description adds the concept of 'facility/store service' but mostly relies on the schema. Since there's only one parameter and it's thoroughly explained in the schema, the description earns a high score, though it doesn't explicitly repeat or recontextualize the parameters, but with such good schema, that's acceptable per the rubric.

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

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

The description clearly states the tool 'Retrieves available delivery or drive time slots for a specific facility/store service' with specific verb and resource. It adds context about the Carrefour France scope and the return value (list of days with time slot cells). While it doesn't explicitly name a sibling to distinguish from, the description implies it's for browsing slots, and the sibling 'select_cart_delivery_slot' suggests a different action (selecting vs retrieving). Clear but could have been more explicit about the difference from similar tools like 'validate_checkout_slot'.

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

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

The description implies usage ('Useful for letting the user pick a delivery or click-and-collect time window') and mentions a prerequisite ('requires an authenticated Carrefour session'). It also notes the need for a facilityServiceId. However, it doesn't explicitly say when NOT to use this tool or contrast it with alternatives like 'validate_checkout_slot' or 'select_cart_delivery_slot'—though the sibling names are suggestive, the description takes no credit for that.

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 for behavioral disclosure. 'Retrieves' and 'Returns' imply a non-mutating read operation, and the output contents are summarized, but it does not discuss pagination, data freshness, or any checkout session 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 two concise sentences that pack in the resource, scope, return value, and use case without redundant filler. It is front-loaded with the primary action.

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-only retrieval tool with no output schema, the description provides an adequate summary of what the list contains and why it is useful. It could mention whether the list is sorted, limited, or dependent on session state, but these are not critical gaps for this tool.

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 fully covered. The description adds meaningful context about what is returned (EAN, title, brand, slug, category, images, attributes), which is the only relevant semantic dimension for a parameterless tool.

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 ('Retrieves') and a specific resource ('donation products') with clear scope (Carrefour France). It clearly differentiates this tool from all sibling tools, none of which target donation 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?

The description identifies the intended use case: displaying available charities/associations during checkout. It does not explicitly mention when not to use it or alternatives, but the context is clear enough for a zero-parameter retrieval 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 explains pagination, location-based filtering, eligibility filtering, and lists the store fields returned. However, given the sibling tools for session management and login (carrefour_refresh_session, carrefour_browser_login, carrefour_clear_session), the description could have disclosed whether authentication is required or whether this reads from live HTML or API endpoints. It's adequate but not rich.

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 well-structured sentences: one for function/return values, one for usage context. The enumeration of return fields is a bit dense but acceptable. Efficient and 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?

The tool has 6 parameters, no output schema, no annotations, and sits among 50+ siblings including session management tools. The description covers purpose, return values, and context adequately. However, it could have mentioned pagination count or session/authentication expectations to be more complete given the surrounding tool ecosystem.

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 all 6 parameters with examples. The description does not add extra parameter meaning beyond what 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 uses a specific verb phrase ('Retrieves a paginated list of Carrefour drive stores eligible for ordering near a given location') with clear scope ('Carrefour France', 'drive/click-and-collect'). It distinguishes itself from siblings by specifying eligibility (for ordering) and store type (drive stores), which separates it from generic store lookup tools.

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 indicates when to use it ('Useful for finding nearby drive/click-and-collect stores available for a specific city or postal code'). However, it doesn't explicitly contrast against alternatives like get_store_information_inserts, get_favorite_store, or get_store_finder_tools, nor does it state when NOT to use it.

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. The verb 'Retrieves' implies read-only, and it adds authentication requirements and lists the returned store fields. It does not explicitly mention side-effect absence or error behavior, but for a simple getter this is adequate.

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

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

The description is front-loaded with the main action, followed by a concise enumeration of return fields and the auth requirement. The list is slightly long but every item adds useful context; no empty 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 zero-parameter read tool with no output schema, the description provides context (authenticated user, Carrefour France), describes return fields, and states a prerequisite. It is generally complete, though it could mention empty-result behavior or explicitly confirm no side effects.

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?

Tool has zero parameters and the schema is 100% covered. No parameter descriptions are needed, and the baseline of 4 applies. The description adds no unnecessary parameter details.

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 ('Retrieves') with a clear resource ('favorite/preferred store on Carrefour France') and even enumerates the returned details. This clearly distinguishes it from sibling tools like get_eligible_drive_stores or get_store_information_inserts by focusing on the authenticated user's favorite 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 states a key precondition: 'requires an authenticated Carrefour session'. This gives clear context for when to use the tool. However, it does not explicitly name alternatives or provide when-not-to-use guidance, though the scope is unambiguous among siblings.

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 explains that the result is paginated, describes the returned product details, facets, pagination metadata, and optional inclusion of unavailable products, and flags the authentication prerequisite. It does not describe failure behavior if the session is missing or expired, but the disclosed behavior is otherwise solid.

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

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

The description is concise and front-loaded with the core action, then expands into return contents and auth requirement. Every sentence adds useful information without filler or redundant restatement of the tool name.

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 no output schema, the description compensates by summarizing the response: paginated list, product fields, facets, pagination metadata, and the unavailable-products flag. It is complete enough for a simple read-only paginated fetch, though it leaves out details about authentication failure or what happens when the session is invalid.

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 schema already documents both page and displayUnavailable, including page size and available/unavailable filtering. The description's mention of 'Optionally includes unavailable products' mirrors the schema rather than adding new semantic meaning, which matches the baseline of 3.

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

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

The description clearly identifies a specific action ('Retrieves') and resource ('authenticated user's frequently purchased products on Carrefour France'). This distinguishes it from related siblings like get_orders, get_personalized_recommendations, and get_product_recommendations by focusing on frequent-purchase history rather than order history or recommendations.

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 sets clear context: use this tool to fetch the authenticated user's frequently bought items, and it explicitly notes that an authenticated Carrefour session is required. It does not name alternative tools for when this tool should not be used, but its use case is specific enough to be unambiguous.

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 discloses the authentication requirement and describes the output structure (list of recommendations with fields). It does not explicitly state it is a read-only operation or mention any side effects, but the verb 'Retrieves' implies a safe read. This is adequate but not thorough.

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 sentences, front-loaded with the primary purpose, and includes only relevant details (output structure, optional limit, authentication requirement). No redundant or vague phrasing.

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 simplicity of the tool (one optional parameter, no output schema, no annotations), the description is nearly complete. It covers what the tool does, what it returns, and a key prerequisite (authentication). It does not mention error conditions or limitations, but these are not critical for this straightforward read operation.

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

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

The single parameter 'limit' has 100% schema description coverage, and the description adds 'Optionally limits the number of recommendations returned,' reinforcing optionality. The schema already defines it as a maximum number, so the description adds minimal additional meaning beyond the schema, warranting the baseline score of 3.

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

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

The description clearly states the tool retrieves the 'returning user banner' for the Carrefour France homepage, which is a specific resource. It differentiates from sibling tools by noting it targets returning users and returns personalized recommendations with fields like product ID, name, image URL, and optional highlight label. This is precise and unambiguous.

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

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

The description provides clear context: it is for the homepage banner for returning users and requires an authenticated Carrefour session. However, it does not explicitly mention when not to use it or name alternative tools, though the context is sufficient to infer appropriate usage.

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?

Since no annotations are provided, the description carries the full burden. It discloses that an authenticated Carrefour session is required and that a list of order details is returned, but it does not describe error behavior, empty results, or any potential side effects, leaving the tool's behavioral profile only partially specified.

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 that immediately state the purpose and return type, with the authentication note placed in parentheses. Every phrase adds value and there is no redundancy or 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 simple, zero-parameter read-only retrieval tool with no output schema, the description covers the essential context: what is retrieved, for whom, from where, and the required auth state. It omits minor details like how many orders are returned or their ordering, but these are not critical for this tool's simplicity.

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 empty, so there are no parameter semantics to clarify. The description appropriately does not invent parameters, and the no-parameter baseline of 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 ('Retrieves') and clearly names the resource ('most recent orders for the authenticated user on Carrefour France'). It gives a precise scope and return type, though it does not explicitly contrast with sibling tools like get_orders to highlight what 'last' adds.

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 guidance is given on when to prefer this over get_orders or other order-related tools. The only contextual hint is the authentication requirement, which is a prerequisite rather than a usage-vs-alternative guideline.

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 transparency burden. It discloses the authentication requirement ('requires an authenticated Carrefour session') and specifies the return content (bonus, timestamp, total points, validity date). It does not discuss side effects or failure modes, but for a read-only lookup, this is sufficient.

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 concise and well-structured. It leads with the action, then lists returned fields, then usage context, and ends with the auth requirement. No fluff or redundancy.

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 parameterless tool with no output schema, the description is complete: it states what it does, what it returns, and the prerequisite. It fully covers the necessary information without needing an 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 has zero parameters, so per the rubric the baseline is 4. The description does not need to add parameter semantics, and the schema covers all (0) parameters. It adds contextual semantics that are not parameter-specific.

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

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

The description clearly states the verb 'Retrieves' and the resource 'loyalty points balance for the authenticated user on Carrefour France'. It also outlines the specific returned fields, distinguishing it from sibling tools like get_loyalty_cards or get_loyalty_coupon_collection.

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 provides a use case ('Useful for displaying the user's current loyalty points balance') but does not explicitly compare with alternatives or state exclusions. It implies when to use but lacks guidance on when not to use or which sibling tools to prefer for other loyalty features.

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. It mentions the authentication requirement and that it returns card list with types, but does not disclose potential errors, side effects, or whether it is read-only. Without annotations, this is minimal but not misleading.

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 concise, a single sentence with an additional note on authentication. It is front-loaded with the action and subject, with no redundant filler. Slightly verbose with the parenthetical but acceptable.

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 simplicity (no parameters, no output schema), the description covers the essential purpose, return type, and authentication prerequisite. It could mention that it is read-only, but the overall completeness is adequate for a zero-parameter tool.

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 has 100% coverage (empty properties). The description confirms no parameters are needed, and adds context about the return content (card numbers and types). Baseline for zero params is 4, and the description adds clarity.

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

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

The description clearly states it retrieves loyalty cards for the authenticated user on Carrefour France, and specifies it returns card numbers and types. It distinguishes itself from similar siblings like get_loyalty_balance and get_loyalty_coupon_dashboard by focusing on the list of cards, though not explicitly 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?

The description implies usage when displaying the user's loyalty cards, and notes the need for an authenticated session. However, it does not provide explicit when-to-use vs alternatives, such as when to use get_loyalty_balance or other loyalty-related tools.

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. It clearly discloses read-only retrieval, enumerates the returned coupon data, mentions facet metadata, and notes the auth requirement. It could have mentioned error behavior or pagination, but for a zero-param getter this is reasonably transparent.

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 compact sentences, first stating the action and resource, second summarizing output detail and auth requirement. Every sentence contributes meaning with no fluff or repitition of the tool name's intent only.

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 no params, no annotations, and no output schema, the description thoroughly describes return content and auth context. It does not discuss limites like pagination, but that is likely unnecessary for a simple zero-parameter retrieval of a coupon collection.

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 disamyguity is not a concern. The description adds a little semantic flavor by listing coupon attributes, but no parameter-level explanation is needed. Baseline 4 applies as per rubric for zero-param tools.

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?

Description is specific with a clear verb and resource: 'Retrieves the loyalty coupon collection for the authenticated user on Carrefour France.' This distinguishes it from sibling loyalty tools like get_loyalty_balance or get_loyalty_coupons_dashboard by naming the exact collection of data.

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 states a clear context (authenticated user on Carrefour France) and an explicit prerequisite: 'requires an authenticatied Carrefour session.' It does not list alternative tools or when not to use, but the behavior is consistent and clear enough for an agent to select correctly.

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 full burden. It discloses the authentication requirement and read-only 'Retrieves' nature, but does not describe error behavior, potential empty results, or side effects. For a simple read operation, this is acceptable but not comprehensive.

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 concise (two sentences) and front-loaded with the action, immediately stating what it does and what it returns. It wastes no words and is well-structured for an agent to parse quickly.

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?

This tool has no input schema and no output schema. The description compensates by specifying all returned metrics (count of coupons, total amount, coupons in cart) and the authentication prerequisite. For a read-only summary tool, this is sufficiently 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 0 parameters, and the description adds no parameter semantics (there is nothing to add). However, it explicitly lists the return values, which is useful. The baseline for 0 params is 4, and the description does not overspecify, so a 4 is appropriate.

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

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

The description clearly states it retrieves a loyalty coupons dashboard summary for the authenticated user on Carrefour France, specifying the three data points returned. It distinguishes itself from sibling tools like get_loyalty_coupon_collection (which likely returns a detailed list) by focusing on a concise overview.

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 clear context: 'Useful for displaying a quick overview of the user's loyalty coupon status.' It does not explicitly mention when not to use it or alternative tools, but the context of a quick overview is sufficient guidance. However, it lacks explicit exclusions or mention of more detailed tools.

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 present, so the description carries the burden. It discloses the authentication requirement and enumerates the returned fields (store name, totals, discounts, barcode, etc.), implying a read-only operation. It does not mention rate limits or error behavior, but for a retrieval tool this is adequate.

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 deliver all key information without fluff. The critical verb and resource 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?

Given three required parameters and no output schema, the description is sufficiently complete: it states the input identifiers, the return data categories, and the auth requirement. It lacks explicit error conditions, but they are not essential for 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?

Input schema already provides 100% parameter descriptions with examples, so the baseline is 3. The description adds context that the three parameters together identify a specific receipt, but no per-parameter semantics beyond 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?

Describes exactly what the tool does with a specific verb ('Retrieves') and resource ('detailed receipt for a specific in-store purchase'). It clearly differentiates from the sibling `get_loyalty_order_receipts` by focusing on a single receipt's details.

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?

Provides clear context: use when you have the GLN, date key, and receipt number for a specific in-store purchase. It does not explicitly mention alternatives or exclude `get_loyalty_order_receipts`, but the uniqueness of the identifiers makes the usage 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?

With no annotations provided, the description carries the full burden and does well: it discloses pagination behavior ('paginated list', 'scroll paging token and scroll hash'), lists the fields returned (transaction date, store name, receipt number, etc.), and notes authentication requirements ('requires an authenticated Carrefour session'). It does not cover error conditions or rate limits, but it goes well beyond the minimal burden.

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 four-sentence description is front-loaded with the core purpose and keeps the most important detail (what is retrieved) first. Each sentence adds necessary context—returned fields, pagination, and authentication—but the use-case sentence and parenthetical auth note are slightly redundant with the opening sentence.

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 list tool with no output schema and no annotations, the description is thorough: it covers the data source, API path, pagination mechanism, required authentication, and an example use case. It could mention behavior on empty results or token expiration, but the complexity does not demand it.

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's mention of 'scroll paging token and scroll hash' maps directly to the scrollPaging and scrollHash parameters but adds no new meaning beyond what the schema already documents, such as token usage patterns.

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 the specific verb 'Retrieves' and clearly identifies the resource: 'in-store purchase receipts associated with the authenticated user's loyalty card on Carrefour France.' This clearly differentiates the tool from sibling tools like get_loyalty_cards, get_last_orders, and get_loyalty_order_receipt_details by scoping it to the paginated list of in-store receipts.

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 provides a clear use case: 'Useful for displaying the user's in-store purchase history linked to their loyalty card.' However, it never explicitly names alternatives (e.g., get_orders for online orders) or states when not to use this tool, which prevents a 5.

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

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

No annotations are present, so the description carries the transparency burden. It clearly states the output: 'a list of ad placements with product details, beacons, and positioning information.' This goes beyond a vague summary and sets expectations for the response structure, though it could disclose more about side effects (likely none) or session 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?

Two sentences deliver dense, well-structured information. The first sentence defines purpose and scope; the second details the return payload. The placement list is slightly long but serves as a quick reference and aligns with the schema. No unnecessary words.

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 absence of an output schema, the description appropriately summarizes return contents and domain inputs. It covers the placement contexts and gives a sense of what the agent will receive. It could be more exhaustive about edge cases (e.g., what 'non-search placements' means for `searchTerm`), but the essential context is there.

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 all four parameters have descriptions. The description adds value by explaining that the placement context is derived from the URL path segment and gives a comprehensive list of allowed values, which is redundant with the schema but reinforces usage. It also hints at the 'productFilters' parameter with a concrete example, enhancing understanding beyond the schema alone.

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 ('Retrieves') and identifies the exact resource ('marketing/advertising placements') with clarifying examples. It also geographically scopes it to 'Carrefour France', which distinguishes it from generic ad tools among siblings.

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?

Clear context is given: the tool is for placement contexts like 'home', 'search', 'pdp', etc. While it doesn't explicitly name an alternative tool for non-ad recommendations, the description's enumeration of placement contexts effectively implies when to use it. Explicit exclusions are the only thing missing.

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. The description discloses the tool is read-only by nature ('Retrieves'), specifies exactly what content is returned, and mentions dynamic state (whether promotions are active). It does not detail session or access requirements, but that is a limited gap for a zero-parameter read-only 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 description is two sentences long, with the main action and scope front-loaded, followed by valuable detail about return fields and use cases. Every clause adds useful information without repetition or 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?

With no parameters, no output schema, and no annotations, the description successfully conveys what the tool returns, its scope, and its intended uses. It is appropriately complete for a navigation-tree retrieval endpoint.

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 description need not add parameter-level semantics. Schema coverage is 100% vacuously. A baseline score of 4 is appropriate given the absence of parameters.

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

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

The description clearly states the tool retrieves the full navigation/category tree for the Carrefour France website, with specific details on the hierarchical structure and included fields. It distinguishes itself from sibling tools that focus on products, cart, loyalty, or sessions.

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 states that the tool is useful for building navigation menus or browsing the category hierarchy, providing clear context for when it should be used. There are no sibling tools with similar navigation-tree functionality, so explicit exclusion of alternatives is not applicable.

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. It states the tool requires an authenticated Carrefour session, which is useful. However, it doesn't disclose what happens if the session is invalid (e.g., error behavior) or whether this is a read-only operation, though 'Retrieves' implies read-only. The description adds some context but not rich behavioral detail.

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, well-structured paragraph that front-loads the purpose, lists the returned data, and ends with the authentication requirement. Every sentence earns its place with no redundancy.

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 has no parameters and no output schema, the description adequately covers what the tool does and what it returns. It could mention error cases or session requirements more explicitly, but for a simple retrieval tool, it is sufficiently 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 schema description coverage is 100% (vacuously). The description doesn't need to explain parameters, and it adds value by describing the return content (balance, club name, link). Baseline 4 is appropriate for a no-parameter tool.

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

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

The description clearly states the tool retrieves the authenticated user's Olympic Games Prime loyalty account information on Carrefour France, listing specific data returned (balance, club association, club name, website link). This is a specific verb+resource and distinguishes it from sibling tools like get_loyalty_balance and get_loyalty_cards.

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 provides clear context for when to use the tool (displaying the user's Olympic Games loyalty subscription and club association status) and notes the authentication requirement. It doesn't explicitly exclude alternatives, but the specific resource (Olympic Games Prime) makes the use case clear among siblings.

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 takes on the full burden. It discloses the requirement of an authenticated Carrefour session, mentions the paginated response with a list of orders and specific fields, and explains the pagination mechanism. It does not explicitly state read-only behavior but implies it; no contradictions. It could add details on rate limits or error cases but is adequately transparent for a retrieval 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 description is succinct, roughly three sentences, and front-loaded with the core purpose. Every sentence contributes: what it does, what it returns, and how the parameters work. No redundant phrases or filler. Excellent structure.

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 retrieval tool without an output schema, the description sufficiently covers the return value (list of order details and fields), authentication requirement, and pagination workflow. It could mention if startDate and endDate are required together or if scrollSize has a max, but given the complexity level, it is nearly complete for effective agent use.

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 already documents all five parameters with 100% coverage, so the description's contribution is modest. However, it adds valuable context by explaining how startDate/endDate filter the date range, scrollSize limits page size, and scrollHash/scrollPaging work together for pagination—reinforcing the schema descriptions and weaving them into the tool's overall behavior.

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 starts with a specific verb-resource combination: 'Retrieves the authenticated user's order history on Carrefour France.' It distinctly identifies the scope (order history) and differentiates from siblings like get_last_orders and get_loyalty_order_receipts by focusing on the full paginated history.

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 clearly implies when to use this tool: for a paginated list of order history with filtering and pagination capabilities. It doesn't explicitly mention alternatives or when not to use it, but the context across siblings (e.g., get_last_orders for recent orders, receipt-specific tools) makes application scenarios reasonably 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?

With no annotations, the description carries the full behavioral disclosure burden. It specifies that the tool 'retrieves' (read-only implied), requires authentication, and details the return structure (wording block with image, text, title, color; and product list). It does not mention error conditions or side effects, but for a retrieval tool this is adequate. No contradictions with annotations (none present).

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 sentence that efficiently conveys the main action and output details. It is front-loaded with the core purpose and then elaborates on return content. No unnecessary repetition or verbose phrasing; it could be split into two sentences for readability, but it remains concise and structured.

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

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

Given the tool has no parameters and no output schema, the description adequately explains what the tool returns (wording block and product list) and the basis (CDP profile). It covers the essential context for an agent to understand the tool's function and expectations. It does not mention pagination or error handling, but these are not critical for such a simple retrieval tool.

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?

There are zero parameters, so the schema is trivially covered (100%). Per the baseline for 0 params, a score of 4 is appropriate. The description adds context about the prerequisite (authenticated session) but does not need to explain parameter semantics since none exist.

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

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

The description clearly states the tool's purpose: 'Retrieves personalized product recommendations for the authenticated user on Carrefour France'. It specifies the resource (product recommendations), the user context (authenticated, CDP profile), and the output (wording block and product list). This distinguishes it from sibling tools like get_product_recommendations (which may not be personalized) or get_frequent_purchases.

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 guidance is provided on when to use this tool versus alternatives. It mentions 'requires an authenticated Carrefour session' but does not explain when to choose this over get_product_recommendations, get_checkout_recommendations, or get_frequent_purchases. There are no explicit exclusions or alternative tool references.

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 of behavioral disclosure. It discloses the authentication requirement, explains mode-specific behavior, and describes the high-level output shape. However, it does not mention side effects, failure behavior, or any rate-limit/pagination concerns.

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 concise, well-structured, and front-loaded with the main purpose. Each sentence adds useful information about behavior, context types, or output format with no redundant 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?

Given the tool has 9 parameters and no output schema, the description provides a solid high-level contract: input context, parameter relevance, and output structure. It could go deeper on edge cases like optional flags or errors, but the schema plus this description gives an agent sufficient guidance for normal usage.

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 baseline is 3, but the description adds extra semantic value by explaining which parameters are relevant for pdp (EAN, price, categories, facility service) versus plp (categories). This helps the agent decide which optional parameters to populate despite not repeating every schema field.

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

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

The description clearly states the tool retrieves product recommendations and gives concrete context-specific behavior for both pdp and plp pages, naming example recommendation zones like 'Customers also bought'. This distinguishes it from sibling tools like get_checkout_recommendations or get_personalized_recommendations.

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 provides explicit context for using pdp vs plp and notes that an authenticated Carrefour session is required. It does not name sibling tools or explicitly state when not to use this tool, but the page-context guidance is strong.

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?

Since no annotations are provided, the description carries the full burden. It discloses that the tool returns the total review count and a paginated list, and supports sorting and limiting. However, it does not mention any session/auth requirements, error handling, or side effects. This is a non-destructive read operation, but the disclosure is somewhat partial, earning a 3.

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 concise and front-loaded, consisting of two sentences with no unnecessary details. It efficiently conveys the tool's purpose and capabilities.

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 output schema, the description must explain return values, and it does mention the key elements: total review count and paginated list. It also clarifies the scope (Carrefour France) and the identification method (EAN/GTIN). While it lacks details like pagination mechanics or default limits, it is reasonably complete for a simple retrieval tool.

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 input schema already describes all four parameters with 100% coverage. The description merely repeats that sorting and limiting are supported, adding no additional meaning beyond the schema. Baseline 3 is appropriate because 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 clearly states the tool retrieves customer reviews for a specific product on Carrefour France, identified by EAN/GTIN. It uses a specific verb ('Retrieves') and resource ('customer reviews') and is distinct from sibling tools like get_products_by_gtins, which focus on product details rather than reviews.

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 guidance is provided on when to use this tool versus alternatives or when not to use it. The description simply states what it does without placing it in the context of other tools or explaining any prerequisites (e.g., session or authentication), so the usage context is not directly addressed.

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 transparency burden. It usefully discloses the returned fields and optional scoping, but does not mention session/auth requirements, behavior for invalid or missing GTINs, or batch size 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?

Three concise sentences, front-loaded with the core action and resource. Every sentence adds value: what it does, what it returns, and when it is useful.

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 appropriately enumerates the returned product fields. It is reasonably complete for a straightforward lookup tool, though it omits edge-case behavior and authentication context.

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 reinforces that GTINs are barcodes/EANs and that facilityServiceId is optional, but it does not add meaningful syntax or format details beyond 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?

The description uses a specific verb and resource: 'Retrieves product details for a list of GTINs' from Carrefour France. It also clearly differentiates from sibling tools like get_products_by_query by identifying barcode/EAN lookup as the core use case.

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 clear context: bulk product lookups by barcode, with optional facility/store scoping. It does not explicitly name alternatives or exclusions, but the intended use case is evident enough for an agent to select it appropriately.

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 present, so the description must carry the behavioral information. It does so by characterizing the operation as read-only ('Retrieves'), listing the output fields, and explicitly stating that an authenticated Carrefour session is required. It doesn't cover failure modes or session expiration, but for a simple query-style read tool this is reasonable.

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: three sentences covering purpose, output content, and usage context, with the authentication note at the end. It is front-loaded and every sentence contributes useful information, with only minor harmless redundancy around 'query ID.'

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 simple two-parameter tool with no output schema and no annotations, the description covers the main needs: what products are returned, which identifier is used, when to use it, and the auth requirement. It does not fully describe edge cases or response pagination, but nothing essential is missing for most agent uses.

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 schema already documents both query_id and limit well. The description adds a small amount of context around query_id (e.g., curated lists), but it does not add significant parameter-level semantics beyond what the schema already 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 uses a specific action ('Retrieves a list of products'), a clear resource ('Carrefour France'), and a precise mechanism ('predefined query identifier'). It also distinguishes the tool from siblings by noting curated lists such as 'bestsellers, promotions, themed selections'.

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 clearly states when this tool is appropriate: 'fetching curated product lists... identified by a query ID.' It also communicates the authentication prerequisite. However, it does not explicitly mention when not to use it or name alternatives like search_products or get_products_by_gtins.

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 and it does deliver: it discloses the authentication requirement, enumerates the return fields (list reference, title, type, item count, categories, memos/items), and even decodes the 'MTB' type meaning (in-store memo list). It's missing some context like not-found or authorization-error behavior, which would push it higher, but for a simple read tool this is above adequate.

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 efficient sentences with the primary verb and object front-loaded. The first sentence covers action, scope, and return fields; the parenthetical covers the authentication prerequisite. Every clause earns its place, and the inline 'MTB for in-store memo list' example is genuinely useful rather than padding.

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

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

For a single-parameter read tool with no output schema, the description is appropriately complete: it covers return structure, scoping, and the per-parameter semantics are already in the schema. Gaps like empty-list behavior or permission errors would be nice, but the description provides enough for an agent to correctly select and consume this tool among 70+ 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?

Input schema coverage is 100%—the list_id parameter is fully documented as a UUID with its own description. The description adds marginal reinforcement ('specific' list, 'unique list ID') but no new semantic or format details beyond the schema. Per the rubric, a baseline of 3 is correct when the schema does the heavy lifting, and this description neither helps nor hurts the schema's parameter documentation.

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+scope: 'Retrieves the details of a specific shopping list... identified by its unique list ID.' The phrase 'specific... unique list ID' implies a distinction from the plural sibling get_shopping_lists, and it's easily told apart from create_shopping_list. However, it never explicitly names or contrasts against these siblings, so it stops just short of full differentiation.

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

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

The description implies usage context: use when you need detail for one specific list (you have a list_id) and notes the prerequisite that an authenticated Carrefour session is required. However, there is no explicit when/when-not guidance or mention of alternatives like get_shopping_lists for retrieving all lists. The guidance is serviceable but implied rather than stated.

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

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

No annotations exist, so the description carries the full burden. It discloses a read-only behavior (retrieves) and mentions authentication requirement, which is useful. However, it does not state that the operation is non-destructive or detail any side effects, but the read-only nature is clear enough for a basic 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 description is a single sentence, concise and front-loaded with the main action. It efficiently mentions the endpoint's scope and includes a brief note on authentication requirements. No wasted words, though it could be slightly more structured for clarity.

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 simplicity (no parameters) and no output schema, the description covers the key aspects: what it does, authentication requirement, and types of information returned. However, it lacks details on error conditions, response format specifics, or any pagination if lists are numerous, which could be important for an agent.

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?

There are zero parameters, and schema coverage is 100%. The description adds context about the returned data (list ID, title, type, item count, slug, last updated date, EANs), which is valuable beyond the schema since no parameters exist. This enhances understanding of the tool's output.

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

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

The description clearly states the tool retrieves all shopping lists for the authenticated user on Carrefour France, specifying the resource (shopping lists) and scope (all). It distinguishes from 'get_shopping_list' (singular) by implying it returns all lists, but does not explicitly contrast with that sibling.

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 alternatives. It implies usage for listing all shopping lists, but does not mention when to use 'get_shopping_list' (single list) or note prerequisites like session requirements beyond 'authenticated Carrefour session'.

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 burden of behavioral disclosure. It states that it 'retrieves' and 'returns a list of information insert items', implying a read-only operation, and notes the authentication requirement. However, it does not detail what happens on failure, performance characteristics, or any side effects beyond retrieval.

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 concise, consisting of two sentences that cover the purpose, return type, and a prerequisite. Every sentence adds value and there is no redundant information.

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 simplicity (only two parameters, no nested objects), the description is adequate. It explains the purpose, return type, and auth requirement. It does not detail the exact structure of return items, but this is acceptable given the absence of an output schema and the straightforward nature of the operation.

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%, with both store_id and insert_ids fully described with examples. The tool description adds only minimal context (e.g., mentions placements), but does not significantly enrich parameter semantics beyond what the schema already 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 clearly states the action (retrieves), the resource (store-specific information inserts), and the context (for a given store and placement identifiers, during checkout). It also distinguishes itself from siblings by specifying checkout-related placements and referencing Carrefour France.

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 provides clear usage context: it is useful for displaying contextual informational content at specific checkout locations. It also notes the authentication requirement, which is a key prerequisite. However, it does not explicitly mention alternatives or when not to use it, so it falls slightly short of a 5.

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

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

With no annotations, the description carries the full burden. It communicates the read-only nature via 'Retrieves' and adds an auth requirement, plus what fields are returned. However, it does not describe behavior when no valid session exists, whether any side effects occur, or the shape/format of the response.

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 sentences, front-loaded with the main action and resource, and contains no filler. Every clause adds relevant information about scope, content, or prerequisites.

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 no-parameter read-only getter, the description adequately names the auth requirement and the specific returned data (channels and partner preferences). The main gap is the lack of explicit failure-mode or response-structure detail, but the description is otherwise sufficient for selecting and invoking the tool.

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 input schema is empty, so there is nothing for the description to explain about arguments. The description still adds value by clarifying the semantic content of the consent flags returned.

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 ('Retrieves') and names a clear resource ('marketing and communication consent preferences'), scoped to the authenticated Carrefour France user. It also enumerates the communication channels covered, which distinguishes it from sibling tools like get_marketing_placements or get_loyalty_balance.

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 clearly states the key prerequisite ('requires an authenticated Carrefour session') and the returned scope, making it obvious when this tool is applicable. It does not explicitly name alternative tools or exclusions, but no sibling tool overlaps with consent-preference retrieval.

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 are not provided, so the description carries the burden. It mentions 'requires an authenticated Carrefour session' and that it returns a list of products, but it does not disclose potential prerequisites like session refresh, rate limits, or what happens if no vignettes are available. It does not cover data volume or pagination, which might be relevant.

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 brief and front-loaded, with the main purpose in the first sentence. It adds relevant context about Carrefour France and authentication in a concise manner. No redundant sentences.

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 no-parameter, read-only tool with no output schema, the description covers the basic purpose and authentication need. However, it lacks details about response structure (list of products, but no fields), and whether it might return empty or require session refresh. Given the tool is one among many in a large suite, a bit more context could help, but it is adequate.

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% (empty). Since there are no parameters to describe, the baseline is 4, and the description adequately explains the purpose of the returned data, which compensates for the lack of parameters.

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 the tool retrieves the authenticated user's vignette products on Carrefour France, which is a specific resource and action. It distinguishes from siblings by mentioning 'vignette products' (promotional stickers/labels), which is a niche concept compared to general product retrieval tools. However, it doesn't explicitly contrast with similar tools like get_loyalty_coupon_collection or get_loyalty_balance.

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 use when displaying the user's vignette-based promotions, but it lacks explicit guidance on when not to use it or alternatives. It does not differentiate from sibling tools like get_loyalty_coupon_collection, and there is no mention of prerequisites beyond authentication, which is stated.

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

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

With no annotations, the description takes on the burden. It discloses that the result is paginated, includes facets and metadata, and respects the page parameter. It does not disclose potential side effects, but as a read-only search, the absence of mutation cues is acceptable. It adds value by explaining the pagination metadata and facets, which is beyond the schema.

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

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

The description is a single, focused paragraph with clear details. It front-loads the core purpose and adds necessary specifics about pagination and facets. Every sentence contributes to the agent's understanding, with no fluff. It could be slightly more concise by splitting into two sentences, but it's efficient.

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 moderate complexity (2 params, no output schema), the description covers the essential aspects: search query, pagination, and response components. It doesn't explain the structure of facets or navigation links, but these are generic web concepts. It is sufficiently complete for selection and basic invocation, though it could benefit from specifying the default page number.

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 parameters 'q' and 'page' are already well-documented. The description adds value by clarifying that 'page' controls pagination and that the result includes pagination metadata, linking it to the parameter. This is slightly above the baseline of 3 because it integrates the 'page' parameter meaning with the response.

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

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

The description clearly states the tool's purpose: searching for products on Carrefour France using a text query. It specifies the resource (products), the action (search), and the market context (Carrefour France), distinguishing it from related tools like autocomplete_search and get_products_by_query by focusing on keyword-based text search with pagination and facets.

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

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

The description implies usage for product search with a text query, and mentions pagination via the 'page' parameter. However, it doesn't explicitly contrast with siblings like get_products_by_query or get_products_by_gtins, nor does it state when not to use this tool. It provides clear context but lacks explicit 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?

With no annotations provided, the description carries the full burden. It discloses that the tool associates the cart with a slot (a mutation), returns details, and requires an authenticated session. It does not mention failure modes or reversibility, but it covers the key behavior and prerequisites. No contradictions with annotations (none exist).

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

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

The description is four concise sentences, front-loaded with the primary action. Each sentence adds relevant information: purpose, association action, return details, and authentication requirement. There is no redundant or filler 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 simple two-parameter tool, no output schema, and no annotations, the description adequately covers the action, return value (listing the specific fields), and prerequisite. It could optionally add error handling or idempotency notes, but it is complete enough for its complexity.

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%, with both parameters (slotRef and storeRef) already fully described. The tool description does not add any extra meaning beyond what the schema provides, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool selects a delivery or drive time slot for the authenticated user's cart, associates it with a specific store, and returns confirmed slot details. This distinguishes it from siblings like get_delivery_timeslots (which lists slots) and validate_checkout_slot (which likely validates the whole checkout).

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 tool is used to attach a slot to the cart and mentions the authentication requirement. Though it doesn't explicitly state when not to use it or contrast with alternatives, the prerequisite that the slot reference is 'as returned by the get_delivery_timeslots tool' (in the schema) and the context of siblings give clear guidance. It lacks explicit exclusions but is not misleading.

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. It discloses the authentication prerequisite and implies a non-destructive 'simulation', but does not explicitly state whether it modifies the cart or session, or any rate limiting. This is a moderate gap for a tool that could have side effects.

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 sentences plus a parenthetical prerequisite, front-loaded with the core purpose and return value. Every sentence earns its place with no redundancy.

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 tool with no output schema, the description fully covers its purpose, inputs, expected output, and a prerequisite. It is sufficiently complete for an agent to decide when and how to invoke it.

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 schema already explains storeRef as the store reference identifier. The tool description adds no additional meaning beyond that, so it meets the baseline for high schema coverage without adding extra value.

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

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

The description clearly states the tool simulates the current shopping cart against a specific store to check product availability, with a specific verb ('simulates') and resource ('shopping cart'), and distinguishes it from sibling tools by focusing on unavailability checking, not just cart retrieval or ordering.

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 explicitly notes it is useful for determining which cart items cannot be fulfilled before placing an order, and mentions the authentication requirement. While it does not name alternative tools for when not to use it, the context is clear and adequately directs usage.

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

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

With no annotations, the description carries the full burden. It discloses the action (sends chosen payment methods), the return value (total/remaining amounts, available methods, saved methods, payment group), and the requirement of an authenticated session. It does not mention error handling or side effects, but the disclosed behavior is substantive.

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 sentences with no fluff. It front-loads the main action, then describes inputs, outputs, and use case. Every sentence contributes value, making it concise yet complete.

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 complexity (7 params, no output schema), the description covers the return values compensating for the missing output schema, notes the authentication prerequisite, and explains the overall purpose. It lacks explicit error behavior but is otherwise complete enough for an agent to invoke correctly.

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% with detailed descriptions for all 7 parameters, including examples like 'driveclcv' and nested payment object structure. The description reinforces examples but adds no significant new semantics beyond the schema, so the baseline score of 3 is appropriate.

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 and resource: 'Submits payment method selection for the authenticated user's checkout.' It clearly distinguishes from sibling tools like validate_checkout_slot and validate_checkout_summary by focusing on the payment submission 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 description states it is 'Useful for initiating the payment step during checkout' and notes the prerequisite of 'an authenticated Carrefour session.' This provides clear context, though it does not explicitly mention alternatives or when not to use this tool compared to validation siblings.

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 discloses the action (submits a device fingerprint ID) and enumerates the return contents (cart state, checkout step, store context, workflow steps, warnings, checkout links). It also states the authentication prerequisite. It does not explicitly state whether the operation has side effects, but 'validates' suggests read-only behavior.

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

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

Three sentences, front-loaded with the action and resource, then return values and usage context. No redundancy; every sentence carries useful information.

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?

Despite no output schema, the description lists the key return fields and positions the tool in the checkout flow (slot selection before payment). It also covers the required authentication, making it self-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?

Schema coverage is 100% and both parameters are fully described in the schema. The description adds an example for basket_service_type ('driveclcv') and mentions the device fingerprint context, but does not add significant meaning beyond 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?

The description clearly states the tool 'validates the checkout slot step' for a specific basket service type, naming Carrefour France and giving an example ('driveclcv'). It distinguishes from sibling tools like validate_checkout_summary by specifying the slot step rather than the summary 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?

It provides clear workflow context: 'Useful for confirming the slot selection step before proceeding to the payment step.' It also notes the authentication requirement, but does not explicitly name alternative tools or when not to use it.

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. It mentions the need for an authenticated session and that it submits a device fingerprint ID for fraud prevention, which adds context. However, it does not disclose whether the tool mutates state (e.g., creates a checkout session) or is read-only, nor does it describe side effects like updating the cart or invalidating previous steps.

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 paragraph with two sentences, front-loading the main purpose and then listing outputs and usage context. It is concise and avoids redundancy, though it could be slightly more structured with bullet points for the output list, but it remains efficient.

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 has 2 parameters, no output schema, and no annotations, the description does a good job explaining the purpose, required authentication, and what the response contains. It lacks details on error conditions or side effects, but for a validation step it is reasonably complete. The mention of 'requires an authenticated session' is crucial and present.

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 already provides 100% coverage for both parameters, including examples and purpose. The description adds minimal extra meaning beyond the schema, only mentioning that basket_service_type is part of the URL path and that deviceFingerPrintId is for fraud prevention, which is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool validates the checkout summary for a specific basket service type on Carrefour France, and lists the key outputs (cart state, checkout step, store context, workflow steps, warnings, checkout links). It distinguishes itself from siblings like validate_checkout_slot and submit_checkout_payment by focusing on the summary validation step before payment.

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 provides clear context: it is useful for initiating or confirming the checkout summary step before proceeding to payment. It also notes the requirement of an authenticated session. However, it does not explicitly state when not to use it or mention alternatives like validate_checkout_slot, though the sibling list implies such alternatives exist.

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