Lezzoo

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

Adds one genuinely valuable constraint not in the annotations: "One merchant per cart." The annotations already declare this is a non-read-only, non-destructive, open-world mutation, so the safety profile is covered. However, the description says nothing about what happens when the cart already contains items from another merchant (error vs. replace) or whether repeated adds merge quantities — the practical failure modes for this 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?

Front-loaded with the core action and then organized around the three usage shapes, so it is easy to scan. The parenthetical "(put a whole request's items in one call)" restates the preceding clause and could be dropped without loss.

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?

An output schema exists, so return values need no explanation, and the description covers the main invocation shapes plus the cross-merchant constraint. What it leaves out — conflict behavior with a non-empty cart and the unmentioned `language` param — are the remaining meaningful holes for a mutation tool with five optional 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 coverage is already 100%, but the description earns credit above baseline by explaining the mutually exclusive parameter paths (items vs. productId/quantity/optionValueIds) and by translating optionValueIds into domain terms (addon/size value ids). The `language` parameter is never mentioned in the description, which is the one 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?

Opens with a specific verb and resource ("Add one or more products to the cart") plus an explicit scope qualifier ("in a single call"), which immediately separates it from update_cart_item, remove_cart_item, and clear_cart. An agent can select it without opening the schema.

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

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

Gives explicit routing rules for each shape: `quantity` for multiple of the SAME item, `items` for DIFFERENT products, direct params for a single product. It also names where product ids come from (search_merchant_products/get_product_details), which is the real prerequisite an agent needs.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds the key behavioral detail annotations can't: the answer is scoped to 'this session' and includes the identity of the signed-in party, not just a boolean.

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 with no filler, and the two things it returns (sign-in state, identity) are front-loaded in that order.

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 params, full annotation coverage and an output schema handling return values, the description covers nearly everything needed. The only small gap is not saying what is returned for an anonymous session (null identity vs. a signed_out flag), which the output schema presumably resolves.

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?

Zero parameters, so the schema has nothing to explain and there is nothing for the description to compensate for. Baseline 4 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?

A specific verb ('Return') plus a precisely scoped resource (whether the customer is signed in for this session, and who). No sibling tool does this — 'logout' is the mutation counterpart and 'get_profile' returns profile data rather than an auth verdict, so the distinction is clear.

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 (check auth state before a signed-in-only action such as place_order or view_cart) but never stated. No explicit when-to-use or when-not-to-use guidance, and no alternatives are named.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered; the description adds nothing on top. It does not say whether clearing is reversible, whether it works on an already-empty cart, or whether it affects only the current user's cart — yet "remove all items" sits in mild tension with destructiveHint=false, which an agent might want reconciled.

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 action and the scope, with zero filler. It is efficient, though its brevity leaves it closer to a restatement than an explanation.

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 a full annotation set and an output schema, the description is minimally adequate — return values need not be explained. What is missing is the scope of the effect (whose cart, state after clearing), which matters even for a simple mutation.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies.

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

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

States a specific verb and resource ("Remove all items from the cart"), and the word "all" implicitly separates it from remove_cart_item and view_cart. It never names a sibling explicitly, so the differentiation is inferred 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?

The description contains no when-to-use guidance, no prerequisites, and no reference to the obvious alternative (remove_cart_item for a single item). An agent must infer the selection rule from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the trailing "Read-only." is pure repetition and earns nothing. The genuine addition is the session-level sign-in requirement, which is behavioral context not encoded in any annotation, plus a hint of the returned field set.

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 purpose and followed by the precondition. The closing "Read-only." is wasted words given the annotations, keeping it just short of ideal.

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

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

A zero-parameter, annotated read with an output schema — nothing an agent needs to invoke it correctly is missing. The description adds the one thing structured fields don't cover (session sign-in), and the field list is a harmless bonus.

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 baseline is 4; nothing needs explaining and the description correctly spends no space on parameter semantics.

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 ("Return the signed-in customer's saved delivery addresses") and enumerates the returned fields. It distinguishes itself from siblings like get_payment_methods by resource domain, though it doesn't explicitly separate itself from get_profile, which could plausibly contain address data.

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 a precondition ("Requires the customer to be signed in for this session") which effectively implies when the tool is usable, but it names no alternatives and offers no when-not guidance (e.g. use auth_status to check sign-in, use get_profile for other account data).

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavior the annotations cannot: a hard 250-item cap and what to do when truncation occurs. It stops short of stating ordering or whether images/options are included, which keeps it at 4 rather than 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?

Three sentences, front-loaded with the core action, then usage, then the limit and its workaround. No sentence is redundant and the truncation caveat is placed where an agent will read it before calling.

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?

An output schema exists so return values need not be re-explained, annotations carry the safety profile, and the description closes the one real gap — the 250-item cap and its fallback. Everything an agent needs to call this correctly and handle a truncated response 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?

Schema description coverage is 100%, with merchantId and the language enum both documented in-schema, so the baseline is 3. The description implies the merchant scoping but adds no syntax or format guidance for either parameter beyond the schema.

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

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

States a specific verb and resource ('Fetch the entire menu of a merchant') plus the scope ('all categories and all items'), which distinguishes it from the paged/search siblings by contrast. The name-plus-description pair leaves no ambiguity about what is returned.

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 an explicit when-to-use ('user wants to browse the full menu', 'find an item across all sections without paging') and an explicit fallback when the result is truncated: search_merchant_products with a query. Both the positive and the escape-hatch path are named.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, so the description's repetition of 'Read-only' adds little. However, it usefully discloses the session authentication requirement and clarifies that results include both in-progress and past orders with specific fields.

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

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

The definition is two sentences with no wasted text. The scope and return content are front-loaded, and the authentication requirement follows 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 zero-parameter read tool with rich annotations and an output schema, the description provides what the agent needs: whose data is returned, which order categories are included, the key fields, and the sign-in prerequisite. Return-value structure is appropriately left to the output schema.

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

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. The baseline for zero-parameter tools applies, and nothing in the description misrepresents the empty input 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 gives a specific verb and resource: returning the signed-in customer's orders. It further distinguishes the two returned groups, `current` and `history`, and lists the fields included, so an agent can identify the tool's scope without opening its 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?

Usage is implied by the signed-in-customer scope and the explicit sign-in prerequisite, but the description does not name alternatives such as `track_order` for tracking a specific order or `auth_status` for checking authentication. It provides context but leaves when-not-to-use guidance implicit.

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, openWorldHint=true, and destructiveHint=false. The description adds useful context by stating that sign-in is required and by explaining the expired/missing-link scenario, but it does not cover failure behavior or link lifetime nuances.

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 three short, front-loaded sentences with no wasted text. Purpose, trigger condition, and authentication requirement are all stated efficiently.

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

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

For a simple one-parameter tool with a full schema and an output schema, the description provides the key context: placed order scope, use case, and sign-in requirement. It could be slightly more complete about error or auth-failure behavior, but it is largely 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 100%, and the orderId parameter is already documented as the order ID returned by place_order. The description reinforces that this is for a placed order but does not add format or usage details beyond the schema.

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

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

The description states a specific verb and resource: generate a payment link for a placed order. It is clear and actionable, though it does not explicitly distinguish itself from sibling order-related tools such as place_order or review_order.

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

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

It clearly says when to use the tool: when the payment link expired or was not returned at order placement. It does not list when-not-to-use cases or name alternatives, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context the annotations cannot convey: sign-in is required and cash on delivery is not returned, which prevents a wasted call and an incorrect offer to the user. It stops short of saying whether the list varies by region or account.

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 dense sentence sequence with zero filler: capability and provider examples first, then the cash-on-delivery exclusion, then the auth prerequisite, then the intended use. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained. For a read-only, no-param lookup, the description covers purpose, exclusions, auth requirement, and the workflow role — nothing an agent needs to call it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The mention of payment_type_id clarifies the output field the agent will consume rather than any 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?

Specific verb (List) plus precise resource (available DIGITAL payment methods for checkout) with concrete examples enumerating the providers. It explicitly excludes cash on delivery, so an agent can distinguish this from order-placement siblings without opening a schema.

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

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

States an explicit use case: mapping a user-named payment method to its payment_type_id, which is exactly the downstream need before place_order. No alternatives are named, but no sibling offers a competing capability, so the routing risk is low.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the payload shape and the host-dependent card rendering under MCP Apps. It does not discuss localization fallback behavior for the language enum, which is the one remaining trait an agent might want.

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, zero waste, with the identifier requirement and provenance front-loaded before the conditional rendering note and the usage trigger.

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?

Output schema exists, yet the description still previews the returned fields and explains host-dependent rendering, so an agent knows both when to call it and what to expect. Nothing needed for correct invocation 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 100%, so both parameters are already documented, including the productId provenance and the language enum. The description only reinforces where productId comes from and says nothing about the language parameter, so it adds marginal value over the schema — baseline 3.

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

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

Names a specific verb and resource ("Show full details for a single product/menu item by product_id") and enumerates exactly what comes back (image, description, price/discount, stock, addons). That scope cleanly separates it from siblings like search_merchant_products or get_full_menu.

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

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

Explicitly states the trigger ("when the user taps a product or asks about a specific item") and routes the agent to search_merchant_products as the source of the id. No explicit when-not or exclusion against siblings, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered and the trailing "Read-only." is redundant. The description does add genuinely new behavioral context not in the annotations: the session sign-in requirement, which determines whether the call will succeed at all.

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

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

Two compact sentences: the returned payload is front-loaded first, the precondition second. Every clause carries information; even the short "Read-only." tag is only marginally wasteful.

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 full annotation coverage and an output schema, the description covers the one thing structured fields cannot: the sign-in precondition. Listing the fields is slightly redundant against the output schema but not harmful, so nothing an agent needs is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter discussion, and the field list it provides refers to return data rather than inputs, so there is no confusion introduced.

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 ("Return the signed-in customer's profile") and enumerates the exact data returned (name, phone, email, language, loyalty tier, total orders, member-since). This clearly separates it from siblings like auth_status or get_addresses without needing to open a schema.

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

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

The description gives a precondition ("Requires the customer to be signed in for this session") which implies when it can be used, but it never explicitly routes the agent to siblings or states exclusions. In particular it does not mention auth_status as the way to check sign-in state before calling, leaving the choice 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the temporal freshness implication of 'currently trending'; 'Takes no arguments' merely restates the empty schema.

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

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

Three short sentences, front-loaded with the core purpose; no filler. The closing 'Takes no arguments' is marginally redundant given the empty schema but not harmful.

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 an output schema present, the description need not explain return values, and annotations cover the safety profile; zero params keep the surface small. The only mild gap is the absence of any cue about how results are ordered or scoped.

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, which sets the baseline at 4. 'Takes no arguments' is consistent with the empty schema, and schema coverage is 100%, so nothing further is required.

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: 'Return the platform's currently trending / most-searched terms.' The scope word 'currently' signals freshness, and the resource is distinct from the sibling 'search' tool, though the description never explicitly contrasts with it.

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?

'Useful for suggesting what users can look for' implies a usage context but gives no explicit when-to-use/when-not guidance and names no alternatives among the ~20 siblings such as 'search' or 'get_full_menu'.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the one thing the annotations don't: an authentication prerequisite (sign-in required), which is exactly the kind of extra behavioral context that matters for a wallet read.

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

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

Two short sentences, front-loaded with the resource and followed by the prerequisite. Nothing is padded or repeated from the schema.

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 with a full output schema and annotations covering the safety profile, the description supplies everything the agent still needs: the resource scope and the sign-in requirement. Return values are handled by the output schema.

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 zero parameters there is nothing for the description to disambiguate, so the baseline is 4. Schema coverage is 100% and no parameter meaning is missing.

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: retrieve the current Lezzoo Pay wallet balance for the signed-in customer. That is clearly distinct from siblings like get_payment_methods or get_order_history, though it doesn't explicitly name any sibling to reinforce the distinction.

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?

"Requires sign-in" is a useful precondition that tells the agent when this call can succeed. However, there is no guidance on when to prefer this over adjacent tools (e.g. get_payment_methods) or any stated exclusions, so usage is only implied.

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

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

The description says the tool "clears the stored token," which is a state mutation, while annotations declare readOnlyHint: true (does not modify its environment). The description is arguably the accurate side here, but as written it directly conflicts with the structured safety profile an agent relies on. It also says nothing about whether the session is invalidated server-side or what happens on repeat calls.

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 front-loaded sentence with the effect in a parenthetical — zero waste, no repetition of the title, and the key consequence is stated up front.

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 parameters, an output schema present, and a small set of annotations, the description covers the essentials of what the tool does. It leaves open how this relates to auth_status (the natural companion for verifying state) and whether the sign-out is local-only or also server-side.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing parameter-level the description needs to compensate for and 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?

"Sign the customer out of this session" names a specific verb and scope, and the parenthetical clarifies the concrete effect (token cleared). It is clearly distinguishable from read-only siblings such as auth_status or get_profile, though it never names those siblings explicitly.

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

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

The phrase "of this session" scopes the action, but there is no explicit when-to-use guidance (e.g., "call when the customer requests sign-out; use auth_status to check current state first"). Usage is implied by the self-evident name rather than stated.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds genuine context beyond them: the preview-vs-commit gate, the sign-in requirement, and the non-empty-cart precondition. It stops short of describing irreversibility or failure modes when the order fails, but it is well above the annotation baseline.

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

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

Four short sentences, each carrying a distinct obligation (purpose, prerequisite, confirm gate, preconditions). The critical commit-gate detail is placed early and nothing is redundant 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. The description supplies the prerequisites and the confirm gate, leaving only edge cases like the active-order conflict to the schema — adequate, though a note on irreversibility would complete it.

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

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

Schema description coverage is 100%, so confirm, addressId, voucherCode, paymentTypeId, and confirmActiveOrder are already fully documented. The description reinforces confirm's semantics but adds nothing new about the other four parameters, so baseline 3 applies.

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

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

States a specific verb and resource ("Place the order from the current cart") and distinguishes itself from the adjacent review_order tool by naming it explicitly. An agent can tell immediately that this is the terminal commit step, not a read or preview.

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 explicit sequencing ("Call review_order first so the customer can confirm the total"), the condition for real placement versus preview (confirm:true), and preconditions ("Requires sign-in and a non-empty cart"). There is essentially no inference required to decide when to call this.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the lineId sourcing constraint but does not explain what happens if the line is missing, whether removal is reversible, or any side effects on cart totals.

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

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

The definition is a single front-loaded sentence with zero filler. The key identifier source is included 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 one-parameter mutation tool with complete schema description coverage, annotations, and an output schema, the description is nearly sufficient. It could be slightly stronger by clarifying behavior for invalid or already-removed line IDs, but no critical agent-facing information is absent.

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

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

Schema coverage is 100%, so the single parameter is already documented as 'line_id from view_cart.' The description repeats this same information without adding format, validation, or error semantics beyond what the schema provides.

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 (remove), resource (cart line), and identifier source (line_id from view_cart). An agent can distinguish it from clear_cart (all lines) and update_cart_item (modifying a line) without opening 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?

The phrase 'from view_cart' implies the prerequisite workflow for obtaining line_id, but the description does not explicitly say when to use this versus clear_cart or update_cart_item. Usage is implied rather than fully 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?

Adds substantial context beyond the annotations: the tool renders an interactive widget where the user picks address and payment as tappable options, those are chosen in the widget rather than in chat, and it requires sign-in and a non-empty cart. This is exactly the behavioral guidance the readOnly/openWorld hints don't convey.

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 front-loaded sentences with no filler; the pricing scope, widget behavior, prerequisites, and 'no order placed' caveat all earn their place.

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

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

With annotations covering safety and an output schema covering return values, the description fills the remaining gaps: the in-widget selection model, sign-in and non-empty-cart prerequisites, and explicit non-placement of orders.

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 already 100%, so baseline is 3. The description adds meaning by explaining that address and payment are selected by the user in the widget rather than passed in chat, clarifying the role of the optional addressId/paymentTypeId.

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 (prices the current cart for checkout), enumerates the price components, and clarifies it also renders an interactive selection widget. The clause 'Places no order' cleanly distinguishes it from place_order.

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?

'Use when the user is ready to check out' gives a clear trigger, and the prerequisites (sign-in, non-empty cart) are stated. It stops short of naming place_order as the next step, but 'Places no order' implicitly routes the agent away from 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the bar is lower. The description does add valuable non-annotation context: ranking is by relevance and proximity, the call is anonymous with no sign-in required, and results may render as cards under MCP Apps. These are real behavioral disclosures beyond the structured hints.

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 what the tool does, then location guidance, then return/sibling routing, then the anonymity and read-only notes. Every sentence carries distinct operational information with 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?

An output schema exists, so return values need not be detailed, yet the description still notes the card rendering form. With 7 parameters fully documented in the schema and the description covering priority ordering and sibling handoff, nothing needed to call the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond it by explaining the priority order for location resolution (lat/long > area/address derivation > server default) and why location matters (proximity ranking), which the schema alone does not convey.

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?

Opening sentence gives a specific verb (search) and resource (restaurants/stores) with geographic scope. It also distinguishes itself from the sibling search_merchant_products by defining the handoff relationship via merchant_id, so an agent can tell the two apart without opening the 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 states to pass latitude/longitude when known, to derive location from area/address otherwise, and that a configured default applies as a last resort. It also gives the concrete next-step routing: use the returned merchant_id with search_merchant_products to open a menu.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive. The description adds genuinely new behavior: pagination with `has_more`, that a single response is only part of the menu, and that it renders as cards with category tabs and Prev/Next when the host supports MCP Apps. These are traits not conveyed by annotations or schema.

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 purpose and required id, then layers mode guidance and caveats. Slightly dense at five sentences, but each earns its place; minor redundancy between the pagination note and the query-reliability note.

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 paged, mode-switching tool this covers the key completeness gaps: pagination limits, how to find a specific item, and host-dependent rendering. With an output schema present, it rightly omits return-field details.

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 the baseline is 3, but the description adds real semantic relationships: `categoryId` comes from the result's `categories`, `query` searches the entire menu across pages and sections, and `page` interacts with `has_more`. This goes beyond field-level docs, though it doesn't cover `city` or `language` behavior.

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

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

States a specific verb and resource ('Show the menu for a merchant/restaurant') and identifies the required key (merchant_id from a `search` result). It is clearly distinguishable from siblings like `search`, `get_product_details`, and `get_full_menu` by being a per-merchant, paged menu view.

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 tells the agent how to choose modes: pass `categoryId` to browse a section, omit both to show top items, provide `query` to search within the menu. It also names the recommended alternative for item lookup (`query="<item name>"` instead of paging), which is exactly the when-to-use guidance an agent needs.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses that sign-in is required, that the result is rendered as a status card with a progress stepper and sometimes a map, and that the tool should be called again to refresh live data. These are meaningful operational details not present in 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 purpose is front-loaded and the description is information-dense, but the first sentence is a long run-on with nested parentheticals and an exhaustive list of returned item fields. Because an output schema exists, some of that return-field detail is redundant, though the overall structure remains usable.

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 one-parameter read-only tracking tool with an output schema, the description covers the essential context: what is tracked, how to pass or omit the order id, authentication, refresh behavior, and when a map is available. Nothing critical for correct invocation 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 100%, and the schema already documents that omitting orderId tracks the most recent active order. The description repeats this behavior but adds no syntax or format detail beyond the schema; the casing mismatch between 'order_id' and 'orderId' is a minor inconsistency rather than added semantics.

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

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

The description gives a specific verb and resource — 'Track a Lezzoo order live' — and immediately clarifies the live-active-order scope versus historical orders. It is detailed enough that an agent can distinguish it from order-history or checkout-review tools without opening the schema.

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

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

It clearly explains the two invocation modes: pass an order_id, or omit it to track the customer's most recent active order. It also states sign-in and read-only requirements, but it does not name alternatives or when-not-to-use conditions, so it falls short of full alternative routing guidance.

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

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

The description carries behavior the annotations do not: setting quantity to 0 deletes the line, a side effect that reads slightly against destructiveHint=false even though a cart line can be re-added. Otherwise, it says nothing about how a bad or stale line_id is handled, and annotations already cover the non-read-only, closed-world scope.

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 with no filler. The key mechanism (line_id from view_cart) and the edge case (quantity 0 removes) come 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 2-parameter mutation with an output schema, the description covers the inputs and the one non-obvious side effect. The only gap is the missing sibling routing, such as when to use remove_cart_item instead of quantity 0.

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 both parameters, including the minimum: 0 constraint and the zero-removes rule, are already documented. The description restates those ideas without adding new format or validation detail, so baseline 3 applies.

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

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

States a specific verb (set quantity) on a specific resource (cart line) keyed by line_id, which is unambiguous. It does not distinguish itself from the related siblings add_to_cart or remove_cart_item, even though a quantity-0 call overlaps with remove_cart_item.

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 workflow by telling the agent to get line_id from view_cart, and it implicitly covers removal via quantity 0. It never says when to prefer this tool over add_to_cart or remove_cart_item, nor what happens on an invalid line_id, so usage guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's 'Read-only' is redundant; however 'Anonymous — no sign-in required' adds real auth context the annotations do not capture, which matters in a suite where auth_status and logout exist as siblings.

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 compact sentence with the resource and contents front-loaded, followed by two short qualifiers for auth and safety. No filler, and each clause 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?

Return shape is covered by the output schema and the description reinforces it; auth is stated and the safety profile is covered. For a zero-parameter read tool this is essentially complete, with only the absence of a named alternative keeping it from a 5.

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

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

The tool takes zero parameters, so the baseline of 4 applies and there is no parameter semantics to compensate for. The enumerated field list mirrors what the output schema already defines, adding mild but non-harmful reinforcement.

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 ('Show') and resource ('current shopping cart') and enumerates the returned contents (items, options, quantities, line prices, subtotal), which distinguishes it from siblings like get_order_history or review_order that deal with placed orders. An agent can select it without opening the schema.

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

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

Qualifying it as 'current' plus 'Anonymous — no sign-in required' implies the natural use case (pre-checkout cart inspection) and clears a common precondition, but there is no explicit when-not guidance or named alternative such as review_order for a finalized cart.

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