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., "@CartScout MCP server Compare these product links and tell me the cheapest one in stock."
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.
Give Claude, Cursor or any MCP-capable AI agent live product prices, stock, variants and deal ratings from online stores. Paste a product link into the chat and ask "is this a good price?", "which of these three stores is cheapest and in stock?" or "does it come in size 10?".
Works with Shopify, WooCommerce, Walmart and eBay stores, with Amazon in beta. The data comes from the CartScout API, which handles fetching, bot filters and parsing. Try the API in your browser first, no sign-up needed.
Tool | What the agent gets | Uses |
| Price, list price and discount, stock, variants (sizes, colours) with their own price and stock, SKU / GTIN, rating, optional reviews and description | 1 extraction |
| 2-10 pages ranked: cheapest, cheapest in stock, best rated, biggest discount, price spread, same product by GTIN | 1 extraction per URL, PRO plan or higher |
| Deal rating of the current price against its recorded history, with average, lowest and highest price | 1 extraction (or none with |
| Recorded price and stock changes with current, lowest and highest price | No extractions |
Every tool is read-only and returns structured JSON with an output schema. Responses are trimmed for agents: bulky parts such as all variants, reviews and the description are included only when the agent asks for them.
Related MCP server: ecommerce-mcp-server
Subscribe to CartScout on RapidAPI. The free plan includes 300 extractions a month: plans.
Copy your X-RapidAPI-Key from the RapidAPI dashboard.
Add the server to your client. It runs with uv, which installs it on first use.
claude mcp add cartscout -e RAPIDAPI_KEY=your-rapidapi-key -- uvx --from git+https://github.com/Veselin15/cartscout-mcp cartscout-mcpSettings → Developer → Edit config, then add:
{
"mcpServers": {
"cartscout": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Veselin15/cartscout-mcp", "cartscout-mcp"],
"env": { "RAPIDAPI_KEY": "your-rapidapi-key" }
}
}
}Add the same mcpServers block to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project).
"What does https://www.allbirds.com/products/mens-tree-runner-nz-ochre cost, and is size 10 in stock?"
"Is $79 a good price for this air fryer? https://www.walmart.com/ip/844320666"
"Compare these three listings and tell me the cheapest one I can buy today: …"
"Show me how the price of this product changed over the last two weeks."
CartScout reads product pages; it does not search stores. Give the agent product URLs, or let it find them with a web search tool first.
Variable | Default | Purpose |
| required | Your RapidAPI key |
|
| RapidAPI host of the API |
| unset | Use a directly issued CartScout key instead of RapidAPI |
The server sends only the product URLs your agent asks about to the CartScout API. Without a key
it still starts and lists its tools (handy for MCP inspectors); each tool call then explains how to
add RAPIDAPI_KEY.
docker build -t cartscout-mcp .
docker run -i --rm -e RAPIDAPI_KEY=your-rapidapi-key cartscout-mcpcartscout-mcp --transport streamable-http --port 8000 serves the tools at
http://127.0.0.1:8000/mcp. Every client connected to it uses the key from the environment, so keep
it on a private address.
Prices follow each store's own region and currency.
Results can be cached for up to 60 minutes (cached: true).
Price history and deal ratings build up as products are read. A product seen for the first time has little history to compare against.
History range depends on the plan: 14 days on the free plan, up to 365 days on MEGA.
When a store blocks a request, the tool returns an error explaining it, and the failed request is not billed.
uv sync
uv run pytestMIT
Rate whether a product's current price is a good deal compared with its recorded price history, with the average, lowest and highest price in the period. History builds up each time CartScout reads the product, so a product seen for the first time has little to compare against.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of one product page, e.g. https://www.allbirds.com/products/mens-tree-runner-nz-ochre | |
| days | No | Period to compare against, capped by the plan. | |
| refresh | No | Fetch the current price first so the rating includes today (1 extraction). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| days | Yes | Days of history analyzed, limited by the plan. |
| verdict | Yes | One-sentence explanation of the rating. |
| currency | No | |
| refreshed | No | True when the current price was fetched just before rating. |
| data_points | No | |
| deal_rating | Yes | How the current price compares with its recorded history, from the lowest price in the period through great, good and fair to high; insufficient_data while the product has less than a day of history. |
| lowest_price | No | |
| average_price | No | Time-weighted average price over the period. |
| current_price | No | |
| highest_price | No | |
| price_changes | No | |
| lowest_price_at | No | |
| highest_price_at | No | |
| in_stock_percent | No | |
| last_observed_at | No | |
| percent_vs_average | No | |
| current_availability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint/openWorldHint/idempotentHint annotations by explaining that price history accumulates over CartScout reads and that first-time products have little to compare against. It also states the rating basis (average, lowest, highest). This is useful behavioral context with no contradiction to the 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?
The description is two sentences with no filler. The first sentence front-loads the core action and comparison inputs, while the second adds an important behavioral caveat about new products. Every phrase contributes to the agent's judgment.
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 complete parameter descriptions, an output schema, and strong annotations, the description focuses on the genuinely missing context: history behavior and the limitation of first-time products. It does not need to explain return values because the output schema already exists, though it could have more explicitly listed when to prefer sibling tools.
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?
All three parameters already have solid descriptions in the schema, so the description does not need to repeat them. It adds high-level context about the timeframe and comparison basis, but it does not materially deepen meaning for url, days, or refresh beyond what the schema already states.
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 predicate ('rate whether a product's current price is a good deal') and a clear resource ('recorded price history' with average, lowest, and highest price). This makes it easy to distinguish from get_product, compare_products, and get_price_history even without baking alternatives into the text.
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 most meaningful after a product has been read enough times to build history, and it calls out the first-visit limitation. However, it never explicitly says when to prefer check_deal over get_price_history or compare_products, nor gives concrete guidance such as a minimum history threshold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-10 product pages side by side: cheapest, cheapest in stock, best rated, biggest discount, price spread and whether every page sells the same product (matching GTIN). Uses 1 extraction per URL and needs a paid CartScout plan (PRO or higher).
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | 2 to 10 product page URLs, e.g. one item at several stores. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| failed | Yes | |
| summary | Yes | |
| products | Yes | |
| succeeded | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: it uses 1 extraction per URL and requires a paid CartScout plan (PRO or higher). This goes beyond the annotations and helps the agent understand cost and access 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?
Two sentences, front-loaded with the core purpose and comparison dimensions, followed by cost/plan constraints. Every sentence earns its place; no fluff.
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?
The description covers what the tool does, the input constraints, the cost model, and the plan requirement. The output schema exists, so return values don't need to be described. Minor gap: it doesn't mention what happens if URLs are invalid or not product pages, but that's not essential for an agent to invoke it correctly.
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%, so the schema already documents the 'urls' parameter. The description adds the 2-10 range and the example 'one item at several stores', which reinforces but doesn't significantly extend 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's function: comparing 2-10 product pages side by side, and lists the specific comparison dimensions (cheapest, cheapest in stock, best rated, biggest discount, price spread, GTIN matching). This distinguishes it from siblings like get_product or get_price_history.
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 specifies the input range (2-10 URLs) and the use case (comparing the same product across stores). It doesn't explicitly say when NOT to use it or name alternatives, but the context signals and sibling list make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recorded price and stock changes of a product page, with the current, lowest and highest price. History exists only for products CartScout has read before; call get_product first to start it. Does not use extractions.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of one product page, e.g. https://www.allbirds.com/products/mens-tree-runner-nz-ochre | |
| days | No | Days of history, capped by the plan (14 on the free plan). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| days | Yes | Days of history returned, limited by the plan. |
| points | Yes | Oldest first; a point is recorded when price or stock changes. |
| currency | No | |
| lowest_price | No | |
| current_price | No | |
| highest_price | No | |
| points_omitted | No | Older points left out to keep the answer short. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is read-only, idempotent, and open-world. The description adds useful behavioral facts not available from annotations: the dependency on a prior get_product call and the explicit statement that extractions are not used. This goes beyond the structured metadata without contradicting it.
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 value: what the tool returns, when it is available, and what it does not do. The most important prerequisite is front-loaded and there is no redundant restating of the tool name.
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 output schema, read-only/idempotent annotations, and fully described parameters, the description covers the only real gap: the state dependency on a prior get_product call. An agent has enough context to invoke this tool correctly in most situations.
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%, so both url and days are already well documented. The description's prerequisite note adds an operational constraint on the url parameter that is not in the schema, but it does not add direct detail about parameter formats or defaults.
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 identifies the resource (a product page) and what is returned (recorded price and stock changes, current/lowest/highest price). It does not explicitly contrast itself against compare_products or check_deal, but the notion of price history is distinct enough.
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 concrete usage context: history only exists for products CartScout has already read, and it directs the agent to call get_product first to start the history. It does not enumerate when to avoid this tool in favor of siblings, but the prerequisite guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the live price, stock status, discount, variants, identifiers (SKU, GTIN) and rating of one product page. Works with Shopify, WooCommerce, Walmart and eBay stores, Amazon in beta. Uses 1 extraction from the user's CartScout plan.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of one product page, e.g. https://www.allbirds.com/products/mens-tree-runner-nz-ochre | |
| include_reviews | No | Add up to 10 customer reviews from the page. | |
| include_variants | No | Add every size/colour option with its own price and stock (up to 50). | |
| include_description | No | Add the product description. |
| Name | Required | Description |
|---|---|---|
| mpn | No | |
| sku | No | |
| url | Yes | Product page URL after redirects. |
| gtin | No | GTIN / UPC / EAN barcode number. |
| brand | No | |
| image | No | Main product image URL. |
| price | No | Current price in the store's currency. |
| store | Yes | Store domain. |
| title | No | |
| cached | No | True when served from a cache up to 60 minutes old. |
| rating | No | |
| seller | No | |
| reviews | No | Present when include_reviews is true. |
| category | No | |
| currency | No | ISO 4217 code, e.g. USD. Prices follow the store's region. |
| in_stock | No | True if it can be bought now; null when unknown. |
| variants | No | Present when include_variants is true. |
| condition | No | |
| description | No | Present when include_description is true. |
| image_count | No | |
| availability | No | in_stock, limited_availability, out_of_stock, pre_order, back_order, discontinued or unknown. |
| extracted_at | No | When the page was read (UTC). |
| variant_count | No | Number of sizes, colours or other options. |
| original_price | No | List or strikethrough price before a discount. |
| discount_percent | No | |
| review_count_on_page | No | Reviews published on the page itself. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and open-world behavior. The description adds valuable context beyond that: it consumes '1 extraction' from the user's plan, reports that Amazon support is beta, and clarifies that data is live. This gives the agent useful operational expectations that annotations do not cover.
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 compact sentences with no filler. The first sentence front-loads the tool's core purpose and output, the second gives platform scope, and the third communicates quota cost. Every sentence 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?
With a complete input schema, an output schema available, and annotations covering safety and idempotence, the description sufficiently covers the remaining operational context: platform support, quota consumption, and beta status. Nothing essential for invoking this tool correctly 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 description coverage is 100%, so the schema already documents all four parameters well, including defaults and constraints. The description mentions 'variants' as a return field but does not add significant meaning to the individual parameters beyond what the schema provides.
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 ('Get'), a concrete resource ('one product page'), and enumerates the exact data returned (price, stock, discount, variants, identifiers, rating). It also distinguishes this tool from siblings by emphasizing 'live' data for a single product, which contrasts with get_price_history and compare_products.
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 usage context: it is for a single product page and lists supported platforms (Shopify, WooCommerce, Walmart, eBay, Amazon beta). It does not explicitly name alternatives or when-not conditions, but the 'one product page' framing plus platform scope makes the intended use clear.
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.0check_dealcompare_productsget_price_historyget_productScored across 4 tools
Each tool targets a clear, distinct operation: one product snapshot, multi-product comparison, deal rating, and historical data. While check_deal and get_price_history both use history, check_deal provides a computed verdict while get_price_history returns raw data, so there is no real ambiguity.
All tool names follow a consistent verb_noun pattern with lowercase snake_case: get_product, compare_products, check_deal, get_price_history. The verb choice clearly conveys the action and the object is always the resource involved.
Four tools is an appropriately tight scope for a price-tracking and product-research server. Each tool covers a distinct core need—single product lookup, comparison, deal assessment, and history—without redundancy or bloat.
The core product research and price history lifecycle is covered well, including starting history via get_product. Minor gaps exist such as no search/discovery tool or watchlist/alerts, but the available tools support the main workflows without dead ends.
Verify live product price, currency, stock, variants and published shipping evidence for AI agents.
AI-powered product search, affiliate links, and price negotiation for e-commerce platforms
Product search for AI agents: Amazon + Shopify, cart-to-checkout buy path. Pay-per-call, no API key.
AI-agent product catalog: search, lookup & purchase routing over verified merchant data.
