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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so safety is partly covered. The description adds real value beyond them: the cart-creation side effect, the 'preserves other carts' blast-radius statement, the option-ID provenance from get_menu_item_options, and the retry caution that operationalizes idempotentHint=false.

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 short sentences, each carrying a distinct rule, with the add/resolution behavior front-loaded and the retry warning placed last where it matters most. No filler, though the option-ID sentence is a cross-reference rather than core semantics.

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 mutating, non-idempotent tool with 6 parameters, a nested options array, and no output schema, the description covers the operation and cart behavior well but says nothing about quantity, special instructions, or what the call returns. Adequate but with clear gaps given the 0% schema 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% across 6 parameters, so the description carries the full burden. It only gestures at cart_id ('explicit cart'), store_id ('same-store cart'), and option IDs; quantity, special_instructions, the nested option/quantity structure, and all defaults are left completely unexplained.

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+resource (add an item to a cart) and goes further by defining the cart-resolution rule: explicit cart_id, else existing same-store cart, else create one. It does not explicitly distinguish itself from the sibling update_cart_item, so it stops short of a 5, but the core operation is unambiguous.

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

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

It clearly states which branch is taken for cart selection (explicit vs same-store vs create) and gives a genuine 'when not to' instruction: 'Do not blindly retry on unknown outcome.' It does not tell the agent when to prefer this over update_cart_item or remove_cart_item, so it is short of explicit 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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds genuine behavioral detail beyond that: what is destroyed (the cart and every item in it) and the boundary that a submitted order is untouched.

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, zero filler, with the destructive scope front-loaded and the exclusion immediately after. Every sentence earns its place.

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

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

For a single-parameter destructive mutation with annotations covering reversibility and safety, the description supplies the missing semantic context (items deleted, orders unaffected). It omits behavior on an already-empty or invalid cart, but that is a minor gap given the annotation 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?

One parameter with 0% schema description coverage, so the description carries some burden; it does not explain what cart_id refers to or how to obtain it. The name is largely self-explanatory and the schema supplies a format pattern, so this is adequate but not enriched.

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 (Delete) and resource (the specified open cart) plus the blast radius (and all its items). The second sentence distinguishes it from order-cancellation tools, so an agent can separate it from place_order or remove_cart_item without opening a 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?

Provides an explicit when-not: 'Does not cancel a submitted order,' which steers agents away from using this to undo a placed order. It stops short of naming a positive alternative (e.g., calling it only after get_cart when the cart is still open), so it is clear context without full when/when-not/alternatives coverage.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds a modest amount beyond that: the 'open cart' precondition and the fact that quantities and selected options are included in the read.

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 verb and resource, with the identifier and the returned content packed in without filler. Nothing is wasted.

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, and the description partially compensates by stating what the read includes (quantities, selected options). For a one-parameter read tool this is nearly sufficient, though it does not say what happens when the cart is closed, empty, or nonexistent.

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, but it only restates the parameter name ('by cart_id') and omits the pattern constraint (1-100 alphanumeric/dash characters) or any format detail. With only one obvious identifier parameter, the gap is small but real.

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?

Names a specific verb ('Read'), a specific resource ('cart'), and scopes it to a single 'open cart by cart_id', which naturally separates it from the sibling list_carts. It does not explicitly name an alternative, but the singular/lookup framing is unambiguous.

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

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

The phrase 'open cart' implies a precondition (the cart has not been checked out), which is useful routing signal versus list_carts. However, there is no explicit when-to-use/when-not statement or named alternative, so usage must be inferred.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds value beyond them by clarifying that the tip_cents input does NOT alter the cart's stored tip and that no submission occurs, which resolves an ambiguity the annotations alone would not.

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, front-loaded with the core action, then the return fields, then the explicit non-behavior. No filler or repetition; each sentence earns its place.

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

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

With no output schema, the description steps in to name the key return fields (total_cents, preview_hash), which is exactly the gap it should fill. Combined with the annotation-covered safety profile, an agent has enough to invoke it correctly, though cart_id's semantics remain unaddressed.

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 carry parameter meaning. It does explain tip semantics ('explicit tip', 'does not change cart tip'), which is genuinely useful, but says nothing about cart_id's role or the total_cents/preview_hash relationship to inputs, leaving half the parameters undocumented.

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 gives a specific verb+resource ('Read current checkout pricing and selected saved payment card') and distinguishes this preview from the mutation sibling place_order by noting preview_hash is 'for place_order'. It is clear and non-tautological, though it does not explicitly contrast with get_cart, which could also be a candidate for reading cart 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 flow is implied: preview_hash is 'for place_order' and the tool 'does not submit', so an agent can infer this is a pre-submission read step. However, there is no explicit 'call this before place_order' or 'use X instead when Y' instruction, so guidance is implied rather than stated.

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

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

Annotations already declare read-only, idempotent and open-world behavior, so safety is covered. The description adds genuinely useful operational context the annotations cannot convey: it needs a saved session and a manually launched CDP Chrome instance, which tells the agent the call will fail without local browser setup. It does not say what a failed verification returns.

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, zero filler. The action is front-loaded and the prerequisite constraint follows immediately, which is the right ordering for an agent scanning for blockers.

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

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

For a parameterless, read-only verification call with full annotation coverage, the description covers action and prerequisites. With no output schema, it could have said what success/failure yields (boolean vs. account payload), which is the only remaining gap.

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 baseline of 4 applies; there is no parameter semantics for the description to add or omit.

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 ('Verify') and a clear resource ('the connected local DoorDash account'), which cleanly separates it from the order-oriented siblings such as get_consumer_order_status. It does not explicitly name alternatives, so it stops short of a 5, but the resource/scope is unambiguous.

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

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

Usage is only implied: the tool checks whether the locally connected account is authenticated, and the second sentence states the prerequisites. There is no explicit when-to-use/when-not guidance or routing to a sibling, so this is adequate but not directive.

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 grant readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuine behavior the annotations don't: the lookup operates on a 20-order history page, pagination continues via next_offset, and the returned status is history status rather than courier tracking. That is meaningful disclosure beyond structured fields.

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, no filler, with the core operation stated first and the disambiguation and pagination hints following. Every sentence 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?

There is no output schema, and the description usefully mentions next_offset as a return field, but it omits how the offset input relates to paging and provides no guidance on what the status values mean. Adequate but with a clear gap around pagination input semantics.

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% for two parameters, and the description never explains the 'offset' parameter (range 0-10000, default 0). It refers to a 'next_offset' response value but does not tie it to the input offset, and only loosely characterizes order_id as 'order ID/UUID'. With zero schema-level descriptions the description should carry this burden and does not.

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 ('Find') and resource ('an order') plus the lookup key (order ID/UUID), and explicitly scopes the output ('history status, not courier tracking'). It does not name which sibling to prefer versus get_order_operation or get_order_payment_status, so the differentiation is partial rather than complete.

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

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

Gives one concrete procedural hint ('Follow next_offset if absent'), which is real usage guidance, but never states when to choose this tool over list_consumer_orders or get_order_payment_status. Usage is implied rather than explicit.

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, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds useful scope info (single item, one level of nesting) but doesn't note rate limits, caching, or freshness of price data. 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?

One tight sentence, front-loaded with the verb and immediately enumerating return content. Every phrase earns its place with 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?

Covers what the tool returns, which is helpful given no output schema, but omits parameter meaning and any usage context. For a 3-param read tool with zero schema descriptions, more is expected.

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% – only patterns and an enum are documented structurally, not the meaning of store_id/item_id/fulfillment_type. The description says nothing about parameters, so the agent gets no semantic help for any of the three. Below the baseline because no parameter info appears at all in the description.

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

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

Clear verb (read) and resource (menu item options) with an explicit enumeration of what's returned: price, customization groups, min/max constraints, one nested options level. Distinguished from get_restaurant_menu by focusing on a single item's options rather than the whole menu.

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

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

No guidance on when to use this versus get_restaurant_menu or when to prefer it over browsing the menu. An agent must infer that it should call this after picking a specific item. No prerequisites (e.g., store/item must exist first) are stated.

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

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

Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real semantics: the state is 'durable', pending/unknown is explicitly not failure, and it warns against resubmission. That is meaningful behavioral context beyond the annotations, though return shape/pagination are not addressed.

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 tight sentences with the core action front-loaded and the safety warning last. No filler, every clause carries 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 low-complexity read tool whose safety profile is fully covered by annotations, this is nearly complete: it explains purpose, workflow timing, and the meaning of ambiguous states. The only gap is that the set of possible state values and the response shape are never described, with no output schema to fill in.

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

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

Schema coverage is 0% and the single cart_id parameter is documented only implicitly ('for a cart'), with no format, source, or constraint details beyond the pattern in the schema. As a basic identifier it is largely self-explanatory, so this lands at an adequate-but-shallow 3 rather than being deficient.

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?

Gives a specific verb+resource: it reads the durable placement state for a cart, which an agent can distinguish from get_cart (contents) and get_order_status (consumer order tracking). It does not explicitly name a sibling it replaces or complements, 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?

Provides clear situational guidance: use it after submission, and if an order UUID came back, also check payment status. Adds a strong negative rule ('pending/unknown does not mean failed; never resubmit that cart'). It never explicitly routes to or away from named alternatives like get_order_payment_status, so it is context without formal alternative 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?

With readOnlyHint and openWorldHint already declared, the bar is lower, yet the description adds valuable context: it returns provider status code and paid flag, exposes no payment secrets, and notes the paginated history constraint. This goes beyond annotations, though it omits pagination behavior details.

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

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

Two short sentences, front-loaded with the primary action and scope, then return content and security note. 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?

No output schema exists, so the description appropriately describes return fields (provider status code, paid flag). Annotations cover safety. It nearly completes the picture but leaves offset semantics and edge cases (e.g., order not found) unaddressed.

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 mentions the order ownership and 20-order page (implying offset semantics), but does not explain offset/min/max or the order_id pattern. Partial compensation yields 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 (Read) and resource (payment status), scoped to 'an order owned by this account'. Clearly distinguishable from siblings like get_consumer_order_status (general status) and get_order_operation.

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?

Implies scope via 'order owned by this account' and the 20-order page constraint, giving some context about when it applies. No explicit when-to-use vs alternatives (e.g., vs non-existent credential tools) 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact beyond them: results 'may be partial', implying incompleteness that the agent should account for. It does not explain what causes partiality or how to obtain a complete result.

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 padding, and the core action is front-loaded before the partiality caveat. Efficient, though the second sentence is terse enough to be slightly ambiguous.

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

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

For a single-parameter read tool with full annotation coverage and no output schema, the description is mostly adequate. However, it omits the meaning of store_id and the relationship between 'default store menu' and other menu-related siblings, leaving a modest gap for correct invocation.

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

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

Schema description coverage is 0% for the single store_id parameter, which is only constrained by a digit pattern. The description never explains what store_id refers to or how 'default store' relates to it, so it fails to compensate for the documentation gap.

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: reads the default store menu feed, plus category metadata and loaded menu items. This clearly distinguishes it from siblings like get_menu_item_options and search_restaurants, though 'default store menu' is not contrasted with any other menu variant.

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

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

No statement of when to use this tool versus alternatives such as get_menu_item_options or search_restaurants. The only guidance is the implicit caveat 'May be partial', which warns of incompleteness but does not tell the agent when to reach for 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered without the description. The text adds only the 'open carts only' scope constraint and the field set returned; no pagination, ordering, or volume behavior 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 short sentences, with the scope and returned fields front-loaded and the exclusion stated last. No filler, no restatement of the tool name.

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

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

With no input parameters and no output schema, the description usefully carries the return-value information (cart-line IDs, menu-item IDs, subtotal) and the open-cart scope. It would be fully complete if it noted ordering or volume characteristics, but nothing essential 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 is no parameter semantics for the description to explain. Baseline for a no-argument tool is 4.

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?

Uses a specific verb (list) and resource (open carts) and enumerates the payload fields (cart-line IDs, menu-item IDs, subtotal). It also scopes away submitted orders, which contrasts with the order-listing siblings, though it does not name any sibling explicitly.

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

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

'No submitted orders' implies this is the pre-checkout view rather than the order-history view, giving an implicit when-to-use cue. However, it never states the condition under which an agent should prefer this over get_cart, get_checkout_preview, or list_consumer_orders, so routing 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavior: results are paginated and cancelled orders are included, plus a data-semantics note that status is derived from history timestamps rather than stored directly.

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 with no filler, and the core scope constraint is front-loaded. The second sentence on status derivation is useful but slightly disconnected from a listing operation.

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 needn't explain return fields, and annotations cover the safety profile. However, for a list tool with undocumented parameters and many overlapping siblings, the missing usage routing leaves real gaps for an agent deciding whether to call it.

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

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

Schema description coverage is 0%, so limit and offset carry no semantic documentation. The single word 'paginated' signals that the parameters govern paging, but the description never explains default, maximum, or offset behavior, leaving the schema's numeric bounds to speak for themselves.

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 ('Read ... consumer order history') with scope detail ('including cancelled orders'), which distinguishes it from a status lookup. It does not name the sibling get_consumer_order_status or otherwise route the agent, so it is clear but not sibling-differentiated.

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 guidance, no exclusions, and no mention of alternatives such as get_consumer_order_status or the cart/checkout siblings. The paginated-history framing only loosely implies usage, and nothing tells the agent when this is the right tool versus a status or search call.

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 by disclosing that it is 'implemented but not live-tested', that one durable submission attempt exists per cart, and that unknown outcomes must be reconciled rather than retried with a new ID. This ties the idempotentHint=true annotation to concrete reconciliation behavior, which is high-value context for a destructive payment tool.

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

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

Four tight sentences, front-loaded with the destructive nature of the call and each sentence adding distinct operational value. The ALL-CAPS emphasis is a minor stylistic cost but the content is dense and earned.

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 destructive, open-world payment tool with no output schema, the description covers safety, idempotency and reconciliation — the critical gaps. It does not describe the failure/decline response shape or how a reconciled result is retrieved, but the essential calling contract is present.

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

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

With 0% schema description coverage, the description carries the full burden. It explains request_id as a caller-generated UUID and links preview_hash/total_cents/tip_cents to the checkout preview, but leaves cart_id and payment_card_id unexplained and doesn't clarify the relationship between total_cents and tip_cents. Partial compensation only.

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

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

States a specific verb and resource ('SUBMITS A REAL ORDER') and immediately clarifies the side effect ('may charge the selected saved card'). This clearly separates it from the non-mutating siblings like get_checkout_preview and 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?

Explicitly directs the caller to a fresh checkout preview and requires using its exact hash/total and the same tip, which is real when-to-use guidance. It does not name the sibling tool by name or state when NOT to use it (e.g. preview-only flows), so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is structured. The description adds scope context (removes an entire line) but doesn't disclose what destruction means (whether the line can be recovered, affected totals, or auth needs). 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?

Two short sentences, front-loaded with the action and scope, followed by the sibling routing. Zero 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 two-param destructive mutation with no output schema, the description covers the action, target, and alternative. Missing confirmation/irreversibility notes that a destructive tool ideally surfaces, but nothing essential to invoking it correctly is absent.

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 both parameters carry only pattern constraints, so the schema under-delivers. The description partially compensates by naming cart_item_id as the target of removal, but leaves cart_id's role implicit and gives no format guidance. Baseline 3 given low 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?

Specific verb+resource (remove a cart line) with exact scope clarified ('one entire cart line by cart_item_id'). Explicitly distinguishes from the sibling update_cart_item, which handles quantity reduction. An agent can select correctly without opening a 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?

Names the alternative (update_cart_item) and the condition that selects it ('to reduce quantity'). Clear when-to-use-this-vs-that. Lacks explicit negatives (e.g., cannot remove partial quantity), but the contrast sentence carries most of the routing.

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, idempotent, openWorld, non-destructive, so the safety profile is covered. The description usefully adds that results are scoped to the current browser delivery location, which is real behavioral context, but says nothing about result count behavior or why the location constraint matters.

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

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

Two short sentences, front-loaded with the core purpose and immediately followed by the key scoping caveat. No wasted words.

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

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

For a simple two-param read tool the coverage is adequate: purpose, location scoping, and a non-directory caveat. But with 0% schema coverage and no output schema, the missing parameter semantics leave the agent slightly under-informed.

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 there are two parameters. The description adds no meaning for 'query' or 'limit' at all, so the agent gets no guidance on what a valid query looks like or how limit affects matching.

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 (autocomplete search) and resource (restaurants), and clarifies it is match-based discovery, not a full directory. Falls short of 5 because it does not differentiate from siblings like get_restaurant_menu or the ordering tools that the agent would also see.

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 'not an exhaustive directory' note implies usage context (discovery/autocomplete) but never says when to call this versus get_restaurant_menu or place_order. Usage is only loosely 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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=true. Beyond that, the description adds real behavioral context: this is a partial update that preserves existing options, and option changes require a remove/re-add cycle. That is genuinely useful semantics not derivable from 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?

Three terse sentences with zero waste; the set-quantity action and the ID disambiguation are front-loaded, followed by the option-preservation rule and the workaround. Every sentence earns its place.

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

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

For a mutation tool with no output schema and 0% schema description coverage, the description covers the non-obvious behavior (options preserved, change via remove/re-add) that an agent would otherwise guess wrong on. It leaves cart_id purpose and error behavior unstated, but those are minor.

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 carry parameter meaning. It clarifies quantity (the primary set value) and special_instructions ('optionally instructions') and pins down cart_item_id as a cart-line ID rather than a menu-item ID, but says nothing about cart_id or the quantity bounds (1-99) beyond what the schema constrains.

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 (Set/update) and resource (quantity plus optional instructions on a cart-line), and crucially disambiguates cart-line ID from menu-item ID. It implicitly separates itself from remove_cart_item and add_cart_item via the options-change guidance, but never names a sibling explicitly.

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

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

Clear context: use this to change quantity/instructions while preserving selected options, and the description tells the agent to remove and re-add to change options. Includes an explicit when-not path, though the sibling tools it implies (remove_cart_item/add_cart_item) are not named.

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