You can query and compare Turkish supermarket product prices and branches through an MCP server.
Search products by keyword, category, brand, price order, and filters.
Get product details and compare branch offers, cheapest branches, and price spreads.
Compare shopping baskets by market chain or physical depot, with totals, missing items, and split-basket estimates.
Retrieve product price history and change statistics.
Find nearby physical branches using coordinates and radius (experimental).
Geocode and reverse-geocode addresses (experimental).
Find similar products and substitutes at a market chain.
Refresh up to 100 product identities in one explicit sync call (experimental).
Check server mode, limits, location configuration, and list market chains.
Browse hierarchical product categories.
Purchase, ordering, and barcode lookup are not supported.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@market-fiyati-mcp En yakın marketlerde 1 kg makarna fiyatlarını karşılaştır."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Resmî değildir. Bu proje Market Fiyatı, TÜBİTAK veya market zincirleriyle bağlantılı değildir ve onlar tarafından onaylanmamıştır. Kullanım koşulları operatörün sorumluluğundadır: Amaç ve kullanım izinleri.
Başlayın: Aşağıdaki yapılandırmayı MCP istemcinize ekleyin.
Türkiye'de ürün, şube fiyatı ve sepet karşılaştırması için MCP sunucusu.
Node.js 22+ gerekir. Normal kullanım gerçek fiyat sorguları için live modudur;
offline geliştirme ve test içindir. Aşağıdaki örnek, önceki sürümlerde de çalışması için modu açıkça seçer.
Şube keşfi: Ürün aramaları şube ID'si ister; yakındaki şubeleri bulan tool deneysel erişim gerektirir.
Bu ayar yakın şube, market listesi, adres/koordinat arama, toplu ürün güncelleme ve alternatif ürün tool'larını açar.
Bu yüzden örnek "MARKET_FIYATI_ENABLE_EXPERIMENTAL": "true" içerir. Ayarın varsayılanı false olarak kalır;
şube ID'lerinizi zaten biliyorsanız bu satırı silebilirsiniz.
{
"mcpServers": {
"market-fiyati": {
"command": "npx",
"args": ["-y", "market-fiyati-mcp@2.0.2"],
"env": {
"MARKET_FIYATI_MODE": "live",
"MARKET_FIYATI_LATITUDE": "41.025591",
"MARKET_FIYATI_LONGITUDE": "28.974075",
"MARKET_FIYATI_DISTANCE": "4",
"MARKET_FIYATI_ENABLE_EXPERIMENTAL": "true"
}
}
}
}Örnek: Galata Kulesi — 41.025591, 28.974075.
distance=4, merkezden 4 km yarıçap demektir (8 km çap).
Sayı tipi: Tool girdisindeki koordinat ve yarıçap tırnaksız JSON sayısıdır.
Yalnız env değerleri ortam değişkeni olduğu için tırnaklıdır; sunucu bunları sayıya çevirir.
market_find_nearby_depots için aynı örnek, tırnaksız sayılarla:
{ "latitude": 41.025591, "longitude": 28.974075, "distance": 4 }Yukarıdaki market-fiyati girdisini istemcinizin dosyasına ekleyin ve istemciyi yeniden başlatın.
İstemci | Dosya | Not |
Claude Desktop | macOS: |
|
Claude Code | Proje: |
|
Cursor | Genel: |
|
VS Code | Proje: | Üst anahtar |
Codex |
| TOML: |
Kendi konumunuz için koordinatları değiştirin. Kişisel konumunuzu özel istemci ayarında tutun; Git'e eklemeyin.
Env konumu 1.0.6'dan beri desteklenir (yarıçap geçişi). Paket kurulamıyorsa kaynak koddan çalıştırın.
npx paketi indirir; bulunamazsa mutlak yolunu kullanın. Hazır Galata yapılandırması.
Related MCP server: Electronic Markets TR
Sunucuyu yeniden başlatıp AI'ya şunu yazın:
market_statusçağır. Modu ve konum ayarının hazır olup olmadığını göster.
Beklenen: data.mode=live, data.liveRequestsEnabled=true, data.locationDefaults.configured=true.
Status yalnız ayarları kontrol eder; gerçek fiyat için sonraki adımdaki aramayı yapın.
AI'ya istediğiniz ürünü ve marketleri söyleyin. Konum ayarı hazırsa tekrar vermeniz gerekmez.
Şubeler bilinmiyorsa yukarıda açtığınız deneysel erişimle market_find_nearby_depots bir kez çağrılır;
ürün aramasında dönen şube ID'leri kullanılır. Adımlar: Gerçek fiyatlarla sorgulama.
Yakınımdaki şubelerde 1 litre yarım yağlı sütün en ucuz fiyatı ne?
3 kg yoğurdu fiyata göre sırala; tam eşleşmeleri ve alternatifleri ayrı göster.
500 g beyaz peynirin fiyatını şubeler arasında karşılaştır ve harita linklerini ver.
1 kg patates, 2 L süt ve 10'lu yumurtadan oluşan sepeti şube bazında karşılaştır.
1 kg toz şekerin fiyat geçmişini özetle.
Ürün adlarını ve paket boyutlarını açık yazın. "Sadece tam eşleşme" gibi kesin şartları belirtin; aksi hâlde AI benzer ürünleri ayrı başlıkta açıklayarak önerebilir.
Durum | Kural |
Env kullanıyorum | Üç değeri birlikte ayarlayın; AI her sorguda tekrar sormaz. |
Env kullanmıyorum | Üçünü de kaldırın; enlem, boylam ve yarıçapı her konumlu çağrıda sağlayın. |
Başka konum arıyorum | Enlem/boylamı birlikte verin. Distance yoksa env yarıçapı kullanılır. |
Eksik veya geçersiz değer | Env hatalıysa sunucu başlamaz; çağrı hatalıysa o çağrı reddedilir. Varsayılan yarıçap yoktur. |
Ayarı değiştirdim | Env için yeniden başlatın. Çağrıdaki değişiklik yalnız o çağrıya aittir. |
Şubeler (depots) ürün çağrısında ayrıca gerekir; MCP bunları saklamaz.
Aynı süreç env konumunu paylaşır; farklı kullanıcılar ayrı süreç veya açık çağrı değerleri kullanmalıdır.
Tüm konum kuralları ve sınırlar.
Amaç | Tool |
Ürün ara |
|
Şube fiyatlarını karşılaştır |
|
Sepet karşılaştır |
|
Fiyat geçmişini incele |
|
Çağrı akışını öğren |
|
15 tool · 3 resource · 3 prompt. Satın alma, sipariş ve barkod sorgusu desteklenmez.
Fiyatlar TRY. percentage indirim oranı değildir; API'nin discount işaretine bakın.
Eksik offer bilinmiyor demektir; “stok yok” veya “tüm fiyatlar tarandı” denemez.
Eksik sepette total=null; subtotal yalnız bulunan ürünlerdir.
Fiziksel şube karşılaştırması için groupBy=depot kullanın; zincir tek bir şube değildir.
Sepet en fazla 5 ürün alır; bütçe retry dâhil 5 HTTP denemesidir. Retry açıksa ürün sınırı düşer
(market_status içindeki limits.basketItems). Listeyi bölerek veya tool değiştirerek aşmayın.
Hata veya belirti | Neden ve çözüm |
| İstemci ayarında |
| Yakın şube, adres arama gibi deneysel tool'lar kapalıdır. Ayara |
| Yanıt yerel boyut sınırını aştı; kısmi veri dönmez. Aynı sorguyu tekrarlamayın: sayfa boyutunu ( |
| İstemci, |
Claude Code büyük sonucu dosyaya taşıyor | Yanıt boyutu ürün ve şube sayısıyla büyür. 2026-10-07 tarihli live oturumda 25 ürün × 25 şubelik aramalar istemcinin çıktı sınırını aştı, 15 ürün × 25 şube altında kaldı. Daha az şube veya daha küçük |
Sunucu listede görünmüyor (Windows) | Claude Desktop MSIX paketiyle kurulduysa (Microsoft Store, WinGet veya resmî kurucu) uygulamanın dosyayı |
Diğer hata kodları: API.
Depoyu klonlayıp çalıştırın:
npm ci --ignore-scripts
MARKET_FIYATI_MODE=offline npm run checkcheck derlemeyi de yapar. İstemcide command: "node", args içinde dist/src/index.js dosyasının
mutlak yolunu kullanın. Geliştirirken istemci env ayarını açıkça MARKET_FIYATI_MODE=offline yapın;
testlerin ağ engeli de korunur. Gerekirse node yolunu da mutlak yazın.
Sunucu stdio JSON-RPC kullanır; HTTP portu açmaz. Geliştirmede MARKET_FIYATI_MODE=offline npm start
MCP mesajlarını bekler. Mod ayarı olmadan başlangıç live seçer; yalnız başlatmak HTTP isteği göndermez.
stdout yalnız MCP trafiğidir. npm kurulumu ağ kullanabilir; uygulama testleri API'ye bağlanmaz.
İhtiyaç | Belge |
Gerçek fiyatları sorgula | |
Tool, filtre ve yanıt kuralları | |
Ayarlar ve kod yapısı | |
Testler ve sınırları | |
Sürüm çıkarma |
Bu proje, ticari kazanç veya başka bir çıkar gözetilmeden geliştirilmiş bağımsız bir çalışmadır. Market Fiyatı'nın, TÜBİTAK'ın veya market zincirlerinin resmî ürünü değildir. Herhangi bir onay, sponsorluk veya ortaklık iddiası yoktur.
Market Fiyatı kullanım koşullarını değerlendirmek ve
kullanımına uygun izinleri sağlamak operatörün sorumluluğundadır. Bu depo üçüncü taraf servislerine
erişim izni vermez; live ayarı yalnız teknik erişimi belirler.
Güvenlik açığı bildirmek için özel bildirim yönergesini kullanın.
MIT — Copyright (c) 2026 Gökhan Çavuş.
Lisans yalnızca yazılımı ve beraberindeki belgeleri kapsar. Üçüncü tarafların verilerine, markalarına, logolarına veya servislerine erişim hakkı vermez. Yukarıdaki amaç beyanı MIT lisansını değiştirmez ve koda ticari kullanım yasağı eklemez. Üçüncü taraf bileşenler kendi lisanslarına tabidir.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| groupBy | No | market | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already marking this as a read-only, open-world, idempotent, non-destructive operation, the description adds substantial behavioral detail: budget rejection behavior, retry counting, null totals for missing items, no substitution of alternatives, groupBy semantics, and splitBasket caveats. This goes well beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with labels like Budget, Results, Presentation, and splitBasket, and it is front-loaded with the core action. However, it is extremely long and dense for a tool definition, and many sentences could likely be compressed without losing essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the presence of an output schema, and annotations covering safety, the description is highly complete. It covers budget limits, group formation, presentation rules, splitBasket handling, and edge cases like missing items and tied groups, leaving little an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is moderate at 67%, and the description compensates by explaining that items are exact product IDs with pack quantities, that quantities are packs of the selected product, and what groupBy=market versus groupBy=depot means. It does not add further meaning for latitude, longitude, or distance beyond the schema, but the added semantics are valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: compare exact product IDs and pack quantities with one product lookup per item. It distinguishes this from a simple offer search by describing basket behavior, but it does not explicitly name or route against the sibling tool market_compare_product_offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong operational guidance: check market_status limits first, never split the basket into several calls, never switch to sync or other tools, reuse sufficient search offers, and ask the user to narrow comparisons. It stops short of explicitly naming sibling alternatives for comparison tasks, so routing is clear but not maximally explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| identity | Yes | ||
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description only needs to add behavioral context. It does: 'Zero prices are unavailable' disambiguates missing data, and it points to market://guide for the discount flag and percentage field semantics. It doesn't cover rate limits or whether results are cached, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short, front-loaded sentences with the core action stated first and constraints following. The telegraphic style ('Zero prices are unavailable') is efficient, though the doc-pointer sentence is slightly cryptic without context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be spelled out, and the description still helpfully previews the result shape. However, for a 5-required-parameter tool, the biggest ambiguity is left open: which parameter selects the product being compared, and why geospatial inputs are mandatory. The description is adequate but leaves an agent with a real invocation question.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema carries most parameter documentation and 3 is the baseline. The description adds nothing about the parameters themselves: it never explains how the target product is identified (the undocumented 'identity' field) or why latitude/longitude/distance/depots are required for a single-product price comparison. 'Returned branch prices' only loosely maps to the depots array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: fetch one product and compare branch prices, and reports the derived outputs (cheapest branches, spread, promo fields). It distinguishes itself from search-style siblings implicitly by noting that 'existing search offers can already answer price questions', though it never names the sibling tool. Clear but not fully differentiated by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('when a detail lookup or refresh is needed') and an exclusion ('existing search offers can already answer price questions'), which steers the agent away from redundant calls. It does not name the alternative tool (e.g. market_search_products or market_get_product) or state prerequisites, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find substitutes at one market chain. Experimental. marketName must match each supplied depot ID prefix; provide original id and product title as keywords.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| size | No | Page size, local maximum 100. | |
| pages | No | Zero-based API page. | |
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| keywords | Yes | ||
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. | |
| marketName | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds that the tool is experimental and that depots are required and never auto-expanded, which provides useful behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, two sentences, and front-loads the core purpose and key constraints. Every sentence adds critical information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and an output schema, the description covers the unique constraints and usage context. It doesn't explain return values but that's covered by the output schema, and it does mention the experimental nature which is important. Minor gaps remain around pagination that are not fully specified, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description explains the relationship between marketName and depot prefixes, and the keyword usage. However, it doesn't explain all parameters (e.g., size, pages) beyond what schema provides, so it adds some value but not complete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool finds substitutes at one market chain, and explicitly mentions it is experimental. The verb 'Find' and resource 'substitutes' are specific, and the description differentiates it from similar tools like market_find_similar_products by emphasizing the market chain and depot prefix constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides key usage guidance: marketName must match depot ID prefix, and keywords should include original id and product title. However, it doesn't explicitly state when not to use this tool or mention alternatives like market_find_similar_products, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety profile is covered; the description goes well beyond by flagging the tool as Experimental, warning that returned distance is in meters while the input radius is in km, that the measurement method is undocumented and is not a route distance, and that the result list is not proven exhaustive (observed cap of ~5 branches per chain). This is exactly the kind of caveat an agent needs before trusting output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and input-source rule are front-loaded, followed by caveats and the downstream usage tip. Sentences are dense and largely load-bearing, though the fragment 'Experimental.' and the hedging around the 5-branch observation cost a little tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description is not obliged to explain return values, and instead spends its words on the things structured data cannot carry: experimental status, unit mismatch, measurement-method uncertainty, and non-exhaustiveness. Nothing an agent needs to call this correctly or interpret the response is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description adds a genuine cross-parameter constraint the schema cannot express: latitude, longitude and distance must all be supplied by the same source. It also implicitly surfaces the km-input vs. meter-output unit mismatch. It does not restate the 50 km safety cap or coordinate bounds, which the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find nearby physical branches') and pins down the two input sources (call coordinates/radius vs. configured env location). It also names the downstream action ('Choose returned depot IDs for product queries'). It never names the nearest siblings (market_reverse_geocode, market_geocode_address), so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a real precondition: all three values must come from one source, not mixed. It also tells the agent what to do with the result (use depot IDs for product queries). It stops short of naming alternative tools for location resolution or stating when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find related products using exact product id and its title as keywords. Similarity is not equivalence: inspect title and package size.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| size | No | Page size, local maximum 100. | |
| pages | No | Zero-based API page. | |
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| keywords | Yes | ||
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond those hints: results may be merely similar rather than equivalent, and the user must verify title and package size. This is a meaningful caveat not captured by the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core mechanism is stated first, and the important caution about similarity is placed immediately after. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich output schema, detailed parameter descriptions for most fields, and strong annotations, the description covers the essential operational nuance. It lacks explicit sibling differentiation and does not explain why location and depot parameters are required, but those are largely documented in the schema. Overall adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the id and keywords parameters lack their own schema descriptions. The description clarifies their joint role—id is the exact product id and keywords should be its title—which adds meaning beyond the raw schema and helps an agent construct valid parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Find related products') with the exact input mechanism ('using exact product id and its title as keywords'). It clearly identifies the resource domain, though it does not explicitly distinguish itself from the sibling market_find_alternatives beyond the word 'similar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful context by warning that similarity is not equivalence and telling the user to inspect title and package size. However, it gives no explicit guidance on when to choose this tool over siblings like market_find_alternatives or market_search_products, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find address suggestions. Experimental map API. Returns display_name and explicit latitude/longitude parsed from API tuple positions.
| Name | Required | Description | Default |
|---|---|---|---|
| words | Yes | Address/place text; encoded as a query parameter. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the operation as read-only, open-world, and idempotent. The description adds meaningful behavioral context by flagging the API as experimental and by revealing that latitude/longitude are parsed from API tuple positions rather than provided as first-class fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying distinct information: purpose, experimental status, and return behavior. There is no redundant or filler content, and the most important detail is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, rich annotations, and a straightforward purpose, the description is largely sufficient. It could be more complete by noting a typical use case or explicitly contrasting with reverse geocoding, but nothing critical is missing for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter, and the description does not need to add much. It reinforces that the input is free-form address/place text, but it does not provide additional semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-plus-resource construction ('Find address suggestions') and identifies the tool as an experimental map API. It clearly conveys forward geocoding, though it does not explicitly name market_reverse_geocode as the opposite sibling to sharpen differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool compared with siblings like market_reverse_geocode. The phrase 'address suggestions' implies a forward-geocoding/autocomplete use case, but the description leaves the selection logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hierarchical categories. query, parentId and flat are local filters. Use returned Turkish names for category searches.
| Name | Required | Description | Default |
|---|---|---|---|
| flat | No | ||
| query | No | ||
| parentId | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by noting that query, parentId, and flat are local filters and that returned names are Turkish, but it does not disclose pagination, ordering, or hierarchy traversal behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded, and the additional sentence about local filters and Turkish names earns its place by conveying practical usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations and the presence of an output schema reduce the burden on the description. However, with zero parameter documentation in the schema, the description leaves significant gaps about how to use query, parentId, and flat effectively. It is adequate but not fully complete for a tool with three optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only states that query, parentId, and flat are local filters, without explaining what each parameter does, how they interact, or what values are expected. This is insufficient for an agent to use the parameters confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hierarchical categories, which is a specific verb and resource. It also hints at its role in category searches via Turkish names, helping distinguish it from search_by_category, though it does not explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to obtain category names for subsequent category searches, but it does not explicitly state when to prefer this over alternatives like market_search_by_category or market_search_products. There is no when-not guidance or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| latitude | Yes | Explicit user-selected latitude. | |
| uniqueId | Yes | Product id from search or product results. | |
| longitude | Yes | Explicit longitude. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real behavioral context: the from/to window is applied 'locally' (not as a server-side query), and the return is a chronological series plus change statistics. That is meaningful beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no padding, and the core purpose plus key parameter sourcing are front-loaded. Minor density cost from folding ID sourcing and return shape into the same sentence, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values, yet it briefly does. It covers the non-obvious inputs (ID provenance, optional date range, local filtering); only the geo/radius parameters are left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, and the descriptions for uniqueId and the date fields largely restate what the schema already says (the uniqueId description in the schema is nearly identical). The depot-preference hint adds some value, but latitude/longitude/distance receive no mention in the description, so it neither compensates for nor exceeds the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Get market price series for one product'), which clearly separates it from siblings like market_get_product or market_compare_product_offers. It does not name an alternative tool explicitly, so it lands just short of the top mark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains where inputs come from ('uniqueId is the product id from search or product results', 'Prefer the depot IDs returned for that product') and that from/to are optional, which implies the calling sequence. However, it never states when to choose this tool over market_compare_product_offers or market_get_product, leaving the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one product by its opaque product id. Returns location-specific branch offers, promotional fields and indexTime. Barcode lookup is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| identity | Yes | ||
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds a useful constraint (no barcode lookup) but its return-content sentence ('branch offers, promotional fields and indexTime') largely duplicates what the existing output schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and zero padding. The only mild waste is the return-content clause, which repeats output-schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description only needs to disambiguate inputs and scope. It does that partly, but the mismatch between the 'opaque product id' it says to supply and the required 'identity' parameter leaves a real gap for an agent trying to construct a call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents latitude, longitude, distance and depots. The description adds no syntax or meaning for any parameter and, worse, refers to an 'opaque product id' that does not map cleanly to the required 'identity' field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one product by its opaque product id') and adds a scope exclusion ('Barcode lookup is not supported'), which separates it from search-style siblings. However, the identifier it names ('product id') does not correspond to any schema parameter, whose required identity field is called 'identity', so the resource it fetches is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'get one product by its opaque product id' and one exclusion is given (barcode lookup not supported), but no alternative sibling is named and no condition for choosing this over market_search_products or market_compare_product_offers is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds value beyond structured fields by flagging the tool as Experimental and prescribing exact failure handling (on HTTP 500 do not retry, mark status unknown, continue) — real behavioral guidance not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded verb+resource in the first clause, followed by terse, high-value sentences (experimental status, optionality, failure handling, disambiguation). Every sentence earns its place, though the trailing disambiguation clause reads slightly tacked-on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values are covered, and the tool takes no parameters. The description supplies the remaining essentials an agent needs — optionality, experimental risk, and 500-error policy — leaving no critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so per the baseline this scores 4. The description correctly adds no parameter detail because none exist; there is nothing further it could meaningfully document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (market chains) and even names the backing endpoint. It explicitly disambiguates from the similarly-named sibling market_get_categories with 'Not the product category tree', so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear negative guidance ('Optional, never a prerequisite for search or comparison') so the agent knows it need not block on this call, and directs fallback behavior on failure. It stops short of naming an explicit alternative tool to call instead, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it is an 'Experimental map API' and the result is 'the nearest address estimate for that point, not a verified address' — an important accuracy caveat that no annotation conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose and then the accuracy caveat. Every sentence carries information; the phrasing is slightly compressed but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies the accuracy caveat and experimental status; the only real gap is the absence of when-to-use guidance versus the forward-geocoding sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (latitude/longitude both documented with ranges), so the baseline is 3. The description's note about 'capitalized Lat and Lon query parameters' adds transport-level detail, but it conflicts with the lowercase schema property names, making it as likely to confuse as to help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Resolve coordinates into address fields and display_name'), which is unambiguous and clearly the inverse of the sibling market_geocode_address. It does not name that sibling explicitly, so the differentiation is implied by direction rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is for coordinate→address lookups, but there is no explicit 'use this when you have lat/lon; use market_geocode_address when you have a street address.' No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Page size, local maximum 100. | |
| brand | No | ||
| order | No | ||
| pages | No | Zero-based API page. | |
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. | |
| offer_price | No | ||
| market_names | No | ||
| sub_category | No | ||
| main_category | No | ||
| menu_category | No | ||
| offer_discount | No | API discount filter ["true"]; matching does not override each offer's discount flag or confirm campaign eligibility. Preserve false or absent flags and separate reference-price fields. Omit to include all products. | |
| refined_quantity_unit | No | ||
| refined_volume_weight | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful constraint context (category filter required, depots must be explicit), but does not disclose behavior such as error handling, pagination, or how category names are resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the search action and category scope. The phrase 'call or configured location' is awkward and slightly unclear, but overall the text is efficient and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 16 parameters, nested objects, and an output schema. The description only covers the category filter and required location/depots. It does not mention how to obtain category names (e.g., via market_get_categories), explain optional filters, or clarify the ambiguous 'call or configured location' phrase. The output schema reduces the need to describe return values, but the input-side context is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44%, so the description must compensate for many undocumented parameters. It explains the category filter requirement and mentions depots/location, but it does not clarify brand, order, offer_price, market_names, refined_quantity_unit, refined_volume_weight, or other optional filters. This leaves a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and a clear resource: products filtered by menu_category, main_category, or sub_category Turkish names from the category tree. It does not explicitly say 'products', but the category-based scope and the sibling tool market_search_products make the intent clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear required conditions: at least one nonempty category filter, a location, and explicit depots. It does not name alternatives or state when not to use this tool, but the prerequisites are explicit enough for an agent to decide whether this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Page size, local maximum 100. | |
| brand | No | ||
| order | No | ||
| pages | No | Zero-based API page. | |
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| keywords | Yes | ||
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. | |
| offer_price | No | ||
| market_names | No | ||
| sub_category | No | ||
| main_category | No | ||
| menu_category | No | ||
| offer_discount | No | API discount filter ["true"]; matching does not override each offer's discount flag or confirm campaign eligibility. Preserve false or absent flags and separate reference-price fields. Omit to include all products. | |
| refined_quantity_unit | No | ||
| refined_volume_weight | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds useful behavioral details: it is a single-page search, requires nonempty depots, and warns that fuzzy search needs result validation. It also mentions following a guide for preserving alternatives. These go beyond annotations and provide practical constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact paragraph, not overly long, and front-loads the core purpose. It packs multiple pieces of guidance without redundancy, though it could be structured more clearly with bullet points for the distinct constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 17 parameters, nested objects, and many siblings, the description feels incomplete. It points to an external guide for exact requirements, which shifts burden. It doesn't explain facets, alternative handling, or how to combine filters beyond examples. The output schema helps, but given complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 41%, and the description only highlights two filters (refined_volume_weight, order) and location/depot requirements. Many parameters (brand, categories, offer_price, etc.) have no description in either schema or the tool description, leaving a significant gap. The description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Search products and facets' and specifies 'one zero-based page', which distinguishes it from paginated search variants. However, it doesn't explicitly differentiate from sibling tools like market_search_by_category or market_find_similar_products, so it's clear but not fully unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides some usage context: location/radius can come from env, depots are required, and it points to a guide for exact requirements. But it doesn't explicitly say when to use this tool over alternatives or when not to use it. The reference to 'market://guide' implies more info but doesn't give concrete alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered; 'No network access' merely restates the closed-world annotation. What the description does add beyond annotations is the set of categories reported (mode, live/experimental access, local limits, request policy), which gives the agent a sense of what this diagnostic surfaces. No auth requirements, failure modes, or call-cost caveats are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler, and the reporting scope is stated first. The opening clause piles several comma-separated items together without connective framing, which slightly reduces front-loading clarity, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers what the tool inspects. The only real gap is the absence of any when-to-call guidance, which is a minor omission for a self-describing, parameterless status endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. No parameter meaning is contradicted or omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Report') plus an explicit list of the state it returns (mode, live/experimental access, env location, local limits, request policy, endpoint counts), and the sibling set contains no other status/diagnostic tool, so it is clearly distinguishable. The phrasing is a dense field list rather than a crisply framed purpose statement, which keeps it out of the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus anything else, nor any precondition such as 'use before invoking market_* tools to verify configuration'. The pointer to market://endpoints is a related-resource note, not usage guidance. For a zero-arg diagnostic the usage is largely self-evident, but the description still supplies no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| depots | Yes | Selected branch IDs from nearest; required and never auto-expanded. | |
| distance | Yes | Required search radius in km. 50 is a local safety limit. | |
| latitude | Yes | Explicit user-selected latitude. | |
| longitude | Yes | Explicit longitude. | |
| identities | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | Yes | |
| error | No | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description adds useful context beyond them: experimental status, no purchase or persistent basket mutation, and anti-abuse guidance around basket budgets and live tests. A minor inconsistency is that it says 'up to 100' while the schema allows maxItems 500 for identities, which could mislead about the actual call limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main action, and every sentence carries a distinct warning or clarification. There is no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return details are not needed, and annotations cover the safety profile. However, for a 5-parameter geo/bulk tool, the description does not explain why location and depot parameters are required for a product-identity refresh, nor does it resolve the 'up to 100' versus schema maxItems 500 discrepancy. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so most parameters are already documented. The description adds meaning only for identities ('identities are product ids') and does not clarify how depots, latitude, longitude, or distance interact with the sync behavior. The 'up to 100' claim conflicts with the schema's maxItems 500 for identities, adding ambiguity rather than precision.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch) and resource (product identities), plus a bulk scope ('up to 100 product identities in one call') and a refresh trigger. It does not explicitly distinguish itself from sibling tools like market_search_products or market_get_product, and the 'sync' framing in the name is not fully explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use condition ('for an explicitly requested refresh') and explicit when-not-to-use warnings ('Never switch to this tool to bypass a basket budget or run large live tests'). It does not name an alternative tool for those prohibited cases, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.1market_compare_basket1 field changedOutput schema / properties / data / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "properties": {
- "currency": {
- "const": "TRY",
- "type": "string"
- },
- "excludedCosts": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "groupBy": {
- "enum": [
- "market",
- "depot"
- ],
- "type": "string"
- },
- "groups": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "complete": {
- "type": "boolean"
- },
- "id": {
- "type": "string"
- },
- "lines": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "lineTotal": {
- "minimum": 0,
- "type": "number"
- },
- "offer": {
- "additionalProperties": {},
- "properties": {
- "depotId": {
- "type": "string"
- },
- "depotName": {
- "type": "string"
- },
- "marketAdi": {
- "type": "string"
- },
- "price": {
- "minimum": 0,
- "type": "number"
- }
- },
- "required": [
- "depotId",
- "depotName",
- "marketAdi",
- "price"
- ],
- "type": "object"
- },
- "productId": {
- "type": "string"
- },
- "quantity": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "productId",
- "title",
- "quantity",
- "offer",
- "lineTotal"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "missingProductIds": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "requiresMultipleDepots": {
- "type": "boolean"
- },
- "subtotal": {
- "minimum": 0,
- "type": "number"
- },
- "total": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "complete",
- "total",
- "subtotal",
- "lines",
- "missingProductIds",
- "requiresMultipleDepots",
- "id"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "missingProductIds": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "outOfScopeOffers": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "offer": {
- "additionalProperties": {},
- "properties": {
- "depotId": {
- "type": "string"
- },
- "depotName": {
- "type": "string"
- },
- "marketAdi": {
- "type": "string"
- },
- "price": {
- "minimum": 0,
- "type": "number"
- }
- },
- "required": [
- "depotId",
- "depotName",
- "marketAdi",
- "price"
- ],
- "type": "object"
- },
- "productId": {
- "type": "string"
- }
- },
- "required": [
- "productId",
- "offer"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "scope": {
- "type": "string"
- },
- "splitBasket": {
- "additionalProperties": {},
- "properties": {
- "complete": {
- "type": "boolean"
- },
- "lines": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "lineTotal": {
- "minimum": 0,
- "type": "number"
- },
- "offer": {
- "additionalProperties": {},
- "properties": {
- "depotId": {
- "type": "string"
- },
- "depotName": {
- "type": "string"
- },
- "marketAdi": {
- "type": "string"
- },
- "price": {
- "minimum": 0,
- "type": "number"
- }
- },
- "required": [
- "depotId",
- "depotName",
- "marketAdi",
- "price"
- ],
- "type": "object"
- },
- "productId": {
- "type": "string"
- },
- "quantity": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "productId",
- "title",
- "quantity",
- "offer",
- "lineTotal"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "missingProductIds": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "requiresMultipleDepots": {
- "type": "boolean"
- },
- "subtotal": {
- "minimum": 0,
- "type": "number"
- },
- "total": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "complete",
- "total",
- "subtotal",
- "lines",
- "missingProductIds",
- "requiresMultipleDepots"
- ],
- "type": "object"
- },
- "unavailableOffers": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "offer": {
- "additionalProperties": {},
- "properties": {
- "depotId": {
- "type": "string"
- },
- "depotName": {
- "type": "string"
- },
- "marketAdi": {
- "type": "string"
- },
- "price": {
- "minimum": 0,
- "type": "number"
- }
- },
- "required": [
- "depotId",
- "depotName",
- "marketAdi",
- "price"
- ],
- "type": "object"
- },
- "productId": {
- "type": "string"
- }
- },
- "required": [
- "productId",
- "offer"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "warning": {
- "type": "string"
- }
- },
- "required": [
- "currency",
- "groupBy",
- "groups",
- "splitBasket",
- "missingProductIds",
- "outOfScopeOffers",
- "unavailableOffers",
- "scope",
- "excludedCosts",
- "warning"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "currency": {
+ "const": "TRY",
+ "type": "string"
+ },
+ "depotMaps": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "apple": {
+ "type": "string"
+ },
+ "google": {
+ "type": "string"
+ },
+ "yandex": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "google",
+ "apple",
+ "yandex"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "excludedCosts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "groupBy": {
+ "enum": [
+ "market",
+ "depot"
+ ],
+ "type": "string"
+ },
+ "groups": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "complete": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lines": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "lineTotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ },
+ "quantity": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "title",
+ "quantity",
+ "offer",
+ "lineTotal"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingProductIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresMultipleDepots": {
+ "type": "boolean"
+ },
+ "subtotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "total": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "complete",
+ "total",
+ "subtotal",
+ "lines",
+ "missingProductIds",
+ "requiresMultipleDepots",
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingProductIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "outOfScopeOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "offer"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "splitBasket": {
+ "additionalProperties": {},
+ "properties": {
+ "complete": {
+ "type": "boolean"
+ },
+ "lines": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "lineTotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ },
+ "quantity": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "title",
+ "quantity",
+ "offer",
+ "lineTotal"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingProductIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresMultipleDepots": {
+ "type": "boolean"
+ },
+ "subtotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "total": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "complete",
+ "total",
+ "subtotal",
+ "lines",
+ "missingProductIds",
+ "requiresMultipleDepots"
+ ],
+ "type": "object"
+ },
+ "unavailableOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "offer"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "warning": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "currency",
+ "groupBy",
+ "groups",
+ "splitBasket",
+ "missingProductIds",
+ "outOfScopeOffers",
+ "unavailableOffers",
+ "scope",
+ "excludedCosts",
+ "warning",
+ "depotMaps"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]market_compare_product_offers1 field changedOutput schema / properties / data / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "properties": {
- "cheapestDepotIds": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "cheapestPrice": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "currency": {
- "const": "TRY",
- "type": "string"
- },
- "highestPrice": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "offers": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "depotId": {
- "type": "string"
- },
- "depotName": {
- "type": "string"
- },
- "marketAdi": {
- "type": "string"
- },
- "price": {
- "minimum": 0,
- "type": "number"
- },
- "savingIfCheapest": {
- "minimum": 0,
- "type": "number"
- }
- },
- "required": [
- "depotId",
- "depotName",
- "marketAdi",
- "price",
- "savingIfCheapest"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "outOfScopeOffers": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "offer": {
- "additionalProperties": {},
- "properties": {
- "depotId": {
- "type": "string"
- },
- "depotName": {
- "type": "string"
- },
- "marketAdi": {
- "type": "string"
- },
- "price": {
- "minimum": 0,
- "type": "number"
- }
- },
- "required": [
- "depotId",
- "depotName",
- "marketAdi",
- "price"
- ],
- "type": "object"
- },
- "productId": {
- "type": "string"
- }
- },
- "required": [
- "productId",
- "offer"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "priceSpread": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "productId": {
- "type": "string"
- },
- "scope": {
- "type": "string"
- },
- "title": {
- "type": "string"
- },
- "unavailableOffers": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "depotId": {
- "type": "string"
- },
- "depotName": {
- "type": "string"
- },
- "marketAdi": {
- "type": "string"
- },
- "price": {
- "minimum": 0,
- "type": "number"
- }
- },
- "required": [
- "depotId",
- "depotName",
- "marketAdi",
- "price"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "productId",
- "title",
- "currency",
- "cheapestPrice",
- "highestPrice",
- "priceSpread",
- "cheapestDepotIds",
- "offers",
- "unavailableOffers",
- "outOfScopeOffers",
- "scope"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "cheapestDepotIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "cheapestPrice": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "currency": {
+ "const": "TRY",
+ "type": "string"
+ },
+ "depotMaps": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "apple": {
+ "type": "string"
+ },
+ "google": {
+ "type": "string"
+ },
+ "yandex": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "google",
+ "apple",
+ "yandex"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "highestPrice": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "offers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "savingIfCheapest": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price",
+ "savingIfCheapest"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "outOfScopeOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "offer"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "priceSpread": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "productId": {
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "unavailableOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "productId",
+ "title",
+ "currency",
+ "cheapestPrice",
+ "highestPrice",
+ "priceSpread",
+ "cheapestDepotIds",
+ "offers",
+ "unavailableOffers",
+ "outOfScopeOffers",
+ "scope",
+ "depotMaps"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]market_get_price_history2 fields changedInput schema / properties / uniqueId / descriptionAdded value: +"Product id from search or product results."Output schema / properties / data / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "properties": {
- "dateFilterAppliedLocally": {
- "type": "boolean"
- },
- "series": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "name": {
- "type": "string"
- },
- "series": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "name": {
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "name",
- "value"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "name",
- "series"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "summary": {
- "items": {
- "additionalProperties": {},
- "properties": {
- "availablePoints": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- "change": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "changePercent": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "first": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "from": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "latest": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "market": {
- "type": "string"
- },
- "max": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "min": {
- "anyOf": [
- {
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "missingPoints": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- "points": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- "to": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "market",
- "points",
- "availablePoints",
- "missingPoints",
- "from",
- "to",
- "first",
- "latest",
- "min",
- "max",
- "change",
- "changePercent"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "series",
- "summary",
- "dateFilterAppliedLocally"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "dateFilterAppliedLocally": {
+ "type": "boolean"
+ },
+ "series": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "series": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "series"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "availablePoints": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "changePercent": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "first": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "from": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "market": {
+ "type": "string"
+ },
+ "max": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "min": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "missingPoints": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "points": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "to": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "market",
+ "points",
+ "availablePoints",
+ "missingPoints",
+ "from",
+ "to",
+ "first",
+ "latest",
+ "min",
+ "max",
+ "change",
+ "changePercent"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "series",
+ "summary",
+ "dateFilterAppliedLocally"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]market_get_product3 fields changedInput schema / properties / identityTypeRemoved value: -{
- "const": "id",
- "default": "id",
- "type": "string"
-}Input schema / properties / pagesRemoved value: -{
- "const": 0,
- "default": 0,
- "type": "number"
-}Input schema / properties / sizeRemoved value: -{
- "const": 1,
- "default": 1,
- "type": "number"
-}v1.0.7market_compare_basket4 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "items"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "items"
+]Output schema / properties / data / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "currency": {
+ "const": "TRY",
+ "type": "string"
+ },
+ "excludedCosts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "groupBy": {
+ "enum": [
+ "market",
+ "depot"
+ ],
+ "type": "string"
+ },
+ "groups": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "complete": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lines": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "lineTotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ },
+ "quantity": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "title",
+ "quantity",
+ "offer",
+ "lineTotal"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingProductIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresMultipleDepots": {
+ "type": "boolean"
+ },
+ "subtotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "total": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "complete",
+ "total",
+ "subtotal",
+ "lines",
+ "missingProductIds",
+ "requiresMultipleDepots",
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingProductIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "outOfScopeOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "offer"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "splitBasket": {
+ "additionalProperties": {},
+ "properties": {
+ "complete": {
+ "type": "boolean"
+ },
+ "lines": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "lineTotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ },
+ "quantity": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "title",
+ "quantity",
+ "offer",
+ "lineTotal"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingProductIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresMultipleDepots": {
+ "type": "boolean"
+ },
+ "subtotal": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "total": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "complete",
+ "total",
+ "subtotal",
+ "lines",
+ "missingProductIds",
+ "requiresMultipleDepots"
+ ],
+ "type": "object"
+ },
+ "unavailableOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "offer"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "warning": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "currency",
+ "groupBy",
+ "groups",
+ "splitBasket",
+ "missingProductIds",
+ "outOfScopeOffers",
+ "unavailableOffers",
+ "scope",
+ "excludedCosts",
+ "warning"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]market_compare_product_offers4 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "identity"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "identity"
+]Output schema / properties / data / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "cheapestDepotIds": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "cheapestPrice": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "currency": {
+ "const": "TRY",
+ "type": "string"
+ },
+ "highestPrice": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "offers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "savingIfCheapest": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price",
+ "savingIfCheapest"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "outOfScopeOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "offer": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "productId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "productId",
+ "offer"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "priceSpread": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "productId": {
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "unavailableOffers": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "depotId": {
+ "type": "string"
+ },
+ "depotName": {
+ "type": "string"
+ },
+ "marketAdi": {
+ "type": "string"
+ },
+ "price": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "depotId",
+ "depotName",
+ "marketAdi",
+ "price"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "productId",
+ "title",
+ "currency",
+ "cheapestPrice",
+ "highestPrice",
+ "priceSpread",
+ "cheapestDepotIds",
+ "offers",
+ "unavailableOffers",
+ "outOfScopeOffers",
+ "scope"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]market_find_alternatives3 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "id",
- "keywords",
- "marketName"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "id",
+ "keywords",
+ "marketName"
+]market_find_nearby_depots3 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance"
+]market_find_similar_products3 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "id",
- "keywords"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "id",
+ "keywords"
+]market_get_price_history4 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "uniqueId"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "uniqueId"
+]Output schema / properties / data / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "dateFilterAppliedLocally": {
+ "type": "boolean"
+ },
+ "series": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "series": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "series"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "availablePoints": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "change": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "changePercent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "first": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "latest": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "market": {
+ "type": "string"
+ },
+ "max": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "min": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "missingPoints": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "points": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "to": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "market",
+ "points",
+ "availablePoints",
+ "missingPoints",
+ "from",
+ "to",
+ "first",
+ "latest",
+ "min",
+ "max",
+ "change",
+ "changePercent"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "series",
+ "summary",
+ "dateFilterAppliedLocally"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]market_get_product3 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "identity"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "identity"
+]market_search_by_category3 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots"
+]market_search_products3 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "keywords"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "keywords"
+]market_status1 field changedOutput schema / properties / data / anyOfAdded value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "api": {
+ "additionalProperties": {},
+ "properties": {
+ "endpointCount": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "experimentalEndpointCount": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "liveValidationPerformed": {
+ "const": false,
+ "type": "boolean"
+ },
+ "liveValidationScope": {
+ "const": "runtime-session",
+ "type": "string"
+ },
+ "releaseVerificationReference": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "endpointCount",
+ "experimentalEndpointCount",
+ "liveValidationPerformed",
+ "liveValidationScope",
+ "releaseVerificationReference"
+ ],
+ "type": "object"
+ },
+ "currency": {
+ "const": "TRY",
+ "type": "string"
+ },
+ "experimentalEndpointsEnabled": {
+ "type": "boolean"
+ },
+ "limits": {
+ "additionalProperties": {},
+ "properties": {
+ "basketItems": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "basketRequestBudget": {
+ "const": 5,
+ "type": "number"
+ }
+ },
+ "required": [
+ "basketItems",
+ "basketRequestBudget"
+ ],
+ "type": "object"
+ },
+ "liveRequestsEnabled": {
+ "type": "boolean"
+ },
+ "locationDefaults": {
+ "additionalProperties": false,
+ "properties": {
+ "configured": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "configured"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "enum": [
+ "offline",
+ "live"
+ ],
+ "type": "string"
+ },
+ "requestPolicy": {
+ "additionalProperties": {},
+ "properties": {
+ "minIntervalMs": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "retries": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "scope": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "retries",
+ "minIntervalMs",
+ "scope"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "mode",
+ "liveRequestsEnabled",
+ "experimentalEndpointsEnabled",
+ "currency",
+ "locationDefaults",
+ "limits",
+ "requestPolicy",
+ "api"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]market_sync_products3 fields changedInput schema / properties / distance / defaultRemoved value: -1Input schema / properties / distance / descriptionPrevious value: -"Search radius in km. 50 is a local safety limit."New value: +"Required search radius in km. 50 is a local safety limit."Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "depots",
- "identities"
-]New value: +[
+ "latitude",
+ "longitude",
+ "distance",
+ "depots",
+ "identities"
+]v1.0.4market_compare_basketmarket_compare_product_offersmarket_find_alternativesmarket_find_nearby_depotsmarket_find_similar_productsmarket_geocode_addressmarket_get_categoriesmarket_get_price_historymarket_get_productmarket_list_marketsmarket_reverse_geocodemarket_search_by_categorymarket_search_productsmarket_statusmarket_sync_productsScored across 15 tools
Most tools have clearly distinct purposes (geocoding, depots, categories, search, comparison, history), but a few boundaries blur: market_compare_product_offers vs market_get_product both return one product's branch offers, and market_find_alternatives vs market_find_similar_products both surface related items. The unusually verbose descriptions help disambiguate, but an agent could still misselect between these pairs.
All 15 tools use a uniform market_ prefix with snake_case verb_noun patterns (list_markets, get_product, search_products, compare_basket, find_nearby_depots). The only deviation is market_status, which lacks a verb, but the overall convention is highly predictable.
15 tools sit at the top of the ideal 3-15 range and each earns its place, covering geocoding, depot discovery, category browsing, keyword search, product lookup, offer comparison, basket comparison, price history, and sync. No redundant or filler tools for the stated scope.
The read-only price-comparison domain is well covered end-to-end: location resolution, depot discovery, category navigation, search, single-product and basket comparison, history, and alternatives/similar products. Minor gaps exist (e.g., barcode lookup explicitly unsupported, no richer market/chain detail), but core agent workflows have no dead ends.
MCP server for real-time product search by barcode (EAN, UPC, GTIN) or keyword on ean-search.org
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
Search and get install details on MCP servers, right from your agent -- a unified marketplace index.
Google Shopping products, prices, sellers, and deals as structured data via a hosted MCP server.
