Skip to main content
Glama

Split one shopping list across two or three shops

split_order
Read-only

Answer 'can I save by ordering from more than one shop?' for a whole list. Returns which items to buy where, each leg's own subtotal, delivery fee and service fee, the combined delivered total, and what it saves against buying everything in one order. Every fee is a published one: a leg whose delivery fee we could not verify is never put in a split, because a split is a recommendation to pay a SECOND fee and it may not rest on a number we would refuse to quote for one order. reason='cheaper' means one order could buy this list and two buy it for materially less. reason='more_of_the_list' means no single storefront stocks everything, so the second order fills the gap: it costs MORE, saving is negative, and that is the honest answer rather than a hidden one. Say which of the two it is. Each leg carries its own handoffUrl, one page per order. Give the shopper both. Every leg meets its own storefront's minimum order, so both legs are placeable as they stand. Returns splitOrder: null when one order is the right answer, which is the usual case — report that plainly and point at the single-order recommendation instead of retrying. optimize_delivery already returns the same splitOrder field, so call this one only when the shopper asks about splitting specifically, or to raise max_stores to 3.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity name in Hebrew or English. Enough for chains that publish a settlement list, not enough for a storefront whose area is a polygon or a depot radius.
nearNo'lat,lng' string, e.g. '32.078,34.774'. Do not combine with address.
itemsYesThe shopping list, same shape as optimize_delivery.
intentNoThe shopper's own framing of this shop, in their own words, e.g. 'ברביקיו ל-12 אנשים'. Not a summary of the item list. Shown on each leg's handoff page next to what was priced. Optional; omit rather than inventing one.
addressNoDelivery address in Israel, free text, e.g. 'מנדלסון 1, תל אביב'. Preferred: some storefronts publish a service area that only a street address can be tested against.
slot_typeNostandard (default) or pickup.
max_storesNoHow many storefronts to spread the list over. Default 2. A third adds a third delivery fee, so it only wins when it reaches items the other two do not stock.
membershipsNoMemberships the shopper holds, e.g. ['credit_card', 'wolt_plus'].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / city / minLength
      Added value: +1
    • addedInput schema / properties / near / minLength
      Added value: +3
  2. Changed1 schema field changed
    • changedInput schema / properties / items / items / properties / pack_qty / type
      Previous value: -"number"New value: +"integer"
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

The description discloses extensive behavioral details: it only splits when delivery fees are verified, reports assumptions for unverifiable counts, handles pack quantities correctly, and clarifies that a null splitOrder means a single order is better. It goes far beyond the annotations (readOnly, openWorld, non-destructive) by explaining side effects and edge cases.

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

Conciseness1/5

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

The description is excessively verbose and repetitive, with phrases like 'Every fee is a published one' and 'Every leg meets its own storefront's minimum order' stated multiple times. It could be condensed to a few sentences without losing meaning, harming readability and maintainability.

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?

Despite verbosity, the description is thorough: it covers purpose, usage conditions, behavioral edge cases, assumptions reporting, return value semantics (splitOrder), and comparisons to the sibling tool. It effectively addresses all relevant contexts for a developer integrating this tool.

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?

While the schema already covers 100% of parameters with detailed descriptions, the tool description adds useful cross-reference context (e.g., items are 'same shape as optimize_delivery') and reinforces the intent parameter's purpose. This supplements the schema without duplicating it.

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

Purpose4/5

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

The description clearly states the tool's core action: splitting a shopping list across multiple stores and evaluating savings vs. a single order. It distinguishes from sibling tools by referencing optimize_delivery, though the added caveats and repetitive phrasing slightly dilute the clarity.

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

Usage Guidelines5/5

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

Explicitly instructs when to use this tool: only when the shopper asks about splitting specifically, or to raise max_stores beyond the default. It also states optimize_delivery returns the same splitOrder field, providing a clear alternative and preventing misuse.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources