Zé Delivery MCP

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

Annotations already convey that this is a non-read, destructive write. The description adds that the operation is 'Dual-gated' and 'Does not checkout,' which are useful boundary statements. However, it does not explain what the two gates are or what side effects applying a coupon may have on the cart or order.

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 compact line, front-loaded with a code signature and two high-signal caveats. There is slight redundancy because 'applyCoupon(couponCode: String!)' repeats the tool name and parameter, but the overall structure is efficient and easy to scan.

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

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

There is no output schema, and the description does not explain return behavior, outcome confirmation, or what the second gate is. The crucial 'dual-gated' mechanism is never expanded, leaving the definition incomplete for a write tool that requires explicit user intent.

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 only 33%, so the description should compensate for undocumented parameters. It merely repeats the couponCode signature and does not explain coupon code semantics, response_format behavior, or how explicit_user_intent gates the operation. This leaves most parameters semantically 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 action ('applyCoupon') and explicitly disambiguates from checkout operations with 'Does not checkout.' It is clear about the verb and resource, though it relies partly on the title and does not specify whether the coupon applies to a cart or an 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?

The description gives only an implied usage context: this tool applies a coupon and does not perform checkout. It does not name an alternative tool, such as ze_checkout_preview or ze_complete_checkout, nor does it explain when to use this tool versus those siblings. 'Dual-gated' hints at prerequisites but leaves them unspecified.

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 indicate a destructive, non-read-only operation. The description adds useful behavioral context beyond annotations: it is dual-gated, fail-closed on 18+ confirmation, and explicitly does not proceed to checkout. No contradiction with 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 tightly written with no fluff and front-loads the function signature. Each sentence contributes meaningful information, though the fragments could be slightly more structured.

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

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

For a tool with a nested input object, no output schema, and low schema description coverage, the description is too sparse to fully guide an agent. It does not explain what bulk_add_to_cart_input should contain, what success/failure looks like, or the precise conditions for the gates.

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 only 25%, so the description needed to explain key parameters. It alludes to dual-gating and 18+ confirmation, which helps interpret confirmed_legal_age and explicit_user_intent, but it does not clarify the required bulk_add_to_cart_input shape or the response_format behavior. This leaves major parameter semantics undocumented.

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

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

The description states the action ('Bulk add to Zé cart') and reinforces it with the API call pattern. The explicit 'Does not checkout' helps differentiate it from checkout-related siblings, though it does not detail the exact input structure.

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 gating language and 'Does not checkout' imply when this tool is appropriate versus checkout tools, but it does not explicitly state when to use it instead of other cart-related tools like ze_get_cart or ze_clear_cart_items. Usage is mostly implied rather than prescribed.

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 the tool as destructive, non-idempotent, and not read-only; the description adds genuinely new context: fail-closed error semantics, the ZE_ALLOW_MUTATIONS entitlement check, and a guest-token restriction on charging. This goes beyond what readOnlyHint/destructiveHint convey, though it stops short of describing post-cancellation side effects or response behavior.

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 with zero filler, front-loaded with the most important trait ('Fail-closed'). Each clause earns its place: error behavior, the mutation-and-intent gates, and the guest-token restriction.

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

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

For a low-complexity destructive tool, the description plus annotations cover the core invocation decision: preconditions, required parameter, format choice, and safety profile. The remaining gaps are the response content (no output schema exists) and the provenance/format of order_id, so it is strong but not fully self-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 low (33%), so the description must compensate; it adds meaning for explicit_user_intent by naming it as a mandatory gate, and response_format is self-documenting via its enum/default. However, the required order_id receives no semantic guidance beyond minLength — no source, format, or provenance hint — leaving the most critical parameter under-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?

The title states the exact verb+resource ('Cancel a Zé order') and the '(gated)' qualifier signals the consent-gating behavior. This clearly distinguishes it from siblings like ze_place_order, ze_track_order, and ze_order_history, and the description's fail-closed framing reinforces the action's safety-sensitive nature.

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 concrete preconditions for a successful call — ZE_ALLOW_MUTATIONS must be enabled and explicit_user_intent must be true — which tells an agent when it is appropriate to invoke this tool. It also implies an exclusion ('Guest tokens cannot charge'), but it never names an alternative tool or explicitly says when not to use it beyond that constraint.

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 non-destructive, so the description needs only to add context. The phrase 'writes stay gated' adds some context about permissions scope, and 'unofficial' warns about provenance, but it does not disclose output structure or failure modes.

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, front-loaded sentence with no padding or repetition. Its phrasing is slightly informal and noun-like, but every word adds information about scope.

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, optional-parameter, read-only capabilities tool, the description gives adequate scope and is consistent with the annotations. Since there is no output schema, a slightly more explicit statement of what gets returned would make it fully complete.

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 never mentions the response_format parameter, so it does not compensate for the low schema coverage. The enum and default in the schema make the single option understandable, but the description contributes no parameter meaning.

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 identifies the tool as a report of what the unofficial MCP can read and which writes remain gated, which is more specific than a tautology and distinguishes it from sibling read/write operations. It lacks an explicit imperative verb like 'List' or 'Return,' but the intent 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?

No explicit when-to-use guidance or alternatives are mentioned; the agent must infer that this is a discovery/metadata tool from the name and phrasing. It does not say to call it before other tools or how it relates to ze_privacy_audit or ze_place_order.

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. The description adds value beyond annotations by explicitly stating that it does not run the manageCheckout mutation and does not charge, disclosing the most important user-facing side effects. This goes 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?

The description is two short, front-loaded sentences. The first sentence states the core purpose and read-only nature; the second clarifies what it does not do. Every word earns its place 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?

The tool is simple, has optional parameters with enums, and annotations cover the safety profile. However, there is no output schema and the description does not state what the preview returns or how response_format affects the output. This is a gap, but the core calling context is adequate for a basic preview operation.

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 description provides no information about privacy_mode or response_format. With two parameters both lacking schema descriptions, the tool description was expected to compensate but remains silent, leaving the agent without any added meaning for parameter selection.

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 ('Read-only loadCheckout query') and explicitly distinguishes itself from mutating operations ('Does not run the manageCheckout mutation'). This clearly differentiates it from sibling checkout tools that perform actual orders or mutations.

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 clear context for use: it is a read-only preview that will not charge or mutate. This implies the tool is appropriate when the agent needs to inspect checkout details without performing the final action. It does not explicitly name sibling alternatives, but the negative constraints give practical 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 carry destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds some behavioral context with 'Dual-gated' and 'Does not checkout', but it does not disclose what exactly is destroyed or whether the action is reversible. The bar is lower because annotations exist, so this is minimally adequate.

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 very short and wastes few words, but it consists of fragments rather than structured sentences. 'clearCartItems' is redundant with the tool name, and the remaining phrases are terse to the point of being 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 destructive, gated write operation with no output schema, an agent still needs to know that this clears all cart items, what the second gate is, and what response format to expect. 'Dual-gated' is left unexplained, and the description omits these essentials.

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 only 50%: explicit_user_intent is documented in the schema, but response_format is not. The description adds no meaning to either parameter; 'Dual-gated' only vaguely references the intent gate without explaining the confirmation requirement or the response_format options.

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 never states the operation in its own words; 'clearCartItems' merely repeats the tool name. 'Does not checkout' distinguishes it somewhat from checkout-related siblings, but the purpose is mostly inferred from the title and schema rather than explicitly defined.

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 when-to-use guidance is provided. There are no exclusions or alternatives mentioned beyond 'Does not checkout', and 'Dual-gated' hints at conditions without explaining when the tool should be invoked or how it relates to ze_get_cart, ze_bulk_add_to_cart, or ze_complete_checkout.

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 mark this as non-read-only, destructive, and non-idempotent. The description adds useful behavioral context beyond annotations: it requires an access token or returns 401, and it enforces dual gating plus an 18+ confirmation. This is meaningful operational context, though the exact side effects remain implicit.

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 very short and contains no filler, which is good. However, it relies on cryptic phrasing like 'Dual-gated plus 18+ confirmation' and an abrupt noun-phrase style, making it less clear than it could be without much extra length.

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 write operation with no output schema, 0 required parameters, and subtle safety-gate booleans that default to false. The description does not explain return behavior, which flags must be explicitly set to true, or what consequences completing checkout has. An agent cannot invoke this tool reliably from this description alone.

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 only 25%, so the description must compensate. It hints at '18+ confirmation' and 'dual-gated,' which loosely maps to confirmed_legal_age and explicit_user_intent, but it never explicitly names those parameters, explains response_format, or describes the nested input object. This is insufficient for the low schema coverage.

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

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

The title and description clearly identify a 'complete checkout' operation with gated payment, which distinguishes it from checkout preview/load tools. It lacks explicit differentiation from ze_place_order, but the core verb and resource are specific enough.

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 an authentication prerequisite but no guidance on when to use this tool versus alternatives like ze_place_order or ze_checkout_preview. No exclusions or preferred invocation context are stated.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context with 'token present', 'mutations off by default', and the 'unofficial' warning, all of which are consistent with the annotations. However, it does not explain what the tool actually returns or any side effects beyond those 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?

The description is very short, with no filler or redundant restatements of the title. The telegraphic style is compact, though the 'Local doctor' metaphor is ambiguous.

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

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

For a tool with one optional parameter and strong read-only annotations, the description is nearly sufficient for a basic call. But it leaves the output format and exact semantics ('Local doctor', what 'mutations off by default' means for the return value) underspecified.

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 needed to explain the 'response_format' parameter. It does not mention the parameter at all; the schema's enum/default are self-explanatory, but the description adds no parameter-specific meaning.

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 the metaphor 'Local doctor' and lists status dimensions ('token present', 'mutations off by default', 'unofficial Zé Delivery GraphQL'), so it suggests a diagnostic/status tool, but it never states a specific verb such as 'checks' or 'returns'. It also does not differentiate itself from sibling diagnostic tools like ze_capabilities or ze_privacy_audit.

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 guidance on when to call this tool as opposed to ze_capabilities, ze_privacy_audit, or ze_logout. No prerequisites such as 'call after authentication' or conditions for selecting response_format are given.

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 establish readOnly, idempotent, open-world, and non-destructive behavior. The description adds a small behavioral detail about GraphQL validation requiring the 'cart' field, but it does not disclose auth requirements, rate limits, or response behavior beyond 'id'.

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 very short, front-loaded with the query, and contains no filler. However, the validation note is cryptic and would benefit from more useful structure, so it is not perfect.

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 and 0% parameter documentation, the description is too incomplete for an agent to know what privacy modes mean, what format options produce, or what the full response looks like. It is minimally sufficient only for a trivial cart lookup.

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?

Input schema description coverage is 0%, and the description contains no explanation of privacy_mode or response_format. The GraphQL snippet refers to a 'cart' field, not to the two input parameters, so the description does not compensate for the missing schema descriptions.

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 title 'Inspect Zé cart' and the GraphQL fragment 'loadCart { cart { id } }' name a specific verb and resource, so the tool's purpose is clear. It does not explicitly distinguish itself from sibling tools, but the cart-inspection intent is unambiguous.

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

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

The description gives no guidance on when to use this tool instead of alternatives such as ze_checkout_preview or ze_clear_cart_items. Any usage rule is only implied by the tool's name and title, not 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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful context beyond the annotations by noting the API is 'unofficial' and 'public,' which signals stability and access assumptions. It also reinforces the no-side-effect guarantee, though it does not discuss rate limits or output details.

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

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

The description is two short sentences with no filler. The core operation is front-loaded, and the second sentence meaningfully reinforces that the tool is non-destructive. Every word 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?

The tool is simple, has no required parameters, and annotations cover the safety profile, so the description is minimally adequate. However, it does not explain what the returned category data looks like, what the privacy_mode options control, or how this tool relates to ze_list_groups. Since there is no output schema, an agent is left to guess at response behavior.

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 description provides no explanation of either parameter. The 'privacy_mode' enum values summary/structured/raw are especially opaque and are left entirely unexplained, while response_format also receives no guidance about when to choose markdown vs json. The description adds no meaning beyond the parameter 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 clearly identifies a specific operation: a read-only list of categories on a named GraphQL endpoint. It explicitly says 'Does not place an order,' which helps distinguish it from order-related sibling tools. The resource and verb are unambiguous.

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

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

Usage context is mostly implied by the name and title; the description does not explicitly state when to use this tool over alternatives. The phrase 'Does not place an order' gives only a negative scoping hint and does not address sibling tools like ze_list_groups or ze_search.

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 destructuringHint false, so the safety posture is covered. The description adds domain-specific reassurance that no order is placed, which is helpful context, but it does not go beyond that to describe output shape, pagination, or any other behaviors.

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 very short and front-loaded with the core action. The second sentence is useful for avoiding a dangerous misunderstanding, though the word 'Read-only' is somewhat redundant with the readOnlyHint annotation.

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 is simple and has strong annotations, so the lack of an output schema is not critical. However, the description does not explain the meaning of privacy_mode or response_format, nor what the returned groups contain beyond the examples. It is adequate but leaves moderate 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 description coverage is 0%, and the description does not explain either parameter. The schema exposes enum values for privacy_mode and response_format, but the agent is left to infer their meaning from names alone. This is a clear gap that the description should compensate for.

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 operation: list root product groups, with concrete examples such as Ofertas and Cervejas. It also explicitly distinguishes itself from ordering tools by stating 'Does not place an order.' This makes the tool's purpose clear and separable from siblings.

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

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

The description implies when to use the tool: when needing a read-only listing of root product groups. It gives one exclusion ('Does not place an order') but does not explicitly describe when to prefer this over sibling tools like ze_list_categories or ze_search, so guidance is present but incomplete.

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 adds meaningful behavior beyond the read-only and idempotent annotations: it discloses last-four redaction, confirms no charge, and notes a session-dependent failure mode. This gives the agent useful expectations about side effects and privacy.

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 very short and contains no filler; each clause contributes either a safety guarantee, a privacy note, or a failure behavior. The parenthetical error note is compressed, but the overall structure is front-loaded and efficient.

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

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

With no output schema, the return format and the effect of privacy_mode are left unexplained, and neither parameter is documented in the schema or description. For a two-parameter tool, the definition is under-specified despite annotation coverage for safety.

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 description says nothing about privacy_mode or response_format. The parameter names and enums are somewhat self-explanatory, but the description does not compensate for the missing parameter documentation.

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 conveys that this tool lists payment methods and explicitly states it does not charge, which helps distinguish it from order/checkout siblings. However, the opening is partly redundant with the tool name, and the '200 with internal error without a full session' phrasing muddies the core purpose.

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

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

There is no explicit guidance on when to use this tool versus alternatives, and no reference to a checkout or payment flow. The only contextual hint is that a full session is needed, but no exclusions or sibling comparisons are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a strange note about 'live 200 with checkout-information-not-found without session' which does not clarify behavior in a useful way and may confuse the agent about session dependencies. No contradiction, but no added value.

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 cryptic sentence that is short but not effectively concise. It omits essential details and uses opaque jargon, sacrificing clarity for brevity. It reads as under-specified rather than deliberately compact.

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

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

With no output schema, no parameter explanations, and no usage context, the description is functionally incomplete. An agent cannot reliably determine expected inputs, return format, or error conditions, making correct invocation highly unlikely.

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 by explaining category_id, privacy_mode, and response_format. It mentions none of these parameters, leaving the agent without any guidance on required identifiers or how the enum options affect the result.

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 says 'Read-only loadCategory' which essentially restates the tool name without explaining what loading a category entails. The parenthetical 'live 200 with checkout-information-not-found without session' is cryptic and gives no clear functional meaning, nor does it distinguish this from siblings like ze_list_categories.

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 guidance on when to use this tool versus alternatives such as ze_list_categories, ze_product_detail, or ze_checkout_preview. No context about appropriate scenarios, preconditions, or exclusions is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds an important semantic clarification: despite the 'checkout' name, this tool does not complete payment. This goes beyond simply repeating annotations and helps prevent misuse. No contradiction with annotations is present.

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 compact: two short sentences with no filler. The read-only nature is stated first, and the key exclusion about payment completion is front-loaded. Every sentence adds useful 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 simple read-only tool with no required parameters, rich safety annotations, and no output schema, this is minimally viable. However, it never states what the loaded checkout contains or what the response looks like, and it leaves parameter semantics undefined. An agent could use it correctly but would miss important context about the returned data.

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

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

The description provides no information about the two parameters, privacy_mode and response_format. Schema description coverage is 0%, so the description carries the burden of explaining parameter semantics, but it does not even mention them. The enum values are somewhat self-explanatory, but a tool definition should clarify what 'summary', 'structured', 'raw', and the response formats actually affect.

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

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

The description clearly identifies the tool as a read-only checkout loader and explicitly states that it does not complete payment. This distinguishes it from payment-completing siblings like ze_complete_checkout and ze_place_order, though it does not name them directly. The core purpose is clear and specific enough for an agent to understand what the tool does.

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 'Read-only loadCheckout' conveys when to use the tool (to load checkout state without mutating anything), and 'Does not complete payment' is an explicit when-not that routes agents away from using it as a payment-completion step. However, it does not mention alternative tools by name or provide a fuller decision tree among the many 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?

The exact file that will be destroyed is named, adding concrete behavioral detail beyond the destructiveHint annotation. It also mentions the intent gate; this is already in the schema, but the file path is genuinely useful context.

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 destructive action and the one critical condition. Every word earns its place.

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

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

For a simple logout tool, the essential call information is present: exact file path, intent precondition, and destructive role. It doesn't describe the response format or post-logout state, but that is a minor gap given the tool's low complexity and no 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?

Schema description coverage is 50%: explicit_user_intent has a schema description and the tool description merely restates it, while response_format has no description but its enum and default offer adequate meaning. The description adds little paramnformation 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 the exact action — 'Deletes ~/.ze-mcp/tokens.json' — with a specific verb and resource, and the title confirms clearing the local Zé token. This clearly distinguishes it from sibling tools like ze_connection_status and ze_cancel_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?

The description makes the key precondition explicit: only use when the user has explicitly asked, matching the explicit_user_intent parameter. It doesn't name alternatives or when-not-to-use scenarios, but the tool's logout role is self-evident next to the unrelated 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 already cover the safety prfile (readOnlyHint=true, idempotentHint=true, destrutiveHint=false), so the bar is lower. The description adds 'Street/phone/GPS redacted,' a genuine behavioral disclosure about output privacy that goes beyond the annotations and gives privac_mode a raison d'être. 'Read-only' restates the annotations but the redaction note earns the extra credit.

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 fragments totaling eleven words, with the purpose front-loaded first. Every fragment carries information (scope, safety, privacy behavior) with zero filler — a model of conciseness for a simple two-parameter read tool.

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 tool with only two optional enum parameters, no required params, and no output schema, most of the picture is present: purpose, safety, and redaction behavior. The clear gaps are that privacy_mode values are left undefined and no sense of output shape, ordering, or history depth is given, though the redaction note partially substitutes for an 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?

Schema description coverage is 0%, so the description must compensate for the undocumented privacy_mode and response_format enums. The redaction note supplies context for why privacy_mode exists, but the description never explains what summary/structured/raw each return or how they differ across modes; response_format is self-evident from its enum values and default.

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

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

The description clearly identifies the resource ('Past consumer orders') and the tool's read-only nature, which distinguishes it from mutating siblings like ze_place_order and ze_cancel_order. The verb is implicit ('retrieve/list') rather than explicit, and it doesn't name ze_track_order as the sibling for active orders, but the scope is unambiguous.

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

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

No when-to-use or when-not-to-use guidance is provided, and no alternatives are named despite a sibling set containing overlapping tools like ze_track_order and ze_search. The word 'Past' faintly implies a historrical scope, but an agent must infer the selection boundary on its own.

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 adds meaningful behavioral context beyond the annotations: fail-closed behavior, required environment flag, explicit user intent requirement, guest charge restriction, and default-example safety. This complements the destructiveHint and readOnlyHint annotations without contradicting them.

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, purposeful sentences with no filler. The most important safety information, fail-closed behavior, is front-loaded, and every sentence adds distinct value.

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

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

For a destructive mutation with a free-form input parameter and no output schema, the description is incomplete. It covers safety gates well, but it does not explain what goes into the input object, how confirmed_legal_age factors in, or what a successful call returns, making correct invocation underspecified.

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 only 25%, and the description does not compensate. It reinforces explicit_user_intent, but provides no guidance for the critical free-form input object, response_format, or confirmed_legal_age, leaving the agent to guess what payload structure is expected.

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 title and description clearly identify the action as placing a Zé order and signal it is gated. However, it does not distinguish this from the closely related sibling ze_complete_checkout, so an agent must infer which action is appropriate.

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 clear invocation conditions: it requires ZE_ALLOW_MUTATIONS and explicit_user_intent, and it warns that guest tokens cannot charge and default examples never enable this. It does not explicitly state when to prefer this over ze_complete_checkout, but the preconditions and exclusions provide actionable 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?

The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful context beyond those annotations by revealing that it reports redaction defaults and the gating condition for place-order, which helps an agent understand the system state without invoking place_order. No contradiction with 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 sentence with no filler, front-loaded with the main verb and content. Every part contributes meaningful information about what the audit reports.

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-required-parameter read-only tool, the description gives enough information for an agent to decide to invoke it and understand the key output areas. It does not explain what 'both gates' refers to, and there is no output schema, but the core behavior and scope are adequately conveyed.

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 only parameter, response_format, is not mentioned in the description at all. The schema offers an enum and default but no explanatory prose, and with 0% schema description coverage the description was expected to compensate; it does not. The parameter is simple and optional, so this is not severely misleading, but the description provides no parameter guidance.

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 ('Shows') and identifies the resource (privacy audit) while enumerating the exact content: redaction defaults and place-order gating status. This clearly distinguishes it from sibling tools like ze_search or ze_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?

The description implies when to use this tool: to check privacy redaction defaults and whether place-order is currently enabled. However, it does not explicitly state when to use it versus alternatives or provide any exclusions or prerequisites.

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, openWorldHint, idempotentHint, and destructiveHint:false. The description only repeats 'Read-only' and adds no new behavioral context such as how privacy_mode affects output or how response_format changes the result. There is no contradiction.

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 very short and front-loaded, stating the operation before the read-only note. It has little fluff, though 'with category' is unclear and somewhat reduces the value of the brevity.

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

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

There is no output schema, so the description should indicate what the tool returns, but it does not. With three parameters including two enum-driven modes, the definition is too sparse for an agent to invoke the tool correctly in all cases.

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 needs to compensate for missing parameter docs. It maps product_id to 'id' but leaves privacy_mode and response_format unexplained, despite both having meaningful enum options. The schema provides the enum names, but not their 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 names a concrete operation and resource ('loadProduct(id)') and marks it read-only, so an agent can tell this fetches product details. However, the phrase 'with category' is ambiguous and no sibling tool is named, so it does not explicitly distinguish itself from tools like ze_search or ze_load_category.

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 guidance about when to use this tool instead of alternatives such as ze_search, ze_load_category, or ze_checkout_preview. 'Read-only' is a safety property, not a usage condition, so the description does not help an agent decide when to call this function.

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=true, and idempotentHint=false. The description adds 'Does not charge' and reiterates the explicit_user_intent requirement, but doesn't clarify what destructive means here (e.g., whether an existing rating is overwritten or immutable). No annotation contradiction.

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 each sentence carrying some information: the action, the explicit-intent requirement, and the no-charge guarantee. No filler sentences, though the opening pseudo-signature is slightly redundant with the title and uses mismatched parameter names.

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, destructive-flagged tool with no output schema and only 25% parameter coverage, the description is too sparse. It omits expected return behavior, error/failure cases, and prerequisites like whether the order must exist or be in a rateable state. It does clarify the no-charge and explicit-intent aspects, which are useful but insufficient.

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 only 25%, so the description needed to compensate, but it merely names 'orderNumber' and 'rating' without explaining their meaning, source, or constraints. The 'orderNumber' label conflicts with the schema's 'order_id', and response_format is unaddressed. It repeats explicit_user_intent but adds little semantic value.

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

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

The description and title clearly identify the action as rating an order, with a specific verb ('rate') and resource ('order'). It is distinct from sibling checkout/cart tools, though it does not explicitly differentiate itself. The pseudo-signature 'rateOrder(orderNumber, rating)' also introduces a parameter-name mismatch with schema's 'order_id'.

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 only guidance is 'Requires explicit_user_intent', a precondition rather than a routing rule. It does not state when rating is appropriate, when it is not, or which sibling tool would be an alternative. An agent must infer usage from the tool name.

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 behavior; the description restates 'Read-only' and adds 'Does not add to cart', which is redundant but reinforces safety. It contributes one extra behavioral trait, 'unofficial GraphQL', indicating potential instability, but no rate limits or error behavior are disclosed. No contradiction found.

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 no filler. The core operation and safety qualifier are front-loaded, making it easy to parse quickly.

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?

Without an output schema and with 0% parameter coverage, the description needs to explain the optional privacy_mode parameter and return behavior. It fails to do so, leaving the agent to guess what 'summary', 'structured', and 'raw' mean in this context.

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 explain parameters. It only hints that 'query' is the queryTerm via 'searchProducts(queryTerm)', leaving privacy_mode and response_format completely unexplained beyond their enum 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 explicitly names the operation 'searchProducts(queryTerm)' and the resource 'Zé products', making the purpose unmistakable. It also distinguishes itself from sibling order/cart tools by adding 'Does not add to cart'.

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

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

The description implies use when searching products but gives no explicit when-to-use or alternative selection guidance. The exclusion 'Does not add to cart' hints at cart-related tools but does not name them or state conditions.

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 indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safe read-only nature is covered. The description adds the useful scope of 'Status only' and what is not returned, but does not describe response details, auth needs, or rate limits. This adds context without contradiction.

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 very concise and front-loaded with the essential 'Status only' point. The 'loadOrder(orderNumber)' fragment is somewhat opaque and adds little clarity beyond the schema, but the overall length and structure are efficient.

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

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

For a read-only status tool with strong annotations, the description is minimally adequate. However, it does not explain the meaning or effect of privacy_mode, what the status response contains, or how this tool relates to ze_order_history. The missing parameter guidance and return details leave clear 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 description coverage is 0%, so the description must compensate. It only mentions 'orderNumber', which loosely maps to order_id, and provides no explanation of privacy_mode or response_format. This is insufficient for three parameters.

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 the tool retrieves status for an order ('Status only') and explicitly excludes GPS polylines and courier phone, which makes the core purpose clear. It does not name or differentiate against sibling tools directly, so it falls 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?

The phrase 'Status only' implies the tool is for simple status lookups, and the exclusions suggest it is not for delivery details. However, it does not explicitly say when to use this tool versus ze_order_history or other siblings, nor name alternatives.

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