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-fiyatlari-mcp-server Süt 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.
Bu proje, Market Fiyatı API'si ile entegre olan bir MCP (Model Context Protocol) server sunmaktadır. Claude ve diğer MCP destekli AI sistemlerinin Türkiye'deki market fiyatlarını sorgulamasına olanak tanır.
Ürün Arama: İsim veya anahtar kelime ile ürün arama
Fiyat Karşılaştırma: Farklı marketlerdeki fiyatları karşılaştırma
Kaynak Erişimi: URI tabanlı kaynak erişimi (search/ ve product/ endpoint'leri)
MCP Araçları: AI'ın doğrudan kullanabileceği veri analiz araçları
Related MCP server: Market Fiyatı MCP Server
# Bağımlılıkları yükle
npm install
# TypeScript dosyalarını derle
npm run build
# Sunucuyu başlat
npm startClaude Desktop'un claude_desktop_config.json dosyasına aşağıdaki yapılandırmayı ekleyin:
{
"mcpServers": {
"marketfiyati": {
"command": "npx",
"args": ["-y @enescinar/market-fiyati-mcp"]
}
}
}Bu MCP server, Market Fiyatı API'sinin aşağıdaki endpointlerini kullanır:
/search: Ürün araması yapar
/searchByIdentity: ID ile ürün getirir
Sunucu aşağıdaki MCP araçlarını sağlar:
search_products: Ürün araması yapar
get_product_by_id: ID ile ürün getirir
compare_prices: Fiyat karşılaştırması yapar
Sunucu, üzerinden sorgulanabilecek şu MCP kaynaklarını sağlar:
market-fiyati://search/{query}: Ürün araması
market-fiyati://product/{id}: Ürün detayları
MIT
Bir ürünün farklı marketlerdeki fiyatlarını karşılaştırır
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | Ürün ID'si | |
| market | No | Belirli bir market için filtreleme (opsiyonel) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds minimal behavioral information. It does not disclose whether the operation is read-only, requires authentication, or any other side effects. The agent cannot infer data freshness or scope of markets covered.
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?
Single sentence, no superfluous words. Efficiently communicates the core functionality.
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?
No output schema is provided, and the description does not indicate the return format (e.g., list of prices, sorted, latest). For a comparison tool, this missing information limits an agent's ability to use the response effectively. However, the tool is relatively simple.
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% but parameter descriptions are minimal. The tool description reinforces the purpose of the market parameter (filtering by market) but does not add new semantic details beyond the schema. Baseline 3 is appropriate.
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 compares prices of a product across different markets. It uses a specific verb ('compares') and resource ('prices'), distinguishing it from siblings like get_product_by_id (single product retrieval) and search_products (product search).
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?
No explicit guidance on when to use this tool versus alternatives. The description implies price comparison but does not mention any prerequisites, exclusions, or context where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ürün ID'sine göre ürün detaylarını getirir
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | Ürün ID'si |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states it retrieves details but does not disclose behavior on missing IDs, return format, or whether it's read-only. Inadequate transparency for a fetch operation.
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?
Description is a single, efficient sentence. It is front-loaded but could be slightly more informative without losing conciseness.
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 no output schema or annotations, the description is too minimal. It does not cover error handling, return type, or relationship to sibling tools, leaving gaps for an agent.
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% (parameter already described). The tool description adds no further meaning to the parameter. Baseline 3 is appropriate as it does not reduce clarity.
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?
Description clearly states the verb (retrieves) and resource (product details) by product ID. It distinguishes from sibling tools like search_products and compare_prices by implying a single-product lookup, but could be more specific about what details are returned.
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?
No guidance on when to use this tool versus siblings (search_products, compare_prices). The description does not mention any context for use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Belirtilen arama sorgusuyla ürünleri arar
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Arama sorgusu |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination, or sorting. The agent must assume it is a read operation.
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 single sentence in Turkish, concise and front-loaded. It is not overly verbose, though it could include more useful 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?
Given the simple input (1 param) and no output schema, the description is minimally adequate but lacks details on return format or any constraints. It leaves 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 100% for the single parameter. The description adds no extra meaning beyond the schema's 'Arama sorgusu' ('Search query'). Baseline 3 is appropriate.
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 searches for products with a query. It is distinct from siblings like compare_prices and get_product_by_id, though it doesn't explicitly differentiate.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., compare_prices or get_product_by_id). Agents must infer from the name.
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.
v0.1.0compare_pricesget_product_by_idsearch_productsScored across 3 tools
Each tool has a distinct and clear purpose: search_products for searching, get_product_by_id for retrieving details by ID, and compare_prices for price comparison across markets. No overlap or ambiguity.
All tools follow a consistent snake_case verb_noun pattern (compare_prices, get_product_by_id, search_products), making it easy to infer their actions and targets.
With 3 tools, the server is well-scoped for a focused price comparison domain. Each tool is necessary and non-redundant, covering product search, detail retrieval, and price comparison.
The server covers the core functionalities for product price comparison. A minor gap is the lack of a tool to list available markets or categories, but the main workflow is complete.
Product Barcode API - camgoz.net: Provides information on products available in markets across.
Track prices & price history on any online shop, with alerts and an API
Search 100+ US retailers, 260M+ products with real-time pricing, stock, and price history. Documentation - https://www.lemmebuyit.com/developer Homepage - https://www.lemmebuyit.com
Real-time Amazon prices, product search, 90-day history, AI forecasts, and price drop alerts.
