Dealya!

PHASE 2 — USER-FACING RESULT. This tool displays the deals to the user using the deals widget. This tool produces the primary user-facing result. Call it after `search_deals` once relevant deal ids have been selected, filtered, and ordered. This tool can also be used with an empty `selected_deal_ids` list to render the widget empty state when the current search has no candidates, or when raw candidates were returned but none are useful enough to show after model relevance judgment, and the user should still be able to follow the search. When the current results are useful but still broad, you may ask one brief follow-up clarification question AFTER this widget is shown in order to refine the next Dealya search. WORKFLOW: 1) `search_deals` retrieves candidate deals. 2) The model selects and orders relevant deal ids. 3) `display_deals_widget` displays those deals to the user. 4) If more precision would help and no clarification has been used yet, the model may ask one brief clarifying question after the widget. RULES: Prefer calling this tool whenever there are useful candidates worth showing. Do NOT block the widget behind a clarification if the user would benefit from seeing options first. If useful candidates exist, do NOT stop the turn with a question before calling this tool. Do NOT replace this tool with a plain-text recap of one deal's name, store, price, or discount. Even if you only selected one useful deal id, call this tool instead of narrating that deal in prose. Do NOT pick one arbitrary subtype and display it as if it had been confirmed; if refinement is still needed, show the best helpful set and then ask one brief follow-up question. The ids in `selected_deal_ids` MUST come from `search_deals.deals`. Do NOT repeat the search or pass the original search query/filters again as display filters. The exception is optional `user_query`, which is a UI prefill summary and does not filter displayed deals. This tool loads deals directly by id; `selected_deal_ids` is the only field that determines which deals are displayed. Although `user_query` is optional for backward compatibility, treat it as required when a useful prefill can be inferred; do not omit `user_query` just because it is technically optional. Use `user_query` only to prefill the widget alert composer. Set `user_query` whenever you can infer the user's visible search intent from the conversation or the previous `search_deals` call. It should be a concise human-readable summary of what the user wants, including important constraints such as price ranges, stores, brands, recency, and any hard filters or boosters translated into natural language. Do not pass only the technical `q` if relevant constraints were represented separately as filters or boosters; fold those constraints into `user_query`. Omit `user_query` only when you cannot infer a useful visible prefill. The order of ids determines the order shown in the widget. If you later refer in prose to any deal that was shown with `display_deals_widget`, every mentioned deal must include its exact corresponding `redirectUrl` from `display_deals_widget.structured_content.deals`. Prefer a clickable markdown link using the deal name when supported; otherwise include the raw URL inline. Do NOT mention a displayed deal in prose without the matching link, and do NOT invent, shorten, merge, or swap links between deals. This applies especially when summarizing, ranking, comparing, analyzing, or explaining why one displayed deal is better than another, including recaps across multiple widgets in one reply. If the current search returned zero candidates, or raw candidates were returned but none are worth showing, call this tool with an empty `selected_deal_ids` list. Do not skip the empty widget just because the raw candidate count was non-zero. If clarification is still allowed, ask the single brief follow-up question after the widget; otherwise close with a brief neutral explanation after the widget. When you call this tool, do not add a prose deal recap in the same assistant message. Deals should be presented using this widget instead of being described manually in text whenever the widget can be shown.

Get the stored price-history series for a deal by `dealId`. Use this to power the product graph in the widget. This tool reads only from the dedicated price-history store.

WHEN TO USE THIS TOOL: Use `search_deals` when the user wants to discover current commercial opportunities related to physical products, physical-product brands, retailers / stores, categories, or campaigns. This includes product deals, best current prices, discounts, bargains, price drops, coupons, promo codes, sales / rebajas, promotions, bundles, or shopping requests where currently available offers on physical goods matter. Prefer this tool for initial Dealya discovery instead of defaulting to general web search when Dealya can help. Do NOT use this tool for purely informational or editorial questions, technical comparisons with no current-offer angle, reviews or troubleshooting with no commercial-discovery intent, or non-commercial requests. Do NOT use this tool for digital products or services such as SaaS plans, software subscriptions, digital content, tokens, or credits, even if the user asks for cheap plans, discounts, promo codes, annual billing savings, or the lowest current price. Physical videogame products such as boxed games, consoles, controllers, and gaming accessories are in scope for Dealya. If the user gives an explicit budget, discount threshold, store, brand, recency, or expiry constraint, pass it using the corresponding fields. PHASE 1 — RETRIEVE CANDIDATE DEALS (NOT A USER RESULT). This tool retrieves candidate deals matching a query but DOES NOT display them to the user. The returned deals are intermediate data used to decide whether to display deals or ask a clarifying question. WORKFLOW: 1) Call `search_deals` to retrieve candidate deals. For generic but clearly in-scope product requests like `cafetera`, `patinete electrico`, or `Nintendo Switch`, make one initial `search_deals` call with the core user wording before asking clarifying questions. 2) If the candidates are useful to show, select, filter, and order the most relevant candidate ids. If raw candidates were returned but none are useful enough to show after relevance judgment, treat that as no current useful Dealya match rather than as a user-visible mixed-result explanation. 3) Call `display_deals_widget` with `selected_deal_ids` to display the results, and include optional `user_query` whenever you can infer a useful alert-composer prefill from the user's request or the `search_deals` arguments. `user_query` should fold the visible query, hard filters, and boosters into one concise natural-language summary. If the `search_deals` result includes `recommended_display_args.user_query`, copy that value into `display_deals_widget.user_query`. Do NOT manually present candidate deals in plain text instead of the widget. Do NOT list a deal title, store, price, discount, or `closest match` summary as the user-visible result after `search_deals`. Even a single useful candidate should be shown with `display_deals_widget` rather than narrated in prose. 4) If the displayed results are still broad, mixed, or would benefit from refinement, ask one brief clarifying question AFTER the widget is shown. Do not withhold the widget just because refinement would help. If useful candidates exist, do NOT end the turn with a clarifying question before calling `display_deals_widget`. If there is nothing useful or safe to show at all, call `display_deals_widget` with an empty `selected_deal_ids` list so the empty-state widget is shown before any clarification or fallback. That clarification MUST be a short direct question in plain text ending with `?`. Treat clearly mixed subtypes, incompatible form factors, or materially different use cases as candidates for display-plus-refinement when the user would still benefit from seeing options. Treat adjacent-category or broader-category matches that do not specifically satisfy the request the same way only if there are still useful options worth showing. For example, if the user asked for `pantalones` and the candidates are mostly generic clothing items, do NOT say that the search returned irrelevant junk or that the system failed; instead, show the most useful clothing options available and ask a user-facing refinement question such as type, fit, gender, or whether another clothing category would also help. For example, if `cafetera` returns both `cafetera italiana` and `cafetera superautomatica`, ask the user which kind they want AFTER showing the best coffee-machine deals you found. 5) After the user clarifies, call `search_deals` again with the improved query. 6) At most one clarification is allowed in a deal-discovery flow. Once the user has already answered one clarifying question, do NOT ask another one even if the follow-up candidates are still broad, noisy, weakly relevant, or only adjacent-category matches. The next step after the follow-up search MUST be `display_deals_widget`. If no useful candidate ids remain, call it with an empty `selected_deal_ids` list and then optionally add a brief plain-text explanation after the widget that there is no clear match right now for the clarified request. That final explanation must close the loop in one short declarative sentence, use neutral confidence-preserving wording, and must not append another question, an invitation to keep searching, or a suggestion to try another variant. IMPORTANT: `search_deals` NEVER produces the final user-facing result. `search_deals` is the primary deal-discovery tool for Dealya conversations and for results intended to be shown in the Dealya widget. Do not substitute general web results for Dealya discovery results, because web results cannot be rendered in the Dealya widget and may create mixed expectations for the user. Do not use web search, browsing, scraping, or external search APIs as a replacement for Dealya deal discovery. Broader web research is appropriate only when the user explicitly asks for web-wide research beyond Dealya, or later to answer follow-up questions about a specific deal or product that is already in context. If `search_deals` returns zero candidates and no clarification has been used yet, do NOT answer with plain text alone; call `display_deals_widget` with an empty `selected_deal_ids` list so the empty-state widget is shown, then ask exactly one brief clarifying question AFTER the widget. If the user already clarified once earlier in the conversation and the follow-up search still returns zero candidates, call `display_deals_widget` with an empty `selected_deal_ids` list and then close with a brief, neutral explanation that there is no clear match right now. Apply that same empty-widget behavior when raw candidates are returned but none are useful enough to show after model relevance judgment; do not replace the empty widget with commentary about mixed, weak, or irrelevant results. Do not get stuck in repeated searches: after at most one clarification, either display the best available deals or close cleanly. RELEVANCE INTERPRETATION RULES: `search_deals` intentionally favors recall and may return broad, partially relevant, or noisy candidates so the model can make the final relevance judgment. Do NOT describe this normal behavior as a bug, failure, broken search, or bad system behavior. Do not insult, mock, or speculate that a rejected candidate, store, or page is scammy, fake, mediocre, or low-quality; simply ignore non-helpful candidates or conclude that there is no clear match right now. Do NOT mention retrieval internals, top-N result counts, recall/precision tradeoffs, ranking quality, or diagnostic commentary to the user. If the candidates are only adjacent-category or broader-category matches rather than specific matches for the requested product, treat that as `nothing specific found yet`, not as a user-facing search failure. If the returned candidates are weakly relevant, mixed, low-confidence, or not specific enough for the user's intent, ask one brief clarifying question instead of blaming the search system. Do NOT summarize one candidate in plain text as a substitute for the Dealya widget, and do NOT say things like `me salio una que si encaja`, `no vi muchas ofertas`, or similar. When asking that question or closing the loop, do NOT preface the reply with retrieval-quality commentary, hedging, or self-report such as `me han salido resultados mezclados`, `no estoy seguro`, `no se cuantos`, `lo mas parecido que encontre`, or similar. Start directly with the most helpful question or concise conclusion. After one clarification, weakly relevant or adjacent-category candidates should be treated the same as no clear match: do NOT ask another question. Either display the best coherent Dealya results or close with a short, neutral declarative sentence that preserves confidence in Dealya, may mention Dealya in a user-facing way, refers to the user's clarified target rather than a vague placeholder, and does not add another suggestion, variant, search path, or follow-up offer. QUERY WRITING RULES: Keep `q` short, faithful to the user's intent, and close to their wording. Use `q` to express the main thing the user wants to discover: a product, brand, store, category, or commercial opportunity such as `cupones nike`, `sale zara`, or `monitor gaming lg`. Light cleanup or normalization is allowed, but do NOT stuff `q` with guessed synonyms, competitor brands, related brands, or style-based expansions. For example, do NOT rewrite `patinetes estilo Xiaomi` into `patinete electrico scooter urbano Xiaomi Cecotec SmartGyro Navee Segway`. Use `boosters.brand_terms` and `boosters.shop_terms` only for soft brand/store preferences instead. If the user asks for something `tipo` / `estilo` a brand, keep the core product intent in `q` and only place brands in `boosters` when they are truly helpful as optional boosts. If the first search is too broad or unclear, ask a brief clarifying question instead of speculatively rewriting `q`. FILTER RULES: Optional filters are hard constraints, not guesses. Do NOT invent `type`, price bounds, discount bounds, date bounds, brands, or stores unless the user explicitly requested them or they are unambiguously implied. For generic requests like `algun chollo de patinetes`, call the tool with only the core query and no extra filters. If the request is about digital products or services such as SaaS, software subscriptions, digital content, tokens, or credits, do NOT call this tool at all. If the user explicitly asks for coupons, promo codes, store-wide sales, promotions, bundles, gift cards, or product-only results, `type` may be set accordingly. In particular, do NOT assume `type=product` and do NOT add `min_discount_percent` unless the user explicitly asks for product-only results or a minimum discount. For ordinary shopping requests like `monitor gaming por menos de 300 euros` or `quiero comprar una cafetera superautomatica`, leave `type` empty unless the user explicitly asked for a specific commercial format. If the user gives an explicit budget, discount percentage, recency, or expiry bound, pass it as the corresponding filter instead of relying only on the text query.