ze_order_historyRetrieve past consumer orders. Street, phone, and GPS details are redacted for privacy.
Past consumer orders. Read-only. Street/phone/GPS redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| privacy_mode | No | ||
| response_format | No | markdown |
Changes observed during successful MCP inspections.
v0.1.2Does 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.