ze_checkout_previewPreview Zé Delivery checkout details without placing an order or charging. Use this read-only query to verify the order summary before finalizing.
Read-only loadCheckout query. Does not run the manageCheckout mutation and does not charge.
| Name | Required | Description | Default |
|---|---|---|---|
| privacy_mode | No | ||
| response_format | No | markdown |
Changes observed during successful MCP inspections.
v0.1.4Does 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.