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

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.8/5.0
Behavior5/5

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

Goes well past the readOnly/openWorld annotations: it discloses the fee-verification policy (a leg with unverified delivery fee is never offered), the two reason values and their cost semantics, that 'more_of_the_list' yields a negative saving, that each leg gets its own handoffUrl, and that every leg independently meets its storefront minimum. This is real behavioral context an agent cannot get from structured fields.

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

Conciseness4/5

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

Front-loaded with the shopper question it answers, then behavior, then routing. It is dense and occasionally repetitive ('Say which of the two it is', 'Give the shopper both'), but nearly every sentence carries constraint or routing information, so length is mostly earned.

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?

With no output schema, the description carries the return-value burden and does: it enumerates the returned constituents, the handoff URLs, the reason discriminator, and the null case. Nothing an agent needs to interpret or act on a result is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning for max_stores by explaining that a third store introduces a third delivery fee and only wins when it reaches items the other two lack. It also frames items as 'the same shape as optimize_delivery', which helps reuse.

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?

States a specific question it answers ('can I save by ordering from more than one shop?' for a whole list) plus the concrete outputs (which items where, per-leg subtotal, fees, combined total, savings). It explicitly names the sibling it overlaps with, optimize_delivery, so an agent can separate the two without opening schemas.

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?

Gives an explicit when-to-call rule: 'call this one only when the shopper asks about splitting specifically, or to raise max_stores to 3', and notes optimize_delivery already returns splitOrder. It also tells the agent what to do when splitOrder is null — report plainly and point at the single-order recommendation, do not retry.

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