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

Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false), and the description adds two non-obvious behaviors: quantities are additive rather than overwritten, and combos auto-select their minimum/default spec when selections is omitted. It does not say what happens on failure (invalid linkId, out-of-stock, max quantity) or what the response contains.

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

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

Two short sentences, front-loaded with the core action, with no filler. The bilingual phrasing is a bit dense but each clause carries 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 write tool with annotations covering safety, the description covers the combo-selection edge case but omits error/validation behavior and any notion of the result. With no output schema, the agent gets no hint of what a successful add returns (cart state, line item, etc.).

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 reported at 0%, so the description carries the burden, and it does explain the selections parameter's fallback rule (auto-select minimum portions when omitted) — meaningful beyond the schema. However, the items array shape and the quantity accumulation semantics are only hinted at, and the quantity default/max are left entirely to the schema.

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

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

States a specific verb and resource ("Add dishes to the cart") and names the combo-meal (套餐) case, which distinguishes it from cart_view/cart_remove/cart_clear. It does not explicitly contrast with the closest sibling, cart_set_quantity, so it stops 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?

"数量累加" (quantities accumulate) implicitly signals when to use this over cart_set_quantity, which overwrites, but the agent must infer that contrast rather than being told. No explicit when-to-use/when-not-to-use or prerequisite guidance is given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutability and scope profile is largely covered. The description contributes the useful detail that the removal is wholesale (every dish), but says nothing about idempotency, whether an empty cart is an error, or what state is returned.

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, front-loaded sentences with the scope stated first. The Chinese sentence is a pure duplicate translation and adds no information a monolingual agent can use, which is the only waste.

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

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

For a zero-parameter mutation with annotations and no output schema this is close to sufficient, but the description never says what the call returns or what the cart looks like afterwards, which matters for a bulk clear.

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

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

The tool takes zero parameters, so the schema has nothing to explain and there is no semantic gap for the description to fill. Baseline 4 applies 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?

"Remove every dish from the cart" gives a specific verb (remove) and resource (cart) with a clear bulk scope (every), which distinguishes it in practice from cart_remove. It stops short of naming cart_remove or cart_set_quantity explicitly as the alternatives for partial removal.

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

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

There is no guidance on when to prefer this over cart_remove or cart_remove-per-item, and no statement of prerequisites, confirmation, or side effects. The agent must infer usage entirely from the name and the sibling list.

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 disclose that this is a non-read-only, open-world, non-destructive operation. The description adds scope information—removing exactly one line, identified by lineKey or linkId—but does not explain reversibility, behavior when the line is missing, or side effects beyond the cart line itself.

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

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

Two short sentences with no waste; the core action and targeting method are front-loaded. The bilingual repetition does not obscure the primary instruction.

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 cart mutation with full schema coverage and annotations, the description is largely complete enough to invoke correctly. Minor gaps remain around what happens if the lineKey is invalid or whether removal is reversible, but they are not critical for basic selection.

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 single lineKey parameter is already documented in the schema, including the linkId alternative. The description restates the same targeting information without adding syntax, validation, or error 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?

States a specific verb and resource: remove one cart line, and identifies how the line is targeted (lineKey or linkId). It distinguishes itself implicitly from cart_clear by saying "one line," though it does not explicitly name 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 tool's usage is implied by the operation: use it to remove a line from the cart. However, the description does not explicitly say when to use it instead of cart_clear or cart_set_quantity, nor does it state any prerequisites 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?

The annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the bar is lower. The description adds genuinely non-obvious behavior: quantity 0 deletes the line, an effect not visible from the schema's minimum: 0, and it points at the source of the key (cart_view). It omits any note on permissions, rate limits, or what state the cart is left in afterwards.

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, front-loaded with the core action and the destructive edge case. The Chinese clause restates the English for a bilingual audience; that is defensible but slightly redundant for a single-language reader.

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

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

For a two-parameter mutation with no output schema and annotations covering the safety profile, the description tells the agent the action, the removal side effect, and where lineKey comes from. Missing only post-call expectations (e.g., whether a refreshed cart is returned or cart_view must be re-called).

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 50%: lineKey is documented in the schema while quantity has only min/max bounds. The description compensates for quantity by defining the 0 = remove semantics, which is meaningful, but it adds nothing about the upper bound (99) or about stale/invalid lineKeys.

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

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

States a specific verb+resource ('Set the quantity of one cart line') and parenthetically clarifies the zero-quantity edge case, which distinguishes it from cart_add/cart_clear. It doesn't explicitly name the siblings it supersedes (cart_remove, cart_clear), so an agent must infer the boundary from the parenthetical.

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 one real workflow prerequisite — 'lineKey 来自 cart_view' — which tells the agent where to obtain the required key. However, there is no statement of when to prefer this over cart_add, cart_remove, or cart_clear, so the choice among mutating siblings is left 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 and openWorldHint=true, so the safety profile is covered. The description usefully adds what the response contains (lines, quantities, total), but says nothing about empty-cart behavior, currency, or whether calling it recalculates totals.

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

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

Extremely short and front-loaded, with the return contents stated immediately. The trailing Chinese phrase 查看购物车 is a pure duplicate of the English rather than added information, a minor waste of the limited budget.

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 this is nearly sufficient, and the description does supply return-field information even though no output schema exists. It could go further on empty-cart behavior and its relationship to preview_order, but nothing essential for calling it correctly 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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Not specifying whether the cart is scoped to the current session is a small residual gap, but no parameter exists to control 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?

"Show cart lines, quantities and total" states a specific verb (show), the resource (cart), and what is returned, which distinguishes it from the mutating cart_add/cart_remove/cart_clear siblings. It stops short of explicitly contrasting with preview_order, which also surfaces totals, so an agent must infer the difference from the names.

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 never says when to call this versus preview_order or order_status, nor mentions any prerequisites such as first calling select_store or cart_add. The read-only nature of viewing a cart is only implied by the word "Show".

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real value by disclosing the key output contract (storeCode) and the downstream dependency on select_store. It does not describe result shape beyond storeCode or how limit interacts with the two search modes.

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 English portion is front-loaded with the two lookup modes and the return value in two tight sentences. The trailing Chinese restatement ('查询肯德基门店，返回 storeCode') duplicates information already given, a minor redundancy rather than a structural flaw.

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 correctly covers the essential return value (storeCode) and its consumer (select_store). The remaining gap is that all five parameters are optional, and the description never explains what an empty call returns or how limit defaults behave.

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 every parameter (limit, keyword, cityCode, latitude, longitude) is already documented inline. The description's 'gbCityCode, e.g. 310100 = Shanghai' and 'latitude/longitude' pairing largely restate the schema, so this lands at the baseline 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?

States a specific verb and resource (find KFC China restaurants) and enumerates the two supported lookup modes: keyword + gbCityCode, or latitude/longitude. It also distinguishes itself from the sibling it feeds into by noting the returned storeCode is what you pass to select_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?

Clear context for use: supply keyword + city code, or coordinates, and then hand the resulting storeCode to select_store — this spells out a concrete workflow. It stops short of stating when not to use it or what happens if no parameters are supplied, 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=true and openWorldHint=true, so the safety profile is covered. The description does add genuinely useful return-shape context that no output schema provides — comboRounds with roundId, selectable items, and min/max portions — but it says nothing about the fuzzy-name path (e.g. what happens when the name matches multiple dishes, or when a linkId is not found).

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, front-loaded with the core action and followed by the conditional combo detail. The bilingual duplication is functional rather than wasteful, and no sentence is filler. Slightly dense with parenthetical details but well within bounds.

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

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

For a 2-parameter read-only tool with full schema coverage and no output schema, the description covers the payload shape adequately. What is missing is behavior around fuzzy matching and ambiguity resolution and any pointer to the search tool that would normally precede this call, which matters in a menu-browsing flow.

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

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

Schema description coverage is 100% and both parameters are documented in-schema, including the '模糊匹配' behavior for name and the mutual-exclusivity note '与 linkId 二选一'. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get dish detail') and goes beyond the name by naming what extra payload comes back (combo rounds and option groups). An agent can tell this is a detail-fetch rather than a search, but the description never names the sibling it is distinct from (e.g. search_menu), so the differentiation is inferred from the tool name rather than earned in the text.

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

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

There is no when-to-use or when-not-to-use statement, and none of the sibling tools (search_menu, get_menu) are referenced. The only implicit signal is that combo/option-group information requires this tool, which an agent could glean but is never stated as a routing rule. It also doesn't mention that either name or linkId must be given, even though the schema makes both optional.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context: it operates on the selected store menu and returns categories with item counts or item details including linkId, price, and whether specs are required. It does not mention caching/refresh behavior, but the schema covers that parameter.

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 and efficient: the first sentence gives the primary purpose and modes, and the second adds item-level detail. The bilingual duplication is purposeful for locale, though it is slightly repetitive rather than maximally concise.

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 tool with four optional parameters, full schema descriptions, and no output schema, the description supplies the key return shape: categories with item counts or category items with linkId, price, and spec requirement. Minor omissions around pagination and behavior when no store is selected are acceptable because the schema and annotations cover surrounding 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 description coverage is 100%, so the baseline is 3. The description clarifies the category-based retrieval mode and returned item fields, but it does not add syntax or constraints beyond what the schema already documents for limit, refresh, category, and includeItems.

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 ("List") and resource ("selected store menu"), and distinguishes two retrieval modes: categories with counts vs. items in one category. It does not explicitly differentiate itself from siblings such as search_menu or get_item, so it falls 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 two modes imply when to use the tool: omit category for categories, provide category for items. However, it does not say when to use this instead of search_menu/get_item, nor does it explicitly state the prerequisite of selecting a store first. Usage is only implied.

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?

Read-only and open-world behavior is already covered by annotations, but the description adds genuinely new context: the endpoint is experimental and may require the logged-in account (KFC). It does not say what the status response contains, what statuses are possible, or what happens when the order is not found.

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?

Front-loaded with the core action and kept to one sentence plus a caveat. The bilingual repetition adds length without new information, which slightly dilutes efficiency.

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

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

A one-parameter read-only tool needs little, and annotations cover safety. However, with no output schema the description could reasonably indicate what a status result looks like, and the 'logged-in account' caveat is vague about whose account (merchant vs. customer).

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 single orderId parameter is already documented in the schema as the order number returned by place_order. The description only restates 'by orderId', adding no syntax or format detail (e.g., length constraints) 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?

States a specific verb and resource: check an order status by orderId. An agent can distinguish it from place_order and preview_order by name and description, though the description never contrasts it with session_status or explicitly says it applies to already-placed 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?

Usage is implied (query a placed order using the orderId returned by place_order) but never stated as when-to-use vs. alternatives. The experimental caveat and account requirement are preconditions rather than 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?

Goes well beyond the annotations: annotations only say non-read-only and open-world, while the description discloses that this creates a real unpaid order, that payment must be completed by the diner in the KFC app/H5, and that confirm=true must be explicitly supplied as an intent gate. The Chinese clause reinforces that a real unpaid order is generated — exactly the side-effect context an agent needs before an irreversible-ish action.

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?

Front-loads the action and the prerequisites in a compact multi-sentence block with no filler. The trailing Chinese sentence largely restates the confirm/real-order point, which is a mild redundancy given the target audience is an agent, but it costs little.

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

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

Covers the high-stakes aspects (required token, explicit confirmation, real unpaid order, payment handoff to the app) for a 6-param mutation tool. The one gap is the return shape — there is no output schema and the description never says what comes back (e.g. order id or status), which an agent needs to chain into order_status.

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 every parameter mentioned in the description (confirm, previewToken, phone) is already documented in the schema with equal or greater detail. The description adds nothing about remark, packType, or expectedTotalCents beyond what the schema states, so it sits at the baseline.

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 ('Submit the previewed order to KFC China') and anchors scope to the preview step, which cleanly separates it from preview_order and order_status in the sibling list. An agent can identify this as the commit step of the ordering workflow without consulting the schema.

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

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

Gives concrete preconditions: confirm=true, the previewToken from preview_order, and the diner phone, which implies the required preview_order-first workflow. It does not explicitly say when not to call it (e.g. pending cart changes) or point at alternatives such as cart_view for adjustments, so it stops short of full 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 does add useful behavior beyond the annotations: a 10-minute token TTL and the fact that the current price is locked. But "locks the current price" describes a server-side state change, which is at odds with readOnlyHint=true (no environment modification). The side effect is disclosed, but in a way that conflicts with the declared safety profile rather than clarifying it.

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 core purpose and the place_order handoff are front-loaded in the first clause, and the token TTL is attached where it matters. The Chinese sentence largely restates the first sentence before adding the return-field list, which is mild but real 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?

With no input schema to explain and no output schema available, the description compensates by naming the returned fields and the token validity window, which is the right shape for this tool. The one gap is that a price-lock side effect is never reconciled with the read-only annotation, leaving the agent unsure whether calling this mutates state.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies the tool derives its inputs from existing session/cart context instead of arguments, which is the only semantic question a zero-arg tool raises.

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 (pre-validate price and stock before ordering) and explicitly positions itself relative to a sibling by naming place_order as the consumer of the returned previewToken. It also enumerates what comes back (amount, store, whether login is required, token), so the agent knows exactly what this call yields without opening any schema.

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

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

"before ordering" plus "returns a previewToken for place_order" gives a clear use condition and the downstream call it feeds. It does not name exclusions or say when to skip the preview (for example, when the cart is empty), so it stops short of full when/when-not 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 declare readOnly=true and openWorld=true. The description adds that matching is fuzzy and restricted to Chinese name/description, and that results include linkId, price, and whether spec selection is required. It does not disclose ranking, no-match behavior, or how limit affects results.

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 states the key scope first. The Chinese sentence largely repeats the English sentence while adding return fields, which is slightly redundant but not excessive.

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 gives partial return-value info (linkId, price, spec selection) which is valuable. It still leaves gaps around the limit parameter, result ranking, no-match behavior, and the exact select_store prerequisite.

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 50%: query is described with Chinese examples, while limit is undocumented in both schema and description. The description reinforces that the query must be Chinese name/description, which is useful, but it does nothing to compensate for the undocumented limit parameter.

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+resource: fuzzy-searching dishes in the selected store menu by Chinese name/description. It clearly distinguishes a search action from browse-oriented siblings like get_menu and get_item, though it doesn't name them explicitly.

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

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

The phrase 'selected store menu' implies select_store is a prerequisite, which is useful context. However, it does not state when to use this tool instead of get_menu/get_item browsing or how it relates to cart_add for the returned linkId.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds real state context: this binds session scope and loads a live menu, and that the binding governs every later cart/order call — behavior the annotations cannot convey. It does not say what happens if a store is re-selected or whether the prior binding is replaced.

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?

Front-loaded with the binding action, then the downstream consequence. The bilingual restatement is a faithful translation rather than padding, but it does lengthen the definition without adding 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?

No output schema exists, yet the description covers what is loaded (the live menu) and the lasting effect on session state, which is what an agent needs before calling. Missing only edge-case behavior such as re-selection or invalid storeCode handling.

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 one parameter at 100% schema description coverage, the schema already explains storeCode and its provenance from find_stores. The description restates the binding role of storeCode but adds no format or validation detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: bind the ordering session to one KFC China store by storeCode and load its live menu. That is clearly distinct from find_stores (which locates stores) and get_menu (which presumably reads a menu without binding session state).

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 establishes the sequencing contract — all subsequent cart and order operations target this store — implying this must precede cart_add/place_order. It does not explicitly name find_stores as the prerequisite, though the schema fills that in.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It does add value by enumerating what is surfaced (current store, cart, preview, session age), but says nothing about response shape, freshness, or whether session age has units/format.

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?

Front-loaded with the verb and the returned fields; no filler. The bilingual duplication adds length, but it plausibly serves a locale purpose rather than being redundant 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 no-param, read-only diagnostic with no output schema, the description needs to convey what comes back, and it does list the four data points. Only a note on units/semantics of 'session age' and the response form 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 takes zero parameters, so there are no semantics to explain and the baseline applies. The description correctly doesn't invent parameter 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?

Specific verb 'Show' plus the exact resources returned (store, cart, preview, session age) and a stated purpose (troubleshooting). This distinguishes it reasonably from cart_view and order_status, though it doesn't name those siblings explicitly.

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

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

'For troubleshooting' implies a diagnostic use case, which is helpful, but the description never states when to prefer this over cart_view or order_status, nor any prerequisites. Usage is implied rather than specified.

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