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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the tool verifies a session, returns balance, and never pays, but does not explain failure behavior for invalid sessions or potential staleness of the returned balance.

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 with no filler. The word 'now' is slightly informal, but the core action and exclusion are stated immediately.

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 read-only tool with one parameter and no output schema, the description gives enough to understand the broad purpose. It still leaves gaps around parameter format, failure modes, and what exactly 'wallet balance' includes.

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?

There is one required parameter, 'account', with 0% schema description coverage. The description mentions 'account session' but never clarifies whether 'account' is an ID, username, token, or selector, so it does not compensate for the schema 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?

The description names a specific action (verify session) and a concrete result (return wallet balance). The phrase 'never pays' helps distinguish it from payment-oriented siblings like order_pay, though no sibling is named explicitly.

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

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

The word 'now' implies immediate use and 'never pays' implies it should not be used for transactions. However, it does not state when to prefer account_refresh or how this differs from other account tools, leaving usage largely 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?

The readOnlyHint and openWorldHint annotations already cover the safety profile. The description adds an important behavioral/security constraint: do not paste session files, SMS codes, or tokens into chat. It does not describe return content or enrollment steps, but it adds meaningful context beyond the annotations.

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

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

The description is one tightly written sentence with the core purpose front-loaded before the security warning. It is appropriately sized for a zero-parameter informational tool, though 'local enrollment' is terse enough to be slightly under-specified.

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

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

For a zero-parameter, read-only tool, the description is minimally adequate. However, it does not say what the enrollment instructions cover, what the response will look like, or when to choose this over sibling account tools, leaving gaps for the invoking agent.

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 burden. The description neither contradicts nor needs to compensate for the empty schema; baseline 4 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 states a specific verb and resource: 'Explain local enrollment.' It is clear enough to identify an informational enrollment-instructions tool, but it does not distinguish itself from sibling account tools such as account_check or account_refresh.

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 by the phrase 'Explain local enrollment' and the warning about not pasting secrets. The description gives no explicit when-to-use guidance, no exclusions, and no routing guidance versus the account-related siblings.

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 declare a non-readonly, non-idempotent, open-world call; the description earns credit by explaining why — credentials may rotate, and repeat calls within 24h degrade to verification only. The unresolved gap is the return value, since no output schema exists to say what a rotated credential response looks like.

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 terse sentences, each adding a distinct constraint (no SMS/purchase, credential rotation, 24h behavior, checkout exclusion) with the core purpose front-loaded. The semicolon-joined middle sentence compresses two separate behaviors less cleanly than separate statements would.

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?

Behavioral caveats are well covered for a mutation tool, but with no output schema the description should say what comes back on success (new token? status only?) and what "unknown outcome" looks like to the caller. The "account" parameter also goes uncharacterized, leaving the definition workable but incomplete.

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 single parameter "account" has 0% schema description coverage, so the description carries the full burden — yet it never says whether this is an account ID, email, or username, nor what format is expected. This is a meaningful gap for the only required input.

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?

"Maintain an existing session" plus "may rotate credentials" conveys a session/credential refresh action, which is specific enough to tell apart from account_check or account_connection_instructions. It stops short of naming the resource type explicitly (account/session for what service), leaving a little ambiguity.

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?

"without SMS or purchases" and "an unknown refresh outcome requires local login" give clear conditions and a fallback path, and "Does not renew checkout runtime" rules out an adjacent use case. However, no sibling is named, so an agent must still infer why it would pick this over account_check.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is largely carried by structured data. The description still adds meaningful context beyond them: the output is credential-masked, which tells the agent this is safe to surface in a conversation. It stops short of describing what an "alias" is or whether the list is local-only.

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

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

A single front-loaded sentence with no filler; each clause (what is listed and what is protected) carries distinct information.

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

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

For a zero-parameter read tool with no output schema, the description covers what is returned and the key privacy guarantee. What is missing is modest: the relationship between aliases and the account_* siblings, so the agent knows whether this supersedes account_check.

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 baseline this scores 4. There is nothing parameter-level for the description to compensate for, and the schema coverage is 100%.

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

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

The description uses a clear verb ("List") and names the concrete resources returned: connected aliases and local spending limits. It is specific enough to be actionable, but it never distinguishes itself from close siblings such as account_check or account_refresh, so sibling differentiation is left to the agent.

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: an agent can infer this is the entry point for enumerating accounts, but there is no explicit when-to-use, no exclusion, and no pointer to account_check for status details. The 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral fact beyond that: the report explicitly distinguishes implemented features from unverified/unsupported flows, which tells the agent how to interpret the output. With no output schema, it could have said more about the report's shape or scope, so this is adequate rather than 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 sentence, front-loaded with the verb and the payload, with zero filler. The qualifier 'explicitly unverified or unsupported' is doing real work by setting expectations about negative results, not padding.

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

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

For a zero-arg, read-only, no-output-schema introspection tool, the description supplies enough to call it and interpret the result. A sentence naming the scope of the report (this server's tools/flows) would close the 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 and the description does not pretend otherwise, so there is nothing to mis-specify. Baseline 4 applies for a no-parameter tool; no param meaning 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 ('Report') and the content of the report: implemented features plus unverified/unsupported flows. The 'capabilities' name is abstract on its own, but the description makes clear this is a self-description/feature-discovery tool, clearly distinct from the account/order/cart siblings. It never explicitly says whose capabilities (this server's), which keeps it 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?

No guidance on when to call it, no mention of calling it before other tools, and no named alternatives. The only implied usage is 'discovery tool', which the agent must infer from the word 'Report' and the sibling list. Nothing tells the agent what to do with the result.

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 idempotentHint=true and destructiveHint=false, and the description usefully adds that the cart must be empty, that it runs once, that it does not order or pay, and that checkout_quote is next. It does not explain what happens if the empty-cart precondition is violated.

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 compact sentences with the main constraint and next step front-loaded. Every sentence adds useful operational context without repetition.

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

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

The description gives enough high-level workflow context for selection and sequencing, and annotations cover the safety/idempotency profile. However, for a mutation tool with a complex required request object and no output schema, it omits important request-field 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%, so the description must carry parameter meaning. It partially explains item selection via live offer_id and combo round/items, but it does not explain the required request object fields (account, store_code, pickup_at, max_amount_cny, eat_type) or the idempotency_key.

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 selected items/combos to an EMPTY cart once. It references product_detail and checkout_quote, but does not explicitly distinguish this configured variant from the sibling cart_add_simple.

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 clear usage context: use live offer_id and explicit round/items choices from product_detail, only standard modifiers, and call checkout_quote next. It lacks explicit when-not guidance, such as what to do for a non-empty cart or when cart_add_simple is more appropriate.

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 openWorldHint, idempotentHint, and non-destructive writes; the description adds useful state context (cart must be empty, single shot, no payment side effect). It does not disclose what happens on a non-empty cart (error vs merge), nor how idempotency_key affects retries, which is the main behavioral unknown for a mutating 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?

Two tight sentences, front-loaded with the action and followed by constraints; nothing is padded. Minor ambiguity in 'once' and the vague 'official App configuration' phrase keeps it from a 5.

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 tool with a deeply nested 0%-documented schema and no output schema, the description is too thin: it omits how the request/checkout block is used, retry semantics tied to idempotency_key, and failure behavior on a non-empty cart. It also conflicts with the schema, which exposes ComboSelection while the text says combos need the official App.

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 a nested input with request (account, store_code, pickup_at, max_amount_cny, eat_type), items, and idempotency_key, yet the description explains none of them. 'Simple uncustomized menu items' hints at items semantics but nothing covers the checkout/request block or idempotency_key.

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

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

States a concrete verb and resource ('Add simple uncustomized menu items') plus the target state ('an empty cart'), which separates it from cart_add_configured and from order/checkout tools. It never names the sibling that handles the non-simple case, leaving the agent to infer that cart_add_configured exists for that.

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 clear preconditions ('empty cart', 'once') and explicit exclusions ('No order/payment', complex combos need the official App). It stops short of routing to a sibling tool for the excluded cases, so the alternative is named only as an out-of-band app rather than cart_add_configured.

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

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

readOnlyHint=true and openWorldHint=true already cover the safety profile, and "inspect" is consistent with that. The description adds little beyond it: no note about per-account scoping, whether an empty/uninitialized cart errors or returns empty, or refresh/freshness behavior of the "official" 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?

A single tight sentence with the resource and returned content front-loaded and 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 and no annotation detail on return shape, combined with a surprising required-parameter set that the description never addresses. For a tool whose inputs look mismatched to its read-only purpose, the description should at minimum explain the scoping/identity parameters.

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

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

Schema description coverage is 0% and the single required parameter is an opaque nested 'request' object whose required fields (account, store_code, pickup_at, max_amount_cny) look like checkout inputs rather than cart-read inputs. The description explains none of this, so an agent has no idea why a read requires a pickup time and max amount.

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 ("inspect") plus resource ("cart") and the exact payload returned (products, quantities, combo choices), so it is clearly a read of the current cart state rather than a mutation. It does not name the sibling tools it differs from (cart_add_simple, cart_add_configured, checkout_quote), leaving that inference to the agent.

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

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

Usage is implied by the wording "currently selected" (check cart contents before checkout), but there is no explicit guidance on when to call this versus cart_add_* or checkout_quote, nor any stated prerequisite such as authenticating the account first. The agent must infer the workflow position.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond annotations: it lists what is validated (cart components, discounts, locker/time, wallet, price cap) and notes the quote's 120-second lifetime, which is useful behavioral detail. It does not contradict readOnlyHint because quote validation is non-mutating; the quote is an ephemeral validation artifact.

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 with no filler. Every clause contributes to scope or behavior.

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 quote-creation tool with one nested parameter object and no output schema, the description covers the validation scope and quote lifetime but omits what the quote returns (e.g., quote ID/token), failure conditions, and how the quote is consumed by checkout_submit. This leaves meaningful gaps for an agent to use the result 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 0%, so the description must carry the burden of explaining the nested request parameters (account, store_code, pickup_at, max_amount_cny, eat_type). The description only indirectly hints at domain concepts like 'locker/time' and 'price cap' and does not explain formats, required constraints, or the role of store_code/account.

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

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

The description uses a specific verb ('Validate') and resource ('cart, components, discounts, locker/time, wallet and price cap') and states that it creates a 120-second quote. It clearly distinguishes a quote from a submit/pay operation, though it does not explicitly name the sibling tool checkout_submit.

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 a pre-checkout validation step by saying it validates the cart and creates a quote, but it does not explicitly state when to use this tool versus checkout_submit, order_pay, or cart_get. Usage is inferable but not guided.

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

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

Annotations already flag destructive=true and idempotentHint=true, and the description meaningfully reinforces the stakes ("REAL PURCHASE") plus a policy constraint not present in structured data. "Repeated calls only reconcile" clarifies the retry semantics beyond the raw idempotent flag, though it doesn't say what a reconcile response actually looks like.

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 tight sentences with the most consequential fact ("REAL PURCHASE") front-loaded. Every clause carries information; the only friction is unexplained jargon like "McWallet".

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?

This is a destructive, real-money mutation with zero parameter documentation and no output schema, yet the description never says how the agent confirms payment success, what a reconcile result contains, or what happens if the quote expired. For a tool that spends money, that leaves material 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%: account, quote_id, and idempotency_key are all bare required strings with no titles beyond the field names. The description only indirectly hints that quote_id comes from a fresh quote and that idempotency_key drives the reconcile behavior; account is never explained.

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 chain and resource: it creates and pays (McWallet) one fresh quoted order, which clearly separates it from checkout_quote and order_pay. It never names those siblings explicitly, so the boundary is inferable rather than stated.

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?

"within the locally authorized policy" and "one fresh quoted order" imply preconditions (an existing quote, prior authorization) but the conditions are not spelled out. Nothing tells the agent when to prefer order_pay over this tool or what to do if the quote is stale.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one valuable trait — that displayed prices are not final quotes — but discloses nothing else about what a 'live' menu returns or why a checkout-shaped request is required.

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 front-loaded and no padding. It is efficient, though the terse framing borders on under-specification for a tool with a required nested request object.

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, no parameter descriptions, and a required checkout-like request object unexplained, the description does not give an agent enough to call the tool correctly. The complexity signaled by the schema is not matched by the description.

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%: neither 'keyword' nor the nested 'request' object's fields (account, store_code, pickup_at, max_amount_cny, eat_type) carry any description, and the tool description mentions no parameters at all. Given four required sub-fields on a required object, this leaves the agent guessing at their meaning and format.

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 ('Browse a live store/time menu') plus a notable inclusion ('card offers'), so an agent knows it returns menu content. It does not contrast with siblings like product_detail or store_get, so differentiation is left implicit.

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

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

The description gives no when-to-use or when-not-to-use guidance and names no alternative. An agent cannot infer from the text whether to call this versus product_detail or checkout_quote for pricing.

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

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

Annotations already disclose that this is non-read-only, destructive, idempotent, and open-world. The description adds meaningful behavioral context by restricting payment to orders with no prior payment attempt and indicating that other states should only be queried.

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

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

The description is two short sentences with the key precondition front-loaded. Every phrase contributes to the invocation decision, with no wasted text.

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

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

The central state precondition is present, which is important for a destructive payment action. However, with no parameter descriptions and no output schema, the definition leaves account/attempt_id semantics and failure or return behavior undocumented.

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

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

The schema has 0% description coverage, and the description does not explain either required parameter. The word 'payment attempt' loosely hints that attempt_id relates to a payment attempt, but account is entirely 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 states a specific verb and resource: pay an existing locally CREATED order. It also adds a clear state constraint, but it does not explicitly name sibling tools such as checkout_submit or order_status, so sibling differentiation is only implied.

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

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

It gives explicit usage conditions: the order must already exist locally, and payment must never have been attempted. It also states the negative case ('All other states only query'), though it does not name the alternative query 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=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by saying it never resubmits or consumes and that cancellation overrides historical PAID, which goes beyond annotations. However, these phrases are terse and do not fully explain the reconciliation behavior or edge-case semantics.

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

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

The description is short and front-loaded, with the core operation stated first and qualifying behavior second. It is appropriately sized, though its terseness borders on under-specification rather than pure conciseness.

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

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

The tool has two required parameters, no output schema, and no parameter descriptions, so the description carries substantial explanatory burden. It does not explain the parameters, the return value, authentication/account context, or how to interpret the PAID/cancellation behavior, leaving key context for correct invocation 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 0% for two required parameters ('account' and 'attempt_id'), so the description must compensate. It does not mention either parameter or explain what 'account' and 'attempt_id' mean, leaving the caller with no semantic guidance beyond the bare names.

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

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

The description states a verb and resources ('Reconcile the exact order, cashier and wallet'), but 'reconcile' is ambiguous for a tool named order_status and does not plainly say it retrieves or checks order status. It hints at differentiation from payment tools by saying it never resubmits or consumes, but the core purpose remains somewhat vague.

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 behavioral reassurance ('Never resubmits or consumes') but gives no explicit guidance on when to use this tool versus siblings like order_pay, checkout_submit, or checkout_quote. The edge case 'cancellation overrides historical PAID' adds context but is not framed as usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data exposure are covered. The description adds the useful notion of real-time availability ('currently available'), implying results may change between calls, but does not discuss rate limits, caching, or whether an empty result means no slots.

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

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

A single front-loaded sentence with no filler; every clause (available, pickup, dates/times/meal periods, per store) contributes to selecting and calling the tool correctly.

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 usefully enumerates the returned shape (dates, times, meal periods), which is its main contribution. But for a tool with two required, fully undocumented parameters and an opaque 'account' argument, an agent lacks enough information to call it confidently.

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% — neither 'account' nor 'store_code' has any documented format, constraints, or meaning. The description only loosely implies a store-scoping parameter ('for a store') and says nothing at all about what 'account' identifies or how it relates to store_code, so it fails to compensate for the schema 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?

The description names a specific verb and resource — retrieving currently available pickup dates, times, and meal periods for a store — which is far more informative than the name 'pickup_slots' alone. It does not explicitly distinguish itself from siblings like store_get or menu_list, but the resource is distinct enough that confusion is unlikely.

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 word 'currently available' implies this is a live-availability lookup rather than a static store lookup, which hints at when to use it. However, there is no explicit when-to-use vs. when-not guidance and no mention of alternative tools for scheduling or ordering downstream.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description reinforces non-mutation ('No cart/order mutation') and lists the data being read, but it does not add behavioral context like authentication requirements, rate limits, or return format. With annotations present, a 3 is appropriate.

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

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

Two short sentences with no fluff: the read scope is front-loaded, and the non-mutation disclaimer follows. It is efficient, though its brevity contributes to under-specification elsewhere rather than being a structural flaw.

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

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

Given a nested request object, three parameters, and no output schema, the description is significantly incomplete. It enumerates some returned content but fails to explain how to construct the request, what product_code and offer_id represent, or how the CheckoutInput fields affect the result, leaving an agent unable to call the tool correctly without guessing.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not explain any of the three parameters: 'request' (a nested CheckoutInput with required account, store_code, pickup_at, max_amount_cny), 'product_code', or 'offer_id'. The description mentions output concepts but gives no guidance on what values to supply.

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 a specific verb ('Read') and concrete resources ('combo rounds, component choices, extra prices, supported standard configurations'), making the tool's core purpose clear. It also states 'No cart/order mutation,' which separates it from cart/order-mutating siblings, though it does not explicitly distinguish it from other read tools like menu_list or checkout_quote.

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

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

Usage is implied: use this tool to read product configuration data without mutating a cart or order. However, no explicit when-to-use or when-not-to-use guidance is given relative to siblings such as menu_list or checkout_quote, and no prerequisites or workflows are described.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that availability is re-checked for pickup time, which is useful behavioral context, but it omits account/auth requirements and return format.

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

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

It is a single front-loaded sentence with no filler. The availability note is useful, though the phrasing is slightly cryptic.

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-required-parameter lookup with no output schema, the description omits what is returned, what 'account' means, and error/availability behavior beyond the re-check note. It is not complete enough for confident 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%, so the description must compensate. It clarifies that store_code is a seven-digit restaurant code but leaves the required 'account' parameter and all format/meaning details undefined.

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

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

The description uses a specific verb ('Read') and resource ('seven-digit restaurant code'), but it is unclear whether the tool returns store details or only validates the code. It does not distinguish this tool from siblings such as stores_favorites or pickup_slots.

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

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

There is no indication of when to use this tool versus alternatives like stores_favorites, pickup_slots, or account_check. The only hint is a behavioral note about pickup availability, not usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful scope qualifier that only pickup restaurants are returned, but says nothing about ordering, pagination, or what a 'saved favorite' entry contains (no output schema exists to cover that).

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 short sentence, front-loaded with the verb and scope, with zero filler. Nothing extraneous to trim.

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

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

For a read list tool with no output schema and an undocumented required account parameter, the definition leaves too much open: account identifier format, result shape (list of stores? IDs?), and any limits are all unstated.

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 required parameter 'account' is undocumented in both schema and description. The phrase 'this account's' gestures at the parameter but never says whether it is an ID, email, or handle — the description fails to compensate for the coverage 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?

The description names a specific verb ('Read') and resource ('saved pickup restaurants'), so the agent knows this returns the account's favorites list rather than store details. It stops short of differentiating from siblings like store_get or accounts_list, which could matter given the surrounding catalog.

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 statement of when to prefer this over alternatives — e.g. store_get for a single location or accounts_list for picking the account. The 'pickup' qualifier hints at a filter but no condition or exclusion is articulated.

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