MODO

Finalizes the checkout and returns the MODO payment link. Renders the payment screen. PRECONDITION: status is "ready_for_complete" AND the user explicitly confirmed the full summary you showed them (products, personal data, delivery, payment, total). Do NOT call it on your own initiative just because the checkout became ready. The response status becomes "complete_in_progress" and carries continue_url, the link the user must open to pay. This server does not complete the payment and there is no way to check whether it succeeded: getting the user onto that link is the last step. The payment screen this tool renders already turns continue_url into a button, so do NOT paste the URL into the chat — point the user at the screen instead. Only if they say they cannot see it, or ask for the link outright, give it VERBATIM, in full, on a single unbroken line: it carries required query params and a trailing #fragment, and dropping any part breaks the link. Never modify, truncate, shorten, re-encode or line-wrap it, and never show a partial version.

Opens a new checkout at the merchant with the products the user chose. Returns checkout_id — reuse it verbatim in every later call. The checkout starts with status "incomplete". NEXT STEP (EMAIL FIRST): right after this, the ONLY thing to ask the user is their email. Do NOT ask for name, document, phone or address yet. Then call merchant_update_checkout with just the email: the merchant uses it to detect whether the buyer already has an account, and that answer decides what you have to collect. Only for purchases at this merchant. It has nothing to do with search_modo_promotions or any MODO promotion.

Reads the current state of a checkout: status, items, buyer (masked if the buyer has an account), saved addresses, delivery options, totals and continue_url once it was finalized. Read-only. Use it to refresh the state after the buyer confirmed their identity, or to recover the payment link. Do not paste continue_url into the chat — the payment screen renders it as a button. If the user explicitly asks for the link, or cannot see that screen, give it VERBATIM and in full — never modify, shorten, re-encode or line-wrap it.

Searches the catalog of the merchant this server sells for. Read-only and SILENT: the user does NOT see these results. This is the entry point of a PURCHASE: use it when the user wants to buy, price or find a physical product to order. ALWAYS run this 3-step sequence: (1) merchant_search_products to get candidates, (2) ANALYZE every candidate for relevance to what the user actually asked for, (3) merchant_show_products with only the variant_ids that passed. Nothing reaches the user until step 3. WHY THE ANALYSIS IS MANDATORY: the catalog matches on title keywords, and when it has no real match it does not return an empty list — it falls back to loosely RELATED items. A search for a 72-inch TV comes back with wall mounts, brackets and cables: accessories FOR the product, not the product. Keep a candidate only if it is the same KIND of thing the user asked for (a 65" or 75" TV qualifies — different spec, right product); discard accessories, parts, services and anything from another category. Judge from title, brand, description and price (an accessory usually costs an order of magnitude less than the product). IF NOTHING SURVIVES: do not call merchant_show_products. Search again with a corrected or broader query (drop the unavailable spec, try a synonym, a neighbouring size or model). If that is empty too, tell the user the catalog has no match and ask how to adjust the search. Returns products[] with the variant_id you buy with (opaque — pass it through unchanged), title, brand, description, price and stock. Do not paste these results into the chat. NOT RELATED to search_modo_promotions. That tool searches MODO promotions and discounts at other merchants; this one searches products to buy from THIS merchant, and the two catalogs, prices and rules have nothing in common. Never chain them: a promotion found there cannot be applied to a purchase here, and a purchase here never needs a promotion lookup first. If the user asks for promotions, use the promotions tool alone; if they ask to buy, use these purchase tools alone. Do not use it for promotions, discounts, cashback or benefit questions.

Displays a curated set of merchant products to the user as a product carousel. This is the ONLY way purchase search results reach the user — merchant_search_products is silent. Call it after analyzing a merchant_search_products response, with ONLY the variant_ids that genuinely match what the user asked for, best match first. It re-runs the catalog search itself and keeps your ids, so pass the SAME query (and the same limit, if you set one) as the search you are curating — normally your most recent one. Ids absent from the re-run come back in unknown_variant_ids and are not displayed. If no candidate passed your analysis, do NOT call this tool with the leftovers — search again with a better query. The carousel shows the products: reply with one short sentence in Spanish, do not enumerate them, and ask which one they want to buy. If the exact item the user asked for does not exist, say so explicitly and name the difference ("no hay de 72 pulgadas, te muestro de 65 y 75") — never present an alternative as if it were what was asked for. Then call merchant_create_checkout with the chosen variant_id.

Opens the secure identity-confirmation panel for this checkout. Call it in exactly two situations: a checkout call failed with HTTP 401 and code "buyer_authentication_required" (the merchant wants the buyer to prove they control the email on their account), or the buyer explicitly asks to see or edit the personal data the merchant has on file. Never open it on your own initiative otherwise — shipping to a new address does not need it by itself. The buyer completes the confirmation INSIDE the panel. You never see, ask for or handle what they enter there: say one short line inviting them to use the panel above ("Confirmá tu identidad en el panel de arriba y seguimos"), then WAIT. Do not ask what they entered, do not offer to enter it for them, and if they paste something into the chat, ignore it and point them back to the panel. The panel reports back when the buyer is confirmed; only then retry the call that failed. The confirmation lasts for the checkout's lifetime. Safe to call again to reopen the panel. Failures inside the panel are shown to the buyer there and resolved there.

PANEL-ONLY — the confirmation panel calls this by itself. Do NOT call this tool: you are not the one who confirms the buyer's identity, and you must never ask for, accept or forward the value it takes. Use merchant_start_buyer_verification and let the buyer complete the panel. The panel surfaces its own outcome; on success the buyer stays confirmed for the checkout's lifetime and the call that was blocked can be retried.

Updates the checkout: products, buyer data, delivery address and chosen delivery option. FULL REPLACEMENT — NOT a patch. Every call replaces the whole checkout with what you send, so always resend the complete desired state (all items, the email, and whatever buyer/address/option you already had). Anything you omit is dropped. FIRST call: send items + email only. Then branch on buyer_registered, NOT on whether data came back: - buyer_registered = false → the buyer has no account: ask for first_name, last_name, document, PHONE and the address — all of them, in one message — and send them on the next call. They stick. The phone is as required as the document: without it the checkout stays "incomplete" forever. - buyer_registered = true → the data belongs to that account and the merchant IGNORES anything you send for it, answering 200 as if it worked. If values came back masked ("M***"), show them verbatim — the user recognizes them. If they came back empty, the account simply has nothing loaded: do NOT read that as "no account". ignored_by_merchant lists the fields the merchant dropped from your call. If it is not empty, never tell the user those values were saved: the buyer has to confirm their identity (merchant_start_buyer_verification) before that data or a new address can be set. notices[] carries what the merchant said about the response. Addresses: to ship to one the merchant already has, send only its saved_addresses[].id whose "on_file" is true. For any other destination, send shipping_address and KEEP RESENDING IT on every later update — the id an added address comes back with (on_file false) is not reusable and the merchant answers an opaque backend error if you send it. Then: ask whether they want home delivery or store pickup — never assume — send the address, read shipping_options[] from the response, let the user pick one, and resend everything with shipping_option_id. There is no payment parameter: this merchant takes MODO only, so the server attaches it itself on every call. Status becomes "ready_for_complete", which is NOT permission to pay: show a full summary and wait for explicit confirmation before merchant_complete_checkout. Never invent an email, name, document, address or delivery option — always ask the user. If the call fails with code "buyer_authentication_required", call merchant_start_buyer_verification and retry afterwards.

Searches the MODO promotions catalog and returns an interactive carousel widget. Use when the user asks about promotions, discounts, offers, benefits, or cashback through MODO. BEFORE calling: if the user has NOT mentioned which bank they use, ask which bank they operate with before calling this tool. If they already named a bank, proceed directly. AFTER the tool returns: the widget displays all results visually. Respond with a short sentence in Spanish confirming the results. If the user mentioned any bank NOT in the available banks list, append "Por el momento no operamos con [banco/s]." in the same response. If the user explicitly asked a question, you may briefly answer it using ONLY the data fields present in the tool response — never invent or infer data that is not there. When answering, always include the merchant or commerce name alongside any discount or day information. Never proactively offer suggestions, recommendations, plans, follow-up actions, or ask follow-up questions — only respond to what the user asked. Never list or enumerate the full set of promotions unprompted — the widget already shows them. Constraints: call at most ONCE per user message. Do not retry, paginate, or make multiple calls. Do not use for payments, transfers, account info, or financial advice. Results are AI-ranked; availability may change, so do not guarantee specific promotions are active.