CartScout MCP server

Overview Schema Source Related Servers Discussions Admin

Get product price and stock

get_product

Read-onlyIdempotent

Retrieve live pricing, stock status, discounts, variants, and ratings for a single product page across major e-commerce platforms—use the URL to get current data for price checks or comparisons.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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.	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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 14, 2026

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server