PttAVM

List available filters (facets) for a query so a search can be refined. Call this BEFORE passing any ``brands``/``merchants``/``category`` value: the returned ``value`` slugs are the only ones search-api matches, and a guessed value yields an empty result set with no error. Facets are for honouring a filter the USER asked for — not a prompt to add filters of your own. ``user_query``: the user's verbatim request, for analytics only (see ``search_products``). Returns Markdown listing categories (hierarchical), brands, merchants, price ranges, boolean toggles and product/variant specs, with how to pass each back into ``search_products``. On failure: "Error: <msg>".

get_search_filters

Display PTT AVM products to the USER as an interactive card grid (visible UI). This is the FINAL, USER-FACING display. **Call it AT MOST ONCE per reply, and only with the results you actually want the user to see** (the final query + filters). Every call paints a NEW grid on screen — calling it twice (e.g. a broad search then a filtered one) leaves BOTH on screen and confuses the user. Do your exploring/analysis FIRST, without rendering: - ``find_products`` — fetch product data as text (no UI) to inspect/compare. - ``get_search_filters`` — list valid brands/categories/specs for a query. Then call ``search_products`` ONCE. **Pass ONLY the filters the user actually stated. Do not invent them.** If the user just names what they want ("iphone 16 telefon arıyorum"), send ``query`` (plus ``user_query``) and NOTHING else — leave ``sort``, ``size``, ``brands``, ``min_price``/``max_price``, ``category`` and the toggles at their defaults. Relevance ranking already puts the best matches first; an unrequested filter silently hides most of the catalog (a guessed brand + price floor can cut 26.000 results to 59) and an unrequested ``sort=price_asc`` puts refurbished/low-end items in front of what the user asked for. Only filter when the user said so ("sadece Apple", "5000 TL altı", "en ucuzdan sırala") or when they ask you to narrow a result set they have already seen. ``brands``/``merchants``/``category`` values MUST come from ``get_search_filters`` (the facet ``value`` slug, e.g. ``apple``, ``elektronik-c-1``) — never the display label and never a guess. A value that matches no facet returns an EMPTY grid with no error. Brand/merchant labels are slug-folded for you; ``category`` is not, so copy it verbatim from the facets. Filtering is server-side — never filter/sort the returned items yourself (they are one page of ``total``). Sort: relevance (default) | price_asc | price_desc | newest | best_seller. ``user_query``: pass the USER's original request **verbatim** (their exact words, e.g. "ssd aramak istiyorum 2 tb olsun"), separate from the cleaned ``query`` search term. Used for analytics only — it does not affect the search. Returns JSON ({type:"products", total, query, page, items:[...]}) rendered as cards (with built-in Önceki/Sonraki pagination). On failure: {type:"error", message}.

search_products

Fetch product data as TEXT for YOUR analysis — does NOT render anything to the user. Use this for every intermediate/exploratory step: counting matches, comparing options, or checking which categories/brands appear. It takes the same parameters as ``search_products`` (including ``user_query`` — the user's verbatim request, for analytics only), and the same rule applies: **pass only the filters the user actually stated**, and take ``brands``/``merchants``/``category`` values from ``get_search_filters`` rather than guessing (a non-matching value returns 0 results with no error). When done, call ``search_products`` ONCE to show the user. Returns JSON {total, count, query, items:[{productId, name, brand, category, price, rating, reviewCount, url}]}. On failure: {type:"error", message}.

find_products