The provided schema exposes tools for product lookup, retailer offer comparison, price history, scheduled monitoring, and API usage checks.
Look up a single product by barcode/UPC/EAN, ASIN, URL, model number, or ShopSavvy ID.
Batch look up multiple products using comma-separated identifiers.
Get current pricing offers from all retailers or one specific retailer.
Retrieve historical price data within a date range, optionally filtered by retailer.
Schedule products for automatic price monitoring hourly, daily, or weekly.
Unschedule products and list all currently monitored products.
View current API usage statistics.
Provides Amazon product price lookup and offer retrieval through ShopSavvy, including looking up Amazon products by ASIN and getting current Amazon.com pricing offers for a product.
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., "@ShopSavvy Data API MCP Server Find product details for barcode 4905524937116"
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 any AI assistant real-time product prices, price history, deals and buying guides from ShopSavvy, via the Model Context Protocol.
No signup and no API key needed. Anonymous use is rate-limited per IP (10 tool calls per minute, 100 per hour). Add a Data API key for higher limits.
ShopSavvy hosts the server. Clients that support remote MCP servers connect by URL, with nothing to install:
https://api.shopsavvy.com/mcpThat's the Streamable HTTP endpoint. Older clients that only speak the HTTP+SSE transport can use https://api.shopsavvy.com/mcp/sse.
Per-client setup (Claude Code, Claude Desktop, claude.ai, ChatGPT, Codex, Gemini CLI, Cursor, VS Code, Windsurf) is at shopsavvy.com/agents.
Some clients can only launch a local command. This package is that command: a small bridge that relays MCP messages between your client and the hosted server. The tools always match the hosted server, because they come from it.
Requires Node.js 18+.
Claude Desktop — add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):
{
"mcpServers": {
"shopsavvy": {
"command": "npx",
"args": ["-y", "@shopsavvy/mcp-server"]
}
}
}Any other stdio client: run npx -y @shopsavvy/mcp-server.
Related MCP server: ecommerce-mcp-server
Get a key at shopsavvy.com/data, then:
Remote server: send the header Authorization: Bearer ss_live_…
This package: set the SHOPSAVVY_API_KEY environment variable:
{
"mcpServers": {
"shopsavvy": {
"command": "npx",
"args": ["-y", "@shopsavvy/mcp-server"],
"env": { "SHOPSAVVY_API_KEY": "ss_live_your_key_here" }
}
}
}Tool | What it does |
| Find a product by barcode/UPC/EAN, ASIN, URL, model number or name |
| Look up several products at once |
| Keyword search across the catalog |
| Ranked search with review summaries, good for category queries |
| Current prices from every retailer |
| Current prices from one retailer (e.g. |
| Price history over a date range |
| Automatic price monitoring (API key required) |
| Your API key's usage |
| Curated "best of" buying guides |
| Pros, cons and a verdict for a product |
| Answers to common questions about a product |
| When-to-buy timing advice |
"What's the best price for AirPods Pro right now?"
"Show me the price history for B0D1XD1ZV3 over the last month."
"Best air fryers, and where are they cheapest?"
"Is now a good time to buy a TV?"
git clone https://github.com/shopsavvy/shopsavvy-mcp-server
cd shopsavvy-mcp-server
bun install
bun run build
bun testSHOPSAVVY_MCP_URL points the bridge (and its tests) at another deployment of the server.
Docs: shopsavvy.com/agents
Email: hello@greatwork.company
MIT, see LICENSE.
View current API usage statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. The word 'View' clearly indicates a read-only operation, which is useful. However, it does not describe what statistics are included, how they are aggregated, or the response shape, so behavioral disclosure is minimal beyond indicating safety.
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, front-loaded sentence with no filler, redundancy, or irrelevant caveats. It earns its place and is appropriately sized for a zero-parameter tool.
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 parameterless read-only tool, the description is largely complete enough for selection and invocation. However, there is no output schema and no detail about what 'usage statistics' includes (e.g., call counts, quotas, time window), leaving moderate ambiguity about the expected return value.
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 has zero parameters and an empty input schema, so the description cannot add parameter-level meaning. Per rubric, 0 params earns a baseline 4 because there is no parameter ambiguity for an agent to resolve.
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 ('View') and a clear resource ('current API usage statistics'), which is distinct from the product-focused sibling tools. An agent can immediately identify this as the monitoring/usage tool without needing to inspect other definitions.
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 phrasing 'current API usage statistics' establishes a clear context: use this when you need current usage information. There are no plausible alternatives among the product-lookup siblings, so explicit exclusionary guidance is not necessary, but it stops short of stating precise when-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a product by barcode, ASIN, URL, model number, or ShopSavvy product ID
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Product identifier (barcode/UPC/EAN, ASIN, product URL, model number, or ShopSavvy ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation and identifier types; it does not mention what is returned, how ambiguity is handled, error behavior, or whether this performs a live network lookup.
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, focused sentence with no filler. The core operation and accepted inputs are presented immediately.
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 lookup tool, the input side is adequately covered. However, with no output schema and no annotations, the description does not clarify return values, possible failures, or how this tool relates to the batch and offers siblings, leaving moderate 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?
The schema description coverage is 100% and already enumerates the accepted identifier formats. The tool description largely repeats the schema rather than adding new parameter-level meaning, so it meets the baseline but does not exceed it.
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 action ('look up a product') and the resource, and enumerates the accepted identifier types. It does not explicitly distinguish itself from product_lookup_batch, though the singular phrasing and tool name imply single-product lookup.
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 given about when to use this tool versus product_lookup_batch, product_offers, or other siblings. The description only states what it does, not when it should be preferred or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up multiple products at once using comma-separated identifiers
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Comma-separated list of product identifiers (barcodes, ASINs, URLs, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Look up' implies a read operation, and 'multiple products at once' conveys batching behavior. It does not disclose limits on identifier count, handling of invalid/unknown identifiers, or partial-failure behavior, which would be valuable for a batch tool.
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?
A single, front-loaded sentence that conveys the core operation, scope, and input format without wasted words. It earns its place and is easy to parse quickly.
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 simple one-parameter tool, the description plus schema adequately cover how to invoke it. It is slightly incomplete only in not specifying what the batch response contains or any practical batch-size limits, but these are minor gaps given the simplicity of the tool.
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 fully documents the identifiers parameter. The description only restates the comma-separated format without adding meaning beyond the schema, so the 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?
States a specific verb ('Look up') and resource ('multiple products'), with the key batching mechanism ('comma-separated identifiers') included. This clearly distinguishes it from the sibling product_lookup tool, which presumably handles a single product.
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 phrase 'multiple products at once' implies this tool is for batch lookups rather than single-product lookups, and the input format gives a usage hint. However, it never explicitly contrasts it with product_lookup or states when alternatives like product_offers or product_price_history should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current pricing offers for a product from all retailers
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Product identifier (barcode, ASIN, URL, model number, or ShopSavvy ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read-only operation and 'current' indicates temporal freshness, but the description does not disclose the response shape, pagination, or any retailer-count limits. It is adequate but leaves behavioral details unstated.
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?
A single, front-loaded sentence with no filler. Every word contributes to scope or resource, making it an efficient and readable definition.
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-required-parameter query tool with no output schema, this description is largely sufficient: it names the action, resource, scope, and temporal freshness. It could be more complete by hinting at the return structure or pagination, but the low complexity keeps this from being a major 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?
Schema description coverage is 100%, and the schema already documents the identifier formats (barcode, ASIN, URL, model number, ShopSavvy ID). The description adds only 'for a product', so it does not meaningfully enrich parameter understanding 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 ('Get') and resource ('current pricing offers for a product from all retailers'), and 'all retailers' helps distinguish this from sibling product_offers_retailer. It clearly communicates what the tool does.
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 phrase 'from all retailers' provides clear context for when this tool should be used, and implicitly contrasts with retailer-specific siblings. It does not explicitly list exclusions or alternative tools, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current pricing offers for a product from a specific retailer
| Name | Required | Description | Default |
|---|---|---|---|
| retailer | Yes | Retailer domain name (e.g., 'amazon.com', 'bestbuy.com', 'target.com') | |
| identifier | Yes | Product identifier (barcode, ASIN, URL, model number, or ShopSavvy ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full disclosure burden, but it only says 'Get current pricing offers.' It does not disclose behavior such as how identifiers are resolved, whether the data is live/cached, possible response omissions, pagination, or error conditions.
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, concise sentence with no redundant filler. The verb, object, and key scope qualifier are front-loaded, making it quick to parse.
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 simple two-parameter read operation, the description plus schema covers the basic invocation. However, the absence of annotations, output schema, and any guidance about expected response shape or tool selection leaves some contextual gaps for an agent choosing among 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?
Schema description coverage is 100%, with useful format examples for both retailer and identifier. The description adds little parameter semantics beyond the schema, so the baseline score of 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 states the verb ('Get'), the resource ('current pricing offers'), and a clear scope condition ('for a product from a specific retailer'). This conveys what the tool does and distinguishes it from the general product_offers sibling by emphasizing retailer specificity, though it does not explicitly name the sibling it complements.
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 phrase 'from a specific retailer' implies this tool is appropriate when offers are needed for one known retailer. However, it does not explicitly state when to choose this over product_offers or other siblings, nor does it mention exclusions; the usage context must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical pricing data for a product within a specific date range
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | End date in YYYY-MM-DD format (e.g., '2024-01-31') | |
| retailer | No | Optional: specific retailer domain name to filter results | |
| identifier | Yes | Product identifier (barcode, ASIN, URL, model number, or ShopSavvy ID) | |
| start_date | Yes | Start date in YYYY-MM-DD format (e.g., '2024-01-01') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It implies a read-only operation via 'Get', but does not disclose output format, pagination, possible aggregation of price history, date-range validation, or behavior with unsupported identifiers.
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, compact sentence that directly conveys the tool's core purpose without repetition or filler. Every word contributes to meaning.
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 is adequate for a simple data-retrieval tool, but it lacks additional context such as what the history includes, how to interpret the returned data, or the role of the optional retailer parameter. With no output schema or annotations, a bit more context would improve completeness.
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 parameters and their formats. The description adds no parameter-level meaning beyond the schema, matching the baseline expectation without enhancing it.
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 action ('Get'), the resource ('historical pricing data'), and the scope ('within a specific date range'). It is distinct enough from siblings like product_lookup and product_offers, though it does not explicitly name or contrast them.
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 given about when to choose this tool over siblings such as product_lookup or product_offers, nor are any exclusions or prerequisites mentioned. The usage context is only minimally implied by the phrase 'historical pricing data'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule products for automatic price monitoring at regular intervals
| Name | Required | Description | Default |
|---|---|---|---|
| retailer | No | Optional: specific retailer domain to monitor | |
| schedule | Yes | Monitoring frequency | |
| identifiers | Yes | Comma-separated list of product identifiers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral effects, but it only states the action. It does not explain whether scheduling overwrites an existing schedule, whether duplicate schedules are allowed, what validation occurs, or what happens after a schedule is created. For a state-changing tool, this is a significant 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?
One sentence, active voice, and front-loaded with the core action and resource. Every word contributes meaning; there is no redundancy.
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 tool has no output schema and no annotations, yet the description does not mention expected result, confirmation behavior, or error handling. While the 100% schema coverage makes parameters invocable, an agent is left without context about what a successful call returns or how existing schedules are affected.
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 input schema already documents identifiers, schedule, and retailer. The description adds no parameter-level details beyond echoing 'regular intervals,' so the baseline of 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 uses a specific verb ('Schedule') plus a resource ('products') and a clear purpose ('automatic price monitoring at regular intervals'). This clearly distinguishes it from siblings like product_lookup, product_offers, product_unschedule, and scheduled_products_list.
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 phrase 'at regular intervals' implies the tool is for recurring monitoring rather than one-off lookups, and sibling names hint at complementary tools for listing or removing schedules. However, the description does not explicitly state when to prefer this tool or name alternatives such as product_unschedule or scheduled_products_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove products from the automatic price monitoring schedule
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Comma-separated list of product identifiers to unschedule |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the removal action without mentioning idempotency, error behavior for unknown identifiers, or whether unscheduling affects historical data. An agent cannot predict side effects from this description.
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?
A single, concise sentence that front-loads the action and target resource. There is no filler, repetition, or unnecessary detail.
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 one straightforward parameter, the description plus schema is sufficient for an agent to construct a valid invocation. It could mention response behavior or idempotency, but the absence is not critical given the tool's simplicity.
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 only parameter is already fully documented in the schema as a comma-separated list, and the description adds no new semantic detail beyond what the schema states. With 100% schema coverage, the baseline of 3 applies.
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 ('Remove') and a clear resource ('products from the automatic price monitoring schedule'). It distinguishes the tool from siblings like product_schedule and scheduled_products_list by stating the inverse operation explicitly.
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 that this tool is used when products should no longer be monitored, but it does not explicitly state when to use it over product_schedule or scheduled_products_list. No exclusion criteria or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View all products currently scheduled for automatic price monitoring
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. The verb 'View' implies a read-only operation, but the description does not confirm side-effect-free behavior, response format, or any caveats.
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, front-loaded sentence that conveys the full scope of the tool without extra words or redundant phrasing.
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 zero-parameter list tool, the description adequately states what the operation covers. It does not describe the return fields or pagination behavior, but the low complexity makes the description sufficient 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?
The tool has zero parameters, so there are no parameter semantics for the description to clarify. The baseline of 4 applies, and no further parameter documentation is needed.
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 ('View') and a clear resource ('products currently scheduled for automatic price monitoring'). It naturally distinguishes this list operation from the scheduling and unscheduling sibling tools.
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 phrase 'currently scheduled for automatic price monitoring' provides clear context for when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the intended use is obvious given the sibling tool names.
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.
v1.0.4api_usageproduct_lookupproduct_lookup_batchproduct_offersproduct_offers_retailerproduct_price_historyproduct_scheduleproduct_unschedulescheduled_products_listScored across 9 tools
Each tool targets a distinct operation: lookup vs batch lookup, all-retailer offers vs specific-retailer offers, schedule vs unschedule, plus a dedicated usage tool. There is no meaningful overlap or ambiguity between tool purposes.
Most tools follow a clear product_<action> pattern (product_lookup, product_offers, product_schedule, product_unschedule). One exception is scheduled_products_list, which inverts the pattern and would be more consistent as product_list_scheduled, but overall the naming is predictable.
Nine tools is well-scoped for a product data API server. Each tool covers a distinct function—lookup, offers, history, scheduling, and usage—without unnecessary redundancy or bloat.
The surface covers core product lookup, offers, price history, and scheduling lifecycle (schedule, unschedule, list). A minor gap is the lack of an update mechanism for scheduled monitoring intervals, but the primary workflows are fully supported.
Product price checks and affiliate link building for AI shopping agents.
Real-time Amazon prices, product search, 90-day history, AI forecasts, and price drop alerts.
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.
