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

With no annotations, the description discloses the default behavior of canceling the most recent order. However, it does not mention irreversibility, required permissions, or side effects, which are important for a destructive 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?

The description is extremely concise with two sentences. The purpose is front-loaded and every part adds value.

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

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

For a simple cancellation tool with no output schema or annotations, the description covers the core behavior and parameter default. However, it lacks context about prerequisites, error conditions, or whether the action is reversible.

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

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

The schema has 0% description coverage, so the description must compensate. It explains that omitting orderId results in canceling the most recent order, adding meaningful context beyond the schema's type declaration.

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

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

The description clearly states the action ('取消订单' meaning cancel order) and specifies the behavior when orderId is omitted: cancels the most recent order. This distinguishes the tool from siblings like confirmOrder or reorder.

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

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

The description implies the tool is for canceling orders but does not provide explicit guidance on when to use it versus alternatives (e.g., reorder, quickOrder). No exclusions or prerequisites are mentioned.

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 full burden. It discloses that the tool creates a real order and returns a payment link, indicating a mutation. However, it does not specify potential side effects (e.g., whether the draft is invalidated after use), error handling, or idempotency. Given the absence of annotations, more behavioral detail would be beneficial.

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 extremely concise, using two clear clauses. The purpose is front-loaded ('确认下单'), and every sentence adds necessary information without redundancy. It is well-structured for quick comprehension.

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

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

Given no output schema, the description adequately explains the return value (payment link) and the input parameter's origin. However, it lacks details on error scenarios or response structure. For a simple single-parameter tool, the coverage is good but not exhaustive.

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 description adds significant meaning to the single parameter 'draftId' by stating it comes from quickOrder/reorder, providing source context and implied format. Since schema description coverage is 0%, this added value is crucial for correct usage.

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

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

The description clearly states the verb (确认下单/confirm order), the resource (订单/order), and the key action: creating a real order from a draft and returning a payment link. It distinguishes from sibling tools like quickOrder (which creates a draft) and cancelOrder (which cancels), making the purpose unambiguous.

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

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

The description provides a clear condition for calling the tool: only after user explicitly confirms ('仅在用户明确确认后调用'). It also implies this is the final step following quickOrder/reorder, giving context for when to use it. However, it does not explicitly mention when not to use or list alternatives, which would elevate the score to 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?

The description discloses key behavioral traits: the tool is stateful, memorizing coordinates after first use. This is valuable as no annotations are provided. However, it does not mention authentication needs, rate limits, or what happens if coordinates are not provided on first use.

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

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

The description is concise with two clauses in one sentence, front-loading the purpose. Every word adds value. It could be slightly more structured, but it is efficient.

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

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

Given 3 parameters, no output schema, and no annotations, the description covers usage and stateful behavior. However, it lacks information about the return format (e.g., list of stores with details), which is a gap in completeness.

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 coverage, the description adds meaning to the parameters: name for searching, longitude/latitude for initial use. However, it does not specify coordinate format (e.g., decimal degrees) or explain how 'memorized common store coordinates' work, leaving ambiguity. Baseline 3 is appropriate as some value is added but gaps remain.

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

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

The description clearly states the tool searches for Luckin stores by name ('按名称搜索瑞幸门店'), which is a specific verb+resource. It distinguishes from sibling tools like searchProduct (search products) and other order-related tools.

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

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

The description provides explicit usage context: first use requires coordinates ('首次使用需提供经纬度'), and subsequent uses rely on memorized coordinates ('之后用记忆的常用门店坐标'). This guides the agent on when to provide longitude/latitude. However, it does not explicitly state when not to use this tool or suggest alternatives.

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

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

With no annotations, the description carries full burden. It discloses the default behavior and the information returned (status, pickup code, progress), but lacks details on side effects, authentication needs, or rate limits.

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

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

The description is concise with two sentences, front-loading the purpose and then addressing the parameter default. Every sentence is necessary and no redundancy.

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

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

Given the tool has one optional parameter and no output schema, the description covers the primary behavior, default logic, and output content. Missing details like error handling or authentication are minor gaps.

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

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

The schema has 0% description coverage, so the description must compensate. It does by explaining that orderId is optional and that omitting it queries the most recent order, adding meaningful context beyond the schema.

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

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

The description clearly states the tool queries order status including pickup code and preparation progress. It distinguishes from sibling tools like cancelOrder and confirmOrder by focusing on status retrieval only.

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

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

The description implies usage for checking order status and mentions default behavior when orderId is omitted, but does not provide explicit guidance on when to use this tool versus alternatives like searchProduct or reorder.

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

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

No annotations are provided, so the description must fully disclose behavior. It reveals that the tool supports both read and write operations, but lacks details on side effects (e.g., whether writing is immediate, persistent) or what the 'get' action returns. The description adds context beyond the schema but is not exhaustive.

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

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

The description is a single sentence, concise and front-loaded with the verb phrase. It efficiently conveys the main functionality without redundancy, though it could be slightly more structured.

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

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

Given no output schema and no parameter descriptions in the schema, the description does not fully explain expected outputs or parameter details. The mention of 'recent orders' and 'frequent items' without schema mapping leaves gaps in understanding, especially for new agents.

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 explains the domain of parameters (e.g., 'temperature' as icy/hot, 'sugar' as sweetness) and the 'action' enum. However, it mentions 'recent orders' and 'frequent items' which do not correspond to any schema parameter or output field, causing ambiguity.

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

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

The description clearly states the tool's purpose: viewing or setting preferences (frequently used store, default temperature, sugar level, cup size) and viewing recent orders and frequently ordered items. It uses specific verbs and resources, distinguishing it from sibling tools focused on order management.

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

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

The description implies usage for preference management but does not explicitly state when to use this tool versus alternatives like 'quickOrder' or 'orderStatus'. No when-not-to-use guidance is provided.

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 that the tool does not directly place orders, returns a preview and draftId, and uses default store and preferences. This is sufficient disclosure for a preview tool.

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

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

The description is a single concise Chinese sentence that front-loads the main purpose and key behaviors. Every word adds value with 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?

Given no output schema, the description adequately explains the return: order preview and draftId, and the overall flow. It is complete for a draft-creating tool, though it does not cover error handling for invalid queries.

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 baseline is 3. The description adds context about the default behavior for shopName and amount, which is not in the schema. It also clarifies the query parameter's role, providing marginal but useful value.

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

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

The description clearly states the tool's purpose: it takes a natural language description of a drink, auto-fills store and taste preferences, and returns an order preview with draftId. It also clarifies that it does not place the order directly, distinguishing it from sibling tools like confirmOrder.

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 explains when to use the tool (quick order draft via natural language) and implies that for final placement, confirmOrder should be used. It mentions default store and preferences, providing context, but does not explicitly list alternative tools or when not to use it.

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

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

No annotations provided, so description carries full burden. It discloses it's a debug backdoor and direct pass-through, but does not explain side effects, authentication needs, or whether operations are destructive. Some behavioral info is given (allowed tools and prohibition), 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?

Two sentences, no wasted words. Front-loaded with purpose, then key restriction. Perfectly concise for the information conveyed.

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

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

Given no output schema and nested parameters, the description is brief. It lists allowed tools but doesn't explain how to use rawCall with specific tools, error handling, or return values. As a debug backdoor, this might be acceptable, but for an agent it leaves gaps.

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

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

Schema coverage is 0% (no descriptions for parameters). The description implies 'tool' selects one of the listed tools and 'args' are its arguments, but doesn't explicitly explain the meaning or format. For a 2-parameter schema with nested object, more detail 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?

The description clearly states it's a debug backdoor for directly calling specific original Luckin MCP tools. It lists the allowed tools (queryShopList, searchProductForMcp, etc.) and explicitly excludes createOrder. This distinguishes it from sibling tools like quickOrder and confirmOrder.

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 states when to use (for the listed tools) and when not to use (createOrder is forbidden, must use quickOrder → confirmOrder instead). Provides clear context for agent decision-making.

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 provided, so description bears full burden. It explains the flow (return preview, draftId, call confirmOrder) but does not disclose failure modes, idempotency, or whether it mutates state.

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?

Single sentence in Chinese, front-loaded with action, no unnecessary words. Very 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?

Given zero parameters and no output schema, the description covers the basic flow but lacks prerequisites (e.g., must have a last successful order) and error conditions.

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?

No parameters in schema; description adds contextual meaning for the no-input action. Baseline 4 applies as no param documentation 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?

The description specifies '一键复购上次成功订单' (one-click repurchase last successful order), a clear verb+resource. It distinguishes from sibling tools like confirmOrder and quickOrder.

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?

States that this is for quickly repurchasing the last order and that after getting a draftId, one should call confirmOrder. Implicitly distinguishes from quickOrder for new orders, but no explicit when-not.

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

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

With no annotations provided, the description discloses retry logic for unstable upstream searches and specifies the output fields. This provides useful behavioral context beyond the schema, though additional details like auth requirements or side effects are absent.

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

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

The description is a single, front-loaded sentence containing the action, retry detail, and output spec. Every element is essential and clearly communicated.

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 search tool with two parameters and no output schema, the description covers purpose, retry behavior, and output fields. It lacks guidance on when to use versus sibling tools and does not mention pagination or error conditions, but otherwise is sufficient.

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

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

Schema coverage is 50% (one parameter described in schema). The description does not add meaning to the 'query' parameter, but its purpose is clear from the context. The 'shopName' parameter is already described in the schema. The description compensates minimally by implying the nature of the query.

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

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

The description clearly states the tool searches for Luckin products and lists the specific fields returned (name/price/SKU/attributes). It also mentions retry behavior, which adds precision. This distinguishes it from sibling tools like findShop (shop search) and others.

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 explicit guidance on when to use this tool versus alternatives. The description implies it is for product search, but does not mention when not to use it or contrast it with siblings like quickOrder or reorder.

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