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

With no annotations, the description carries the full burden and does well: it declares this is a write action, that the cart is scoped per store while multiple carts may coexist, and that adding is not purchasing and requires user confirmation. It stops short of saying what happens on failure (item unavailable, option mismatch) or whether the response returns the updated cart.

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

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

Front-loads the action and its write nature, then parameter semantics, then two short bullets with genuinely non-obvious constraints. Every sentence adds information an agent would otherwise have to guess; nothing is padded.

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

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

For a 3-parameter write tool with no annotations and no output schema, the description supplies the mutation semantics, the cart-per-store model, the confirmation workflow, and the verification tool to call next. That is enough for correct invocation without further discovery.

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 a baseline of 3 would apply, but the description goes beyond it: it explains the spec string as space-separated keywords, one per option group, matched level by level, with concrete examples in two languages ('Coke Large' / 'コーラ ポテト(L)'). That materially disambiguates a free-text parameter the schema only labels '选项关键词，空格分隔'.

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 one item to the cart') and immediately qualifies it as 'a write action', which separates it from read-only siblings like ue_search/ue_cart. The closing note 'Adding is not buying' implicitly draws the boundary with ue_place, so an agent can place the tool without opening other schemas.

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 the agent to ue_cart for post-add verification and instructs 'Confirm with the user before adding anything', which is meaningful pre-use guidance for a mutating tool. It does not, however, state how to obtain the required id (that guidance lives only in the parameter schema, pointing at ue_store).

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

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

With no annotations, the description must carry behavioral disclosure. It usefully discloses return fields and sort order, but does not explicitly state that the operation is read-only and side-effect free, nor does it mention pagination, limits, or authorization requirements.

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

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

The description is front-loaded with the core behavior, then uses a compact "Use this when" list. Every sentence adds actionable information 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?

For a zero-parameter tool with no output schema, the description adequately explains what is returned and in what order, and links the draft_id to ue_review. It could be slightly more complete by noting scope or read-only safety, but the essential context 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?

The tool has zero parameters, and the description correctly focuses on output rather than input semantics. There is no parameter ambiguity to resolve, so the baseline is a 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 and resource ("List the carts"), clarifies cardinality ("one per store"), and enumerates the returned fields (draft_id, store, items) plus ordering ("most recently changed first"). This is enough for an agent to distinguish it from sibling tools such as ue_add or ue_review.

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 explicit when-to-use guidance: after adding an item to confirm it landed, or when the draft_id is needed for ue_review. It does not state when not to use it or name an alternative listing tool, so it falls 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?

No annotations exist, so the description carries the full behavioral burden. It adds genuine value by prescribing the post-ue_place verification flow, but it never states that this is a read-only operation, whether completed/historical orders are included, or how fresh the delivery progress is. With no output schema either, more disclosure was warranted.

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 lines: a front-loaded statement of what it returns, followed by a bulleted 'use when' list. No filler, no repetition of the name, and the most actionable content (call it after ue_place) comes first.

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

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

For a no-parameter read tool with no output schema, the description supplies the decision context an agent needs to call it at the right moment. It is slightly thin on what 'delivery progress' actually contains (status granularity, ETA, history scope), which is the one 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 per the rubric the baseline is 4. The empty schema leaves nothing to clarify, and the description correctly focuses on invocation timing rather than argument syntax.

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 the resource (active orders) and the payload (delivery progress), which is enough for an agent to distinguish it from ue_cart, ue_search, and ue_place. The verb is only implied — there is no explicit 'retrieve/list' — so it falls just 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?

Gives two concrete trigger scenarios and ties them to a sibling tool's outcome: confirm after ue_place, especially when ue_place returned unknown or an error, and check while the order is in transit when the user asks location. That is explicit when-to-use guidance with a named alternative (ue_place) and a failure-recovery condition.

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

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

No annotations exist, so the description carries the full burden and does so richly: it discloses the re-read validation gates (total/store/cart), the per-order and per-day caps, the refusal behavior, the idempotency hazard (a second press is a second charge), and crucially the ambiguous-failure semantics ('status unknown ... does NOT mean it failed'). That is exactly the context a mutating, money-moving tool needs.

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 precondition, then segmented into when-to-use and notes. Every sentence carries operational weight (gates, ambiguous failure, double-charge) 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?

With no annotations and no output schema, the description still tells the agent everything needed to call it safely: prerequisite token source, what is validated server-side, what refusal means, and how to reconcile an uncertain result. Nothing material 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?

Schema coverage is 0% and the single parameter is undocumented in the schema, so the description must compensate. It does: confirm_token is stated to come from ue_review and to be re-validated against the snapshot and caps. It stops short of describing format/expiry/lifetime, so not a 5.

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 ('Place the order') with unambiguous scope, and names the sibling it depends on (ue_review) and the sibling used to verify outcome (ue_orders). An agent can distinguish it from ue_review and ue_orders 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?

Explicit when-to-use gate ('The user has explicitly said yes to the exact review you showed them. Only then.'), plus an explicit when-not ('Never call ue_place again for the same cart'). Alternatives and preconditions are named, not 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?

With no annotations, the description carries the disclosure burden and does well: 'Read' implies a safe, non-mutating call, and it reveals the surprising environmental dependency on Uber Eats being logged in via Chrome, plus that caps are expressed in the account's currency. It omits failure modes (e.g., what the tool returns when logged out) or rate-limit behavior, which keeps it from a 5.

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 parts: a front-loaded enumeration of the returned fields followed by a single tiered bullet with the usage trigger. No sentence is padding, and the most decision-relevant information (caps, spend, login state) comes first.

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?

Because there is no output schema, the description must describe the return payload, and it does so field by field, including the login-state value an agent may need to branch on. It doesn't cover what happens when ordering is disabled or when Chrome isn't logged in, leaving a small behavioral gap for a tool whose whole purpose is gating downstream actions.

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 zero parameters, so the baseline is 4 per the rubric. Nothing in the description contradicts or adds parameter meaning, and none is needed.

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

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

States a specific verb ('Read') and resource ('the ordering policy') and then enumerates exactly what the policy contains: enabled flag, per-order/per-day caps, today's spend, and Uber Eats Chrome login state. This is clearly distinguishable from siblings like ue_add, ue_cart, and ue_place, which mutate or inspect cart/order state rather than policy limits.

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 'Use this when' block gives an explicit trigger: before adding to cart or placing an order, check the caps. It clearly signals the pre-flight role relative to ue_add and ue_place, but does not name those siblings or state when this tool is unnecessary, 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?

With no annotations, the description carries the full burden and does well: it discloses that data is read from the checkout API keyed by draft rather than the rendered page, that two independent anchors 'throw instead of mixing two carts' (error rather than silent cross-contamination), and that the confirm_token is valid ~10 minutes and single-use. It stops short of stating permissions/auth needs or any throttling, so not a full 5.

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 purpose in the first clause, then a short 'Use this when' block. The mid-sentence field enumeration is long, but since there is no output schema it earns its place by telling the agent what will come back. The phrasing 'two independent anchors that throw' is slightly opaque but compact.

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

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

There is no output schema, so the description deliberately enumerates the returned fields (store, items, subtotal, fees, total, ETA, address, payment method) plus the confirm_token lifetime and single-use constraint. Combined with the usage ordering against ue_place, an agent has everything needed to invoke and act on this tool correctly.

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

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

Schema description coverage is 100% and there is only one optional parameter, so the schema already documents `draft`. The description adds only the conceptual framing ('keyed by draft (not the page)'), which is useful context but not parameter-level syntax or default behavior beyond what the schema states.

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: 'Checkout snapshot for one cart', then enumerates exactly what the snapshot contains. It is clearly distinguishable from siblings ue_cart (mutable cart state) and ue_place (order submission) because it positions itself as the trusted read-back step between them.

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 'Use this when' block gives an explicit condition and an explicit next step: call before placing an order, show the user exactly what is returned, and only call ue_place after confirmation. It names the alternative tool (ue_place) and the gating condition, so the sequencing is unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It discloses useful behavior: delivery to the account's current address, country coverage, and that product queries surface supermarkets/drugstores with prices. It omits auth/permission requirements and rate or result-limit behavior, so it is good but not comprehensive.

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

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

Front-loads the core capability, then a short conditional block. Mostly tight, though the 'real food and real money' clause is a bit of editorializing that doesn't directly help tool selection.

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 search tool with a complete schema and no output schema, the description covers what is searched, what results look like for product queries, and when to invoke it. Missing only permission/limit behavior and explicit sibling routing.

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 query (store/dish/product keyword) and limit (default 10) are already documented in the schema. The description restates that queries span store names, dishes and products but adds no new syntax, format or constraint detail, so the baseline 3 applies.

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

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

States a specific verb (Search) and resource (Uber Eats) plus the searchable scope: store names, dishes, products. The note that product searches return supermarkets/drugstores with matching items and prices makes the resource behavior concrete and separable from siblings like ue_store or ue_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 'Use this when' block gives an explicit triggering condition (user asks for delivery, e.g. '点个 X' / 'order me X') and a caution against initiating delivery orders autonomously. It does not name alternatives (e.g., use ue_store to browse a specific store's menu), so the routing guidance is clear but not complete.

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

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

With no annotations, the description carries the full burden and discloses two genuinely useful traits: supermarket/drugstore front pages expose only a subset of shelves, and their item ids are composite long strings (store:item:section:subsection) that must be forwarded unchanged. It omits auth, pagination, and rate-limit behavior, but the operational quirks it does reveal are substantive.

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

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

Front-loaded with the return shape, then a short notes block; every sentence contributes. The field enumeration is justified because no output schema exists, though the mixture of the field-list and the two notes could be slightly tighter.

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 enumerates returned fields, and it flags the store-type-specific search behavior and id handling. For a 2-parameter, fully schema-documented read tool this is close to complete, with only auth/pagination details 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 the schema already documents both id and query. The notes add rationale (why query is needed for supermarkets) and downstream handling of ids, but no new syntax or format detail beyond what the schema states. Baseline 3 is appropriate.

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

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

The description names the resource and its contents precisely ('A store's menu: item ids, names, prices, sections, quick-add, sold out'), making clear this is a store-scoped retrieval distinct from the cross-store ue_search. It lacks an explicit verb ('retrieve/get'), but the store-scoped framing differentiates it from siblings.

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

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

It explains how to use the query parameter (supermarkets/convenience/drugstores only expose a few shelves on the front page, so pass query) and what to do with results ('pass them to ue_add unchanged'). However it never states explicitly when to call ue_store versus ue_search or ue_place; the id-parameter text pointing at ue_search is the only routing hint.

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