Lazada Community MCP

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

Annotations already mark non-readOnly, non-idempotent, non-destructive. The description adds useful behavioral context: the shortlist is one-use and prevents duplicate retries, the operation stops on first failure, and no order is placed. It does not detail output/error behavior, but the output schema covers that 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?

Four dense sentences deliver purpose, consumption behavior, retry guidance, promotion workflow, and a clear boundary ('No order is placed') without filler. Every sentence earns its place and the most important action is 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?

For a 3-param mutation tool with an output schema and useful annotations, the description covers preconditions, failure handling, and a significant non-effect. The main missing piece is explicit confirmation semantics for the confirm parameter, but the schema and the retry guidance make the tool callable with reasonable inference.

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?

With 0% schema description coverage, the description must compensate. It adds meaning for shortlist_id ('one-use shortlist') and quantity ('explicit quantities,' chosen after considering promotions), but it does not explain the confirm=true requirement or the group_id/url selection identifiers. The schema provides the mechanical shape, so the description provides partial but incomplete semantic 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 states a clear verb ('Add'), an object ('user-approved choices'), and a key constraint ('explicit quantities'), and the tool name/title make the cart destination clear. It does not literally say 'to cart,' so sibling differentiation from add_to_cart is present but implicit.

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 gives actionable workflow guidance: inspect get_product and discuss multi-buy promotions before choosing quantities, read get_cart before retrying after failure, and no order is placed. It does not explicitly contrast with add_to_cart or state when this tool should be avoided, so it stops short of a full 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?

Annotations already indicate mutation (readOnlyHint=false, idempotentHint=false), so the description adds limited but useful context by specifying the target as the user's live Lazada cart and framing the operation as additive. It does not disclose auth requirements or exact side effects, but the annotations carry the core behavioral 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?

A single sentence with no filler, front-loading the action and object. Every word earns its place.

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

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

For a two-parameter tool with a complete input schema and an output schema present, the description covers the essential operation and target context. It stops short of 5 only because it does not mention session/login preconditions or clarify behavior when the product already exists in the cart.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description's 'units' and 'one product' loosely align with quantity and url but do not add new semantic detail 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 states a specific verb ('add'), a concrete resource ('the user's live Lazada cart'), and a clear scope ('units of one product'). This semantically distinguishes it from siblings like remove_from_cart, set_cart_quantity, and add_shortlist_to_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?

'Use this to...' gives a clear and direct context for when the tool applies. It does not explicitly mention when not to use it or name alternatives, but the usage intent is unambiguous given the sibling set.

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 annotations, it discloses that the session is persisted privately and that no credentials are required. The idempotent/readOnly annotations are not contradicted; the 'call once' instruction supplements, rather than conflicts with, idempotentHint.

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 short sentences carry the essential information with no filler; the core behavior is front-loaded and the usage caveat is placed at the end.

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 tool with an output schema, the description covers purpose, persistence, timing, and polling behavior. It does not detail what happens if called too early, but the instruction to call only after the user finishes is sufficient for this tool's 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?

With zero parameters and 100% schema coverage, the description has little to add, but explicitly stating 'No credential arguments' reinforces that the tool should be called without 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?

States a concrete action — checking completion of human sign-in and persisting the session — and is clearly distinct from login/start_login siblings that initiate sign-in. The 'No credential arguments' qualifier avoids ambiguity with credential-taking login 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?

Explicitly says when to call ('after the user finishes') and adds a negative instruction ('do not poll repeatedly'). It does not name sibling alternatives such as session_status, so the routing guidance is clear but not exhaustive.

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

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

Annotations already mark destructiveHint=true, and the description adds useful detail: omitting label wipes all account-level shopping memory, while order history and cart remain untouched. This goes beyond the annotations by explaining the exact destructive scope.

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 deliver the action, conditional behavior, and explicit non-effects without redundancy. Every clause earns its place.

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

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

For a one-optional-parameter destructive tool, the description fully covers scope, conditional behavior, and boundaries. The output schema exists, so return-value detail is not required here.

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

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

With 0% schema description coverage, the description compensates by explaining that the optional 'label' identifies a named product preference, and its omission triggers a broader delete-all behavior. It adds semantic meaning beyond the bare schema type.

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 a specific verb ('Forget') and resource ('named product preference' or 'all shopping memory'), and explicitly contrasts with cart/order history tools. It is immediately distinguishable from siblings like get_shopping_memory and remember_product.

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 when to use the tool: forget a single named preference or all shopping memory when label is omitted. It also states what the tool does not affect, but it does not explicitly name alternative tools for cart/order modifications.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds value by stating the result is authoritative, includes selected totals, and reflects the live cart, giving the agent a clear sense of what it will receive beyond the annotations.

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 earns its place: it states the action, the resource, and the key outputs with no filler 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 zero-parameter read-only tool with an output schema and strong annotations, this description is complete. The agent has enough information to select and invoke it correctly, and the output schema covers return-value details.

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 has zero parameters, so there are no parameter semantics to document. Baseline of 4 applies because no parameter confusion is possible and the description focuses on the tool's behavior instead.

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 (list) and resource (the user's live Lazada cart) and clarifies it exposes authoritative contents and selected totals. This distinguishes it from mutation siblings like add_to_cart, remove_from_cart, and set_cart_quantity.

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 opening 'Use this to list...' clearly frames the tool as the read-only retrieval operation, which contrasts with the cart-mutating siblings. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous for a zero-parameter getter.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful context beyond those annotations: the exact product data inspected, the caveat that 'contentCoverage: unavailable' should not be treated as a product claim, and the guardrail that Lazada remains authoritative and external enrichment requires user approval.

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 inspection scope in the first sentence and important caveats in the second. Every sentence adds value, and 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?

For a single-parameter tool with an output schema and read-only/idempotent annotations, the description is sufficiently complete. It covers what data is inspected, adds critical caveats about contentCoverage and external enrichment, and does not need to explain return values because an output schema exists.

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

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

Schema description coverage is 0%, so the description must compensate for parameter documentation. It does not mention the 'url' parameter, its expected format, or that the URL must point to a Lazada product page; the schema only provides 'format: uri'. This leaves parameter meaning mostly to inference.

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 ('Inspect') and resource ('Lazada product'), and enumerates the data categories returned: price, stock, promotions, description, specifications, and labelled ingredients/nutrition. It does not explicitly differentiate from siblings like search_products or probe_page, so it stops short of a 5.

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

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

The intended use is implied: use this tool to inspect a Lazada product's details. However, there are no explicit when-to-use versus when-not-to-use instructions or alternatives named, and the 'ask the user before external web enrichment' guidance concerns behavior rather than tool selection.

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?

Adds substantial behavioral nuance beyond annotations: refresh=true avoids double counting, counts are 'observed orders, not lifetime purchases,' 'quantities are unknown,' and cached URLs may be stale. These interpretation caveats are exactly the kind of context annotations cannot convey. No contradiction with annotations — the refresh semantics even help explain why readOnlyHint=false despite the 'Return' framing.

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?

Four sentences, each earning its place: core purpose, refresh semantics, interpretation caveats, and a routing pointer. The purpose is front-loaded, and sentences 3 and 4 pack two related facts each via semicolons without bloat.

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

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

The output schema covers the return shape, and annotations cover safety and idempotency. The description covers the genuinely tricky semantics: double-counting on refresh, count interpretation, quantity limitation, cache freshness, and the need to verify price elsewhere. The only real gap is the implicit query parameter, a minor omission against an otherwise complete picture.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains refresh=true ('incorporates the recent-order window without double counting'), but the query parameter is never named or described — its role as a product lookup term is only implied by the tool's overall purpose. One of two parameters is left to inference.

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

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

States a specific verb and resource: 'Return account-scoped product frequency, observed orders, and remembered choices.' This clearly distinguishes it from siblings: get_product handles current price/promotions, search_products handles discovery, and remember_product/forget_shopping_memory handle memory writes and deletes. The title 'Your Usual Groceries' reinforces the recall role.

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

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

Explicitly routes to an alternative with a condition: 'verify current price and promotions with get_product,' and explains when to set refresh=true ('incorporates the recent-order window'). However, it never explicitly distinguishes itself from the closely related memory siblings remember_product and forget_shopping_memory, leaving part of the routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well established. The description adds useful behavioral scope by specifying that it returns either the saved or currently selected address, and that it operates on the user's Lazada account context.

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, tightly written sentence with no filler. It front-loads the action ('read') and the object ('saved or currently selected delivery address'), making it immediately scannable and 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?

For a zero-parameter read-only tool with robust annotations and an output schema, the description is complete. It tells the agent what resource is being accessed and the account scope, while the output schema handles return-value expectations.

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

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

The tool takes zero parameters and schema_description_coverage is 100%, so there is no parameter detail for the description to add. With no parameters, the baseline for this dimension is 4, and the description adequately conveys that the operation is context-dependent rather than argument-driven.

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 the specific verb 'read' and clearly identifies the resource: the user's saved or currently selected delivery address for their Lazada account. This distinguishes it well from sibling tools like list_delivery_slots, which concern delivery time slots rather than address 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 gives clear context: use this when you need to read the saved or currently selected delivery address. It does not explicitly name alternatives or exclusion conditions, but the use case is scoped enough for an agent to select it confidently.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context that the data is the 'currently shown' checkout snapshot, but it does not disclose return format, pagination, or any other behavioral traits. The output schema covers return structure, so a mid-range score is appropriate.

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

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

The description is a single, front-loaded, waste-free sentence. It immediately says 'Use this to read' and provides the essential scope 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 zero-parameter, read-only tool with an output schema, this description is complete. It tells the agent what the tool does, what scope the data represents, and the surrounding annotations plus output schema cover safety and return shape.

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 there is no parameter documentation burden on the description. The schema already fully covers this aspect; the description's reference to 'currently shown at checkout' reasonably anchors expectations about what the returned data represents.

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 a specific verb ('read') and resource ('delivery options currently shown at checkout'), which distinguishes it from sibling tools like select_delivery_slot and review_checkout. The scope is precise: it is a read-only listing of checkout-visible delivery slots.

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 it when you need the delivery options currently at checkout. It does not explicitly list exclusions or alternatives, but the sibling tool name select_delivery_slot strongly implies the contrasting selection use case, making the intended use 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description's 'read' is consistent with those. It adds scope information ('recent' orders from the user's account) but does not disclose additional behavior such as default limit, ordering, or session requirements. Given the annotations, this is 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 a single, direct sentence without filler. It places the action first and conveys the essential purpose immediately, with every word earning 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 one optional parameter, clear annotations, and an output schema, so the description does not need to explain return values. It covers the key context of reading orders from the user's account. The only real gap is the undocumented 'limit' parameter, which is minor given the 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?

Schema description coverage is 0% and the description never mentions the 'limit' parameter. The schema provides only type and min/max constraints, not semantic meaning, and the description does not compensate. An agent must infer that 'limit' caps the number of returned orders, so the description adds zero parameter-level 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 states a specific action ('read recent orders') and a specific resource ('the user's Lazada account'), which clearly defines the tool's purpose. It is unambiguous and distinct from sibling tools, none of which overlap with listing orders.

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

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

The phrase 'Use this to read recent orders...' explicitly tells an agent when to invoke this tool. It does not name alternatives or exclusions, but for a simple list-read operation the context is sufficiently 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?

Beyond annotations, the description reveals that the tool opens a visible window,returns promptly, and requires human interaction. It also states a critical constraint about not handling credentials, which is valuable behavioral context not present in the structured metadata.

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 unnecessary words. The first sentence states the action and follow-up, and the second adds a mandatory safety constraint. It is concise and properly 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?

With zero parameters and an existing output schema, the description covers the core usage and constraints sufficiently. It could be more complete by explicitly distinguishing from the sibling 'start_login,' but the given text still provides enough context 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?

The input schema has zero parameters and 100% coverage, so there is nothing additional for the description to explain. The description does not mention parameters, which is appropriate; the baseline of 4 applies for a parameter-less 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 opens with a specific action: 'Start or reuse a visible sign-in window and return promptly,' which clearly identifies the tool's purpose and resource. It also distinguishes itself from session capture by instructing 'after human sign-in call capture_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 gives clear workflow context: use this to start or reuse the visible window, then call capture_session after human sign-in. It also enforces a boundary with 'Never ask for or pass credentials, OTPs, or captcha answers through chat.' It does not explicitly name alternatives like start_login or session_status, so exclusions are absent.

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

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

Annotations already flag destructive behavior, but the description adds critical context beyond them: real money is spent and explicit user approval of the exact reviewed total is required. This helps the agent understand the real-world weight of the action and the need for human confirmation.

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, each earning its place: the first gives the precondition, the second states the consequence, and the third gives an exclusion. It is front-loaded with the most important usage constraint and contains no 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 fully documented input schema, the output schema, and annotations, the description covers the essential operational context: when it is allowed, what is at stake, and when it must never happen. Nothing needed for correct invocation appears to be 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?

Schema description coverage is 100%, so every parameter is already documented. The description does not add parameter-level details, but it reinforces the linkage between review_token, expected_total, and the exact approved review, which is useful contextual emphasis.

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 name and title clearly identify the action as placing a Lazada order, and the description reinforces the consequence by stating 'This spends real money.' It does not explicitly restate the verb 'place,' but the intent is unambiguous from the tool name, title, and surrounding checkout 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 gives explicit, actionable usage rules: use only after showing the immediately preceding review_checkout result and receiving explicit approval of that exact review. It also forbids unattended use, which is strong, unambiguous guidance for an agent deciding when to invoke the tool.

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

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

The description discloses a concrete side effect beyond the annotations: 'It may write a local screenshot and report under debug/.' This is valuable because readOnlyHint is false and destructiveHint is false, so the agent learns that the tool can create local artifacts without being told that by the structured metadata. It does not contradict the annotations.

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 entire description is a single well-structured sentence that front-loads the most important information: when to use the tool, the scope restriction, and the side effects. There is no redundant wording 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 small diagnostic tool with only two parameters and an output schema, the description covers the key operational context: allowed inputs, triggering condition, and side effects. It does not describe the output content or the behavior on non-allowlisted URLs, but the output schema and the explicit 'only for an allowlisted URL' restriction mitigate these gaps.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the parameters. It partially does: 'allowlisted Lazada Singapore URL' gives selection criteria for the url parameter, and 'may write a local screenshot' implies the role of the screenshot boolean. However, it does not explicitly state how the screenshot parameter controls behavior, defaults, or what the report contains, leaving some ambiguity.

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

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

The description clearly identifies this as a diagnostic tool for probing a Lazada Singapore page, with a specific trigger condition ('when a selector fails'). This distinguishes it from the broader e-commerce action tools in the sibling list, which perform operations like login, search, cart, and order placement.

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 explicit usage context: 'Use this diagnostic only for an allowlisted Lazada Singapore URL when a selector fails.' This clearly states when the tool is appropriate and imposes a scope restriction. It does not explicitly name alternatives or state when not to use it, but the 'only' and 'diagnostic' framing provides strong guidance.

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

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

Annotations already indicate this is not read-only, is idempotent, and is not destructive. The description adds the conceptual behavior that saving is a suggestion rather than a purchase action, but does not explain what happens on repeated saves, whether existing memories are overwritten, or how the stored data is later used.

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

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

Two short sentences convey the core purpose, optional parameters, usage condition, and a key boundary. There is no redundant wording, and the most important information is 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?

For a simple save-to-memory tool, the description covers what to do, when to do it, and what not to overinterpret. It leaves some parameter semantics and idempotency details implicit, but the annotations and output schema fill part of that gap, and the tool is not highly complex.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter explanations. It clarifies that quality and quantity are optional preference details, but it does not define the roles of label and url beyond calling them a 'product', nor does it explain the meaning of quantity bounds or how these values interact with shopping memory.

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

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

The description states a specific action ('Save a product') with a clear resource and scope, and adds an important boundary: it is a future suggestion, never purchase approval. This clearly differentiates it from purchase-related siblings like add_to_cart and place_order.

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 limits use to when the user asks to remember their preference and warns against interpreting it as purchase approval. It does not name alternative tools explicitly, but the 'only when' phrasing provides clear usage 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?

The description explicitly discloses the destructive nature ('permanently remove'), which aligns with and adds context to the destructiveHint annotation. It also clarifies exactly what is affected ('one named line') and that it operates on the 'live' cart, going slightly beyond the boolean annotation.

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, tightly worded sentence that front-loads the action, scope, and irreversibility. There is no filler, repetition of the title, or unnecessary detail.

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 rich annotations and an output schema, this description is sufficiently complete. It states the action, target, scope, and destructive nature. It does not cover prerequisites like an active session, but that is largely implied by the cart-focused sibling context and annotations.

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

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

The schema has 0% description coverage and only an item_name string with minLength 2. The description compensates by framing the operation around a 'named line', making it clear that item_name is the identifier of the cart line to remove. Some ambiguity remains about exact matching behavior, but the mapping is strong.

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 ('remove'), a specific resource ('one named line from the user's live Lazada cart'), and the irreversible nature ('permanently'). This clearly distinguishes it from siblings like set_cart_quantity or select_cart_items, which modify or select rather than remove.

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 when a named line must be permanently removed from the active cart. It does not explicitly mention alternatives or exclusions, but the wording 'one named line' and 'live cart' provides enough situational clarity for this simple operation.

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

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

The annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context about rendering UI in MCP Apps clients and preserving JSON/image-URL fallbacks, which goes beyond the structured annotations. No contradiction with annotations.

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 dense sentences with no filler: first states the core behavior, second gives sequencing and UI guidance, third covers fallback. The most important information is 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 the rich annotations (read-only, idempotent, non-destructive), the presence of an output schema, and a 50%-covered input schema, the description covers the essential invocation context: when to call, what UI to produce, and what fallback exists. No critical operational detail needed for correct invocation appears 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 describes the non-obvious 'selections' parameter well: it restores only explicitly selected choices and quantities, and 'does not add anything'. 'shortlist_id' is self-evident from the phrase 'saved shortlist', so the description does not need to elaborate further.

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

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

States a specific verb ('Display') and resource ('a saved shortlist') and gives the exact UI format: a comparison table followed by labelled product-photo cards. It also distinguishes itself from the sibling workflow by saying to call after shortlist_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?

Explicitly instructs when to call the tool ('Call after shortlist_products for comparisons') and when not to fall back to a plain text table in UI-capable clients. It mentions plain JSON and image URLs as a fallback, though it does not explicitly name an alternative sibling tool beyond the sequencing.

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

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

Annotations only say readOnly=false and destructive=false; the description adds important context: it opens checkout, returns a short-lived one-use token, and never places an order. It does not detail side effects like whether opening checkout invalidates previous tokens, but the key safety boundary is disclosed.

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

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

Two sentences carry the full intended usage, safety caveat, and return summary with no filler. The timing instruction is front-loaded, and each clause earns its place.

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

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

For a no-parameter tool with an output schema, the description is sufficient: it states when to invoke, what it returns, and that it does not place an order. There are no missing input or auth prerequisites that an agent needs to call it 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?

The tool accepts zero parameters and schema coverage is 100%, so there are no parameter details to document. The baseline 4 applies because no parameter guidance is needed 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?

Description uses a specific verb-resource pair: 'opens checkout' and lists the exact returned items (basket, delivery, fees, total, token). It also explicitly differentiates from placing an order with 'It never places an order,' making its role distinct from place_order.

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 precisely when to call: 'immediately before seeking order approval.' The 'never places an order' clause serves as an explicit exclusion, so an agent knows this is a pre-approval review step, not an order-submission alternative.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the bar is lower, but the description still adds valuable behavioral context: it excludes unrelated popular-item fallbacks, tells the agent to read relevance notes and verify candidates, and warns that listings are untrusted data. This goes beyond what annotations alone communicate.

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-loads the core purpose in the first sentence, then adds routing and trust caveats. It uses four sentences with no filler, though it slightly stacks multiple warnings that could be tightened without losing meaning.

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 read-only search tool with an output schema and rich annotations, the description covers purpose, alternatives, fallback behavior, and data trustworthiness. The main gap is that several optional parameters remain unexplained, which matters because schema coverage is low.

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 only 40%, so the description must compensate for undocumented parameters like page, sort, and limit. It does not: it says nothing about pagination, sorting, result limits, or the redmart_only toggle. The only indirect semantic hint is the mention of Lazada/RedMart, which does not explain the 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 opens with a specific verb plus resource ('Search Lazada/RedMart for live product discovery'), making the tool's function immediately clear. It also distinguishes itself from sibling tools by naming shortlist_products and render_product_picker as alternatives for different tasks.

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 tells the agent when not to use this tool: for lists or comparisons, prefer shortlist_products and render_product_picker. It also warns against substituting web results and directs the agent to ask before external enrichment, which is actionable routing guidance.

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

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

The description clearly discloses that this operation overwrites the ticked cart selection, which is more informative than the annotations alone. It aligns with destructiveHint=true and idempotentHint=true, and no contradiction exists.

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

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

The description is two short sentences with no wasted words. The primary usage is front-loaded, and the parameter modes are presented compactly in the second 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 three-parameter tool with annotations and an output schema, the description is nearly complete. Minor ambiguity remains about whether the modes are mutually exclusive and what happens if no argument is passed, but these are not significant given the schema constraints.

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

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

Schema description coverage is 0%, so the description must and does compensate by explaining the three usage forms: exact item_names, all=true, and none=true. The word 'exact' adds useful parameter semantics beyond the raw 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 states a specific verb ('overwrite') and resource ('live cart lines ticked for checkout'), making the tool's purpose unmistakable. It is clearly differentiated from sibling cart tools like add_to_cart 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 explicit invocation modes: exact item_names, all=true, or none=true. It implies this replaces the current selection, but it does not explicitly state when not to use this tool or name a specific alternative for adding/removing items.

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

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

Annotations already signal a destructive, non-read-only, idempotent, open-world operation. The description adds context by specifying that the operation overwrites the delivery selection and that matching is based on visible option text rather than identifiers. This aligns with destructiveHint=true and provides useful behavioral detail beyond the annotations.

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, direct sentence with no filler. The action, target, and matching strategy are all front-loaded, making it easy 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?

Given a simple one-parameter tool, strong annotations, and an output schema, the description covers the essential behavior. The reference to list_delivery_slots in the parameter description fills the remaining gap about where the match text comes from. It could go a step further by stating exact-match requirements, but this is not a major omission.

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 solid. The description adds meaning by clarifying that the 'match' parameter corresponds to visible option text, not just any string. This complements the schema's 'Text from list_delivery_slots' and gives the agent a clearer model of how the parameter is used.

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

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

The description states a specific action ('overwrite'), a specific target ('checkout delivery selection'), and the mechanism ('matching visible option text'). This clearly distinguishes it from the read-oriented sibling list_delivery_slots and other checkout 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 clearly indicates when to use the tool: when the checkout delivery selection needs to be overwritten. It also implicitly points to list_delivery_slots as the source of the match text via the parameter description, which provides practical guidance. However, it does not explicitly state when not to use it or name 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds meaningful behavioral context by specifying that no browser is launched and no connection to Lazada is made, reinforcing the annotation signals without contradicting them.

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, compact sentence that front-loads the core action and resource, then adds the key scoping constraint. Every word earns its place and 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 tool's simplicity, zero parameters, rich annotations, and presence of an output schema, the description is fully sufficient for an agent to select and invoke the tool correctly. Nothing important 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 tool has zero parameters and schema coverage is 100%, so there is no parameter burden for the description to carry. The baseline for no-parameter tools is 4, and the description adds no unnecessary parameter-related text.

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 exact action ('Read') and the specific resources ('service version and browser mode'), and it explicitly distinguishes itself from connection-oriented tools by noting it does not launch a browser or connect to Lazada. This clearly separates it from siblings like 'login' and 'start_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 implies this is a safe diagnostic read that can be used without establishing a connection, but it does not explicitly state when to prefer it over alternatives or when not to use it. The negative constraints ('without launching a browser or connecting to Lazada') give context but no direct routing to or away from 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds the 'live cart line' context and reinforces the destructive overwrite behavior, but it does not go much beyond what the annotations already communicate.

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, direct sentence with no filler. The key action is front-loaded and every word contributes to meaning.

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, the existing output schema, and the annotations covering destructive/idempotent behavior, the description is mostly complete. It could be slightly richer about the 'live cart line' concept, but nothing critical is missing for a basic call.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It loosely maps 'named' to item_name and 'quantity' to quantity, but it does not clarify constraints such as the 1-50 quantity range, exact-match requirements, or what happens if the named line does not exist. This is only minimal compensation.

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 ('overwrite') and a specific resource ('quantity of a named live cart line'), clearly distinguishing it from sibling tools like add_to_cart or remove_from_cart. The phrasing makes the tool's core action unmistakable.

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?

'Overwrite the quantity of a named live cart line' gives clear context that this tool is for modifying an existing cart line. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to infer the intended 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?

Annotation Contradiction: readOnlyHint=true suggests no state change, but the description says 'Create saved Lazada shortlists' and 'Drafts survive restarts,' implying persistent state is written. 'Nothing is added' does not fully reconcile this contradiction with the readOnlyHint annotation.

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 usage context. Every sentence adds meaningful guidance, including persistence, expiry refresh behavior, and an error-handling caution. None of it is 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?

The description provides useful operational details like draft persistence, price refresh after expiresAt, and the next-step tool. However, the contradiction with annotations and the lack of parameter-level guidance leave gaps in the full calling context, especially given zero schema description coverage.

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

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

Schema description coverage is 0%, so the description must compensate for items and limit_per_item. It only hints at 'missing quantity/quality questions' and doesn't clarify the item object fields, limits, or limit_per_item behavior. This is insufficient for low schema 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 clearly identifies the tool's function: creating saved Lazada shortlists with product comparison details. It also names its downstream sibling, render_product_picker, and distinguishes its scope ('ambiguous items, lists, and comparisons') from the other sibling 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 explicitly states when this tool is preferred and instructs the agent to follow up with render_product_picker. It doesn't explicitly state when not to use it versus alternatives like search_products or get_product, but the preference context is strong enough for selecting this tool.

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

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

Annotations already indicate this is non-read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond those hints: it returns promptly, names the actual browser, and has a specific environment requirement. It also clarifies the assistant should not solicit cookies or credentials. This is valuable but does not fully describe side effects or state changes, so a 4 is appropriate.

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 compact sentences with no filler. It front-loads the core purpose, then adds the most decision-relevant behavioral and environmental details, each earning 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 the tool has no parameters and an output schema exists, the description covers the essential context: what the tool does, how it behaves, where it can run, and what the agent should not do. Nothing critical is missing for an agent to select and invoke it 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?

The tool has zero parameters, so there is no parameter information for the description to add. The schema already fully covers the input surface, and the description is not required to explain parameters. The baseline of 4 for zero-parameter tools applies.

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

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

The description states a clear action: 'Start or reuse human sign-in,' naming both the verb and the resource (sign-in). It also gives concrete behavioral outcomes (returns promptly, names the actual browser), which helps distinguish it from a generic login. However, it does not explicitly contrast with the sibling tool 'login', so differentiation is implicit rather than explicit.

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

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

The description provides clear operational context: it is for starting or reusing a human sign-in, and it specifies a remote VM prerequisite ('requires the configured host browser'). It also gives an important exclusion: 'never ask for cookies or credentials in chat.' It stops short of naming alternative tools or explicit when-not-to-use conditions, so it is not a full 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds useful context about inspecting the local browser profile and returning sign-in status plus account identity, without contradicting the annotations.

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

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

A single sentence that front-loads the action, states the resource, and conveys the key outcome without any 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-only check with a full annotation safety profile and an output schema, the description is complete. Nothing material is missing for an agent to decide whether 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?

The tool accepts zero parameters and the input schema has no properties, so the description has no parameter burden. This aligns with the baseline for zero-parameter 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?

The description uses a specific verb ('check') and identifies the exact target: whether the local Lazada browser profile is signed in and which account it represents. It is clear and specific, though it does not explicitly differentiate from sibling tools like session_status.

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

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

The phrase 'Use this to...' gives direct usage context, but no alternatives or exclusions are mentioned. Sibling tools such as session_status and capture_session may overlap, and the description does not clarify when to prefer one over the other.

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