SuperMCP

{
  "name": "SuperMCP",
  "description": "Israeli online supermarket pricing for AI agents. Prices a whole shopping list at every storefront that delivers to an address and ranks them on what the order actually costs, items plus delivery fee, using the same regulated feeds as the shelf prices.",
  "supportedInterfaces": [
    {
      "url": "https://supermcp.web.app/mcp",
      "protocolBinding": "https://supermcp.web.app/bindings/mcp-streamable-http/v1",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "SuperMCP",
    "url": "https://supermcp.web.app"
  },
  "version": "b594e1a4",
  "documentationUrl": "https://supermcp.web.app/openapi.json",
  "iconUrl": "https://supermcp.web.app/icon-512.png",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "extendedAgentCard": false
  },
  "defaultInputModes": [
    "application/json"
  ],
  "defaultOutputModes": [
    "application/json"
  ],
  "skills": [
    {
      "id": "optimize_delivery",
      "name": "Price a shopping list for delivery",
      "description": "Price a whole shopping list at every Israeli online supermarket that delivers to an address, and rank them on what the order actually costs: items + delivery fee + service fee. Call this ONCE with the full list \u2014 never price lines separately. This is SuperMCP's shopping-list tool for online supermarket delivery. THE HEADLINE FIGURE IS deliveredTotal, not the item subtotal: a \u20aa35.90 delivery fee outweighs most price differences between chains. But RANK on deliveredComparableTotal, never on deliveredTotal: totalScope is priced_lines_only, so a storefront that stocks four of your twelve items reports a small deliveredTotal precisely because it cannot fill the basket. Check pricedLines against requestedLines and say when the coverage is partial. Read deliveryTerms.confidence before quoting: 'verified' was read from the retailer's own binding terms, 'reported' from a cited secondary source, 'unknown' means no fee is established and the ranking used an assumption (assumedDeliveryFee) that must not be repeated as a price. deliveryFeeIsFloor=true means the fee is a published lower bound, so quote it as 'from \u20aaX' and treat deliveredTotal as a minimum. meetsMinimum=false means the order cannot be placed as it stands; report amountToMinimum, the top-up needed. Those plans are still listed, after the orderable ones, so present them as options that need topping up rather than hiding them. Rank on cheapestDelivered only if the shopper will happily order twice: it prices missing lines at a market reference. bestSingleOrder is the fullest basket obtainable in one order. Both, and bestVerifiedTerms, carry totals only: find the storefront in plans by serviceSlug for its priced lines. When nextFeeBreak.worthTopUp is true, spending a little more makes the order cheaper overall \u2014 say so. A line carrying cheaperAlternative can be met for less AT THE SAME SHOP: it names the product, how many packs, what the line would cost instead, and the saving, promotions included. Every one is cheaper per 100g/ml/piece as well as per line, so it is a genuine saving rather than a smaller pack, and the saving can be quoted as it stands. Offer these unprompted when the shopper cares about price, and never silently swap them in \u2014 it is a different product and theirs to choose. Pin one by calling again with its productId. splitOrder, when it is not null, is the same list bought from two shops instead of one, with each leg's items, fees and its own handoffUrl. reason='cheaper' means it saves money after BOTH delivery fees; reason='more_of_the_list' means no one shop stocks everything and the second order fills the gap at extra cost, which `saving` reports as a negative. Volunteer it unprompted, and say which of the two it is. null means one order is the right answer here. If the shopper says a priced line is wrong, call suggest_similar_products with their Hebrew words and the rejected product_id, then call this tool again with that product_id on the line. Storefronts that cannot serve this basket come back in unavailableStores with a reason. By default only the actionable ones are listed: below_minimum_order, and price_feed_stale for a chain that delivers here but has published no prices for over a fortnight, which is therefore not in plans at all and must not be presented as an option. A plan flagged priceFeedStale is a milder case, over a week old: still worth comparing, but quote it as what the shop last published on priceFeedAsOf. If no storefront inside the fortnight can take the order, the abandoned ones come back in plans rather than leaving the shopper with nothing, and notes says so. unavailableStoresOmitted counts the rest, all ruled out on the address alone. A plan may carry venues: branches of one marketplace chain that priced this basket identically, collapsed into one row. Any slug in it works with get_delivery_terms. By default only the recommended storefronts carry a `lines` breakdown; every other plan reports its totals and pricedLines with `lines: []`. That is not a gap \u2014 re-call with response_detail=standard only if you must compare the same item's price across chains. When the shopper settles on a storefront, give them that plan's handoffUrl: it opens the whole basket as one Hebrew page, every line with its price and its own product link. Hand over that one link rather than the per-line link fields, which leave the shopper opening a tab per item. Say that the page shows the prices this answer was built on.",
      "tags": [
        "groceries",
        "israel",
        "shopping-list",
        "delivery",
        "prices"
      ]
    },
    {
      "id": "split_order",
      "name": "Split one shopping list across two or three shops",
      "description": "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 \u2014 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.",
      "tags": [
        "groceries",
        "israel",
        "shopping-list",
        "delivery",
        "savings"
      ]
    },
    {
      "id": "list_delivery_options",
      "name": "List storefronts that deliver here",
      "description": "Which Israeli online supermarkets deliver to an address, with each one's delivery fee, minimum order, free-delivery threshold and whether it offers click-and-collect \u2014 without pricing a basket. Use for 'who delivers to me?'. For 'what will my shopping cost delivered?', use optimize_delivery instead. Every entry carries deliveryTerms.confidence and verifiedAt; quote a fee only when it is verified or reported, and say the fee is unknown otherwise. Every entry also carries catalogSize (priced items we hold) and catalogVisibility. catalogVisibility 'partial_index' means WE cannot see the whole shop: that storefront's prices are read off a website that cannot be paged, so catalogSize is the part we indexed and says nothing about how much the retailer stocks. 'full_catalogue' means the count is the retailer's complete published price file. Never recommend a storefront on its delivery fee alone: one where we hold a few hundred items cannot fill a normal basket, so price the basket with optimize_delivery before naming a winner. An entry carrying notesRef instead of notes shares its terms with other storefronts: read the text from sharedNotes[notesRef]. Marketplace terms are written once per chain and held per venue, so they would otherwise repeat verbatim on every branch.",
      "tags": [
        "groceries",
        "israel",
        "delivery",
        "coverage"
      ]
    },
    {
      "id": "get_delivery_terms",
      "name": "Get one storefront's delivery terms",
      "description": "The full published terms for a single online storefront: every fee band over basket size, the minimum order, the service area, and where each figure came from. Use to explain a deliveryFee an optimize_delivery plan reported, or to answer 'what do I need to spend for free delivery?'. Take the slug from a plan's serviceSlug. catalogSize and catalogVisibility are reported here only when already known: this tool answers from published terms and never waits on the item count. A null in either means one of two things, and they are not interchangeable: we hold no priced store for this storefront, OR the count has not been taken yet. Call list_delivery_options for a count you can rely on being present; never read a null here as an empty shop.",
      "tags": [
        "groceries",
        "israel",
        "delivery",
        "fees"
      ]
    },
    {
      "id": "search_products",
      "name": "Search products",
      "description": "Search the canonical product catalog by free text (Hebrew or English), brand, category, or exact GTIN, and answer 'how much is X' for a SINGLE item. Also matches chain listing names. Send city or address and every hit comes back priced: fromPrice is the lowest it goes for at any storefront delivering there, so quote it as 'from \u20aaX across N storefronts' (pricedAtStorefronts) and never as one national price \u2014 there is no such thing here. pricedAtStorefronts=1 is one shop's price, not a market rate. normalizedUnitPrice is that same money per 100g/100ml/piece: compare on it, NOT on fromPrice, because a smaller pack is cheaper to buy and usually dearer per gram. Results come back cheapest per unit first. fromPrice is the ordinary price, never a loyalty-club or coupon rate. Without a location nothing can be priced and the price fields are absent. For a whole shopping list call optimize_delivery ONCE with query items \u2014 never price lines one by one here, and never add these prices up: they come from different storefronts and each carries its own delivery fee. After optimize_delivery priced the wrong product, call suggest_similar_products with the shopper's Hebrew words and the rejected product_id, then call optimize_delivery again with that product_id. Returns canonical products (not per-chain detail); call get_product for listings.",
      "tags": [
        "groceries",
        "israel",
        "catalogue",
        "search"
      ]
    },
    {
      "id": "get_product",
      "name": "Get product",
      "description": "Fetch full detail for one canonical product by product_id (UUID) or GTIN barcode, including every per-chain listing (chain-specific item code, display name, and package size). Use after search_products to confirm identity, or directly when the GTIN is already known. Each listing carries `orderable`: false means no delivery or pickup storefront prices it, so it cannot be bought through this API. A listing is catalogue identity, not availability: never present an `orderable: false` chain as somewhere the shopper can buy. When every listing is `orderable: false` the product is not purchasable right now, whatever its chains suggest.",
      "tags": [
        "groceries",
        "israel",
        "catalogue"
      ]
    },
    {
      "id": "suggest_similar_products",
      "name": "Suggest similar products",
      "description": "After optimize_delivery priced the wrong product, use this to show other things the shopper might have meant. Send their words in HEBREW (original line or the correction) and the rejected product_id so that SKU is dropped. Example: priced \u05e0\u05e7\u05e0\u05d9\u05e7\u05d9\u05d5\u05ea \u05e4\u05e8\u05d2\u05d9\u05d5\u05ea, shopper said thigh cuts \u2192 query='\u05e4\u05e8\u05d2\u05d9\u05d5\u05ea' or '\u05e9\u05d5\u05e7\u05d9\u05d9\u05dd', product_id=<the sausage>. Then call optimize_delivery again with the same list, that line pinned to the chosen product_id. Also answers 'is there a cheaper one?': every suggestion carries fromPrice, the lowest it goes for at any storefront delivering to this address, and normalizedUnitPrice, the same money per 100g/100ml/piece. Compare on normalizedUnitPrice, NOT on fromPrice: a smaller pack is cheaper to buy and usually dearer per gram, so a saving claimed on fromPrice alone is wrong whenever the pack sizes differ. Results come back cheapest per unit first, and `rejected` carries the same fields so the swap is directly comparable. fromPrice is a floor across storefronts, so quote it as 'from \u20aaX'; pricedAtStorefronts=1 means it is one shop's price rather than a market rate. Send city or address, or no price can be reported at all. Do not use this for a first-pass shopping list \u2014 call optimize_delivery once with every line.",
      "tags": [
        "groceries",
        "israel",
        "catalogue",
        "substitutions"
      ]
    },
    {
      "id": "get_promotions",
      "name": "Get promotions",
      "description": "List promotions (e.g. '2 for 30\u20aa', club-member price, second-unit discount), optionally filtered by store_id or product_id, and by active=true to only return promotions currently running. Use this to explain why an optimize_delivery line price is lower than list_price.",
      "tags": [
        "groceries",
        "israel",
        "promotions",
        "prices"
      ]
    }
  ]
}