Skip to main content
Glama

rami_levy_clear_cart

Clear your Rami Levy shopping cart on both local and server accounts. Returns updated cart totals, and flags rejected items or stale orders so you can resolve them quickly.

Instructions

Empty the cart completely, both locally and on the real Rami Levy account. Returns cartTotal (local estimate) and serverTotal (Rami Levy's own total — authoritative). ok:false with a transport reason means nothing changed. reason items_rejected means the server refused the listed products; they have been removed from the cart too, so tell the user and pick alternatives. If resetAfterOrder {orderId, createdAt} is present, an order was placed since the last sync, so the items from before it were treated as bought and cleared first; tell the user the cart started fresh after that order.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden. It discloses that both local and server carts are emptied, that transport failures mean nothing changed, that items_rejected removes products and requires user follow-up, and that resetAfterOrder changes the starting cart state.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: main action, return semantics, failure modes, and the resetAfterOrder edge case. It is front-loaded with the core purpose and avoids repeating schema or annotation information.

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

Completeness5/5

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

Without an output schema, the description must explain return values and edge cases, and it does so thoroughly. It covers what each return field means, what to do when items are rejected, and how to interpret resetAfterOrder, making the tool safely callable.

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

Parameters4/5

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

The tool has zero parameters, so there is nothing for the description to document. The baseline of 4 applies, and the description instead usefully explains the return envelope and outcome semantics.

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

Purpose5/5

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

The first sentence states a specific verb and resource: 'Empty the cart completely, both locally and on the real Rami Levy account.' It clearly distinguishes this from siblings like remove_item and view_cart by emphasizing complete cart clearing.

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

Usage Guidelines4/5

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

The description makes the tool's scope obvious: use it to empty the entire cart, with detailed handling for ok:false and items_rejected results. It doesn't explicitly name remove_item as the alternative for partial removals, but the context and sibling list make that distinction clear.

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