Report mode, live and experimental access, whether env location is configured, local limits, request policy and endpoint counts. market://endpoints lists the routes. No network access.

Get hierarchical categories. query, parentId and flat are local filters. Use returned Turkish names for category searches.

List market chains via /api/v1/categories. Experimental. Optional, never a prerequisite for search or comparison. If it returns HTTP 500, do not retry; report the chains' active status as unknown and continue with other tools. Not the product category tree.

Find nearby physical branches using call coordinates/radius or configured env location. All three values must be supplied by one of these sources. Experimental. Response distance is meters from the API; its measurement method is undocumented and it is not a walking or driving route. The returned list is not proven exhaustive; one live session (2026-10-07) returned at most 5 branches per chain, which is not guaranteed. Choose returned depot IDs for product queries.

Search products and facets, one zero-based page. Combine keywords with known API filters such as refined_volume_weight and order in one request. Location/radius come from the call or configured env; nonempty depots are required per call. Follow market://guide to preserve alternatives and exact requirements; fuzzy search still needs result validation.

Search using menu_category, main_category or sub_category Turkish names from the category tree. At least one nonempty category filter and call or configured location and explicit depots required.

Get one product by its opaque product id. Returns location-specific branch offers, promotional fields and indexTime. Barcode lookup is not supported.

Find related products using exact product id and its title as keywords. Similarity is not equivalence: inspect title and package size.

Find substitutes at one market chain. Experimental. marketName must match each supplied depot ID prefix; provide original id and product title as keywords.

Get market price series for one product: uniqueId is the product id from search or product results. Prefer the depot IDs returned for that product. Optional from/to (YYYY-MM-DD) filter locally; returns chronological series and change statistics.

Fetch up to 100 product identities in one call for an explicitly requested refresh. Experimental. Never switch to this tool to bypass a basket budget or run large live tests. identities are product ids. No purchase or persistent basket mutation.

Find address suggestions. Experimental map API. Returns display_name and explicit latitude/longitude parsed from API tuple positions.

Resolve coordinates into address fields and display_name, the nearest address estimate for that point, not a verified address. Experimental map API. Uses capitalized Lat and Lon query parameters.

Fetch one product and compare returned branch prices. Use when a detail lookup or refresh is needed; existing search offers can already answer price questions. Reports cheapest branches, price spread and promotional fields. Zero prices are unavailable. Follow market://guide for the discount flag and percentage field.

Compare exact product IDs and pack quantities with one product lookup per item. This description is the single source for basket rules. Budget: read market_status limits.basketItems and limits.basketRequestBudget first; the budget counts every possible HTTP retry and over-budget calls are rejected before any lookup. Never split the list into several calls or switch to sync or other tools to bypass it. Ask the user to narrow the comparison, or explain search offers already returned with their original retrieval time; never present a shortened basket as complete. For a brand-agnostic list, exact IDs fix one product per item: say which products the basket covers, and label any sum of search offers as an estimate with each offer depot and retrievedAt, not a basket total. Reuse sufficient search offers instead of redundant lookups. Results: quantities are packs of the selected product; alternatives are never substituted; a missing item makes total null, never zero. groupBy=market may span branches; groupBy=depot means one physical shop. Check selected offer depot IDs and requiresMultipleDepots before claiming one physical shop; a chain name alone is insufficient. A complete basket covers the selected IDs, not proof that they meet every user requirement; equal prices do not prove equivalent products. Presentation: present complete groups first, using total rather than an incomplete subtotal, and lead with the cheapest complete group the answer contains; splitBasket stays separate. Show all groups tied at the lowest total, naming each market or depot; the first sorted group is not the sole winner. For long lists, summarize branches by chain and disclose the shortened display and omitted group count. Explain any preference among tied options with evidence or stated user preferences; depot-ID ordering does not mean nearest or best, and branch distance is not a walking route or the total shopping journey. splitBasket: a theoretical multi-shop minimum without travel, delivery or stock guarantee; it shows one combination, never a unique or exhaustive one; never invent alternatives absent from returned data. Present a complete splitBasket separately, as a saving only when strictly cheaper than the cheapest complete single-depot group, and state the TRY saving and that baseline. If only multi-depot groups are complete, use the cheapest one as an explicitly multi-depot baseline. Never promote an equal total as a saving. If no group is complete, explain the missing products and present a complete splitBasket as the only complete option without claiming a saving; if it is incomplete too, report only its subtotal and missing items. No purchases.