A
licenseA
qualityB
maintenanceCompetitive intelligence platform with 24 tools. Monitor competitor pricing, content, positioning, tech stacks, and AI visibility — track how ChatGPT, Claude, and Gemini rank your brand.
33
2
MIT
pricepilot-mcp
The PricePilot MCP server provides read-only Amazon pricing intelligence for CPG brands, offering competitive price benchmarking across Grocery & Gourmet Food, Health & Beauty, Household, and Pet Supplies categories.
get_price_position– Input a product price and category to get its percentile rank, Price Index (ratio vs. category median), and positioning label (Value / Parity / Premium) against 100+ tracked Amazon competitors.get_category_trend– Get the 30-day price trend direction (Rising / Stable / Falling) for a CPG category — useful for timing promotions or price changes.get_category_overview– Retrieve the full tier breakdown (budget / midmarket / premium bands), median price, and product count for a category.compare_products– Stack-rank a list of 1–20 SKUs against the category, returning per-product percentile rank, position, and difference vs. the category median.list_categories– List all available categories with product counts and current trend directions — recommended as the first call in any workflow to get exact category names.server_status– Verify server health and data freshness; returns a degraded status if the snapshot data is more than 10 days old.
Provides Amazon pricing intelligence for multi-channel CPG brands, offering tools for price position analysis, category trends, product comparison, and category overview based on weekly Amazon Buy Box scans across Grocery, Health & Beauty, Household, and Pet Supplies.
PricePilot MCP Server
Free Amazon pricing intelligence for multi-channel CPG brands, exposed as a Model Context Protocol server. Six read-only tools over a point-in-time Amazon Buy Box snapshot across Grocery, Health & Beauty, Household, and Pet Supplies.
A free alternative to NielsenIQ / SPINS syndicated category data — accessible from any MCP client (Claude Desktop, Claude.ai, Cursor, Continue, agent frameworks).
What it does
Given a price and a category, the server answers questions like:
Where does this Amazon price sit against 100+ tracked competitors?
Is the category trending up, stable, or falling over the last 30 days?
What are the budget / midmarket / premium price bands?
How do these N SKUs stack against each other on the shelf?
The server returns derived statistics only — percentile rank, Price Index, trend direction, tier bands. No raw competitor prices are exposed.
Related MCP server: PricePilot for Claude Desktop
Connect
Hosted endpoint (no install)
{
"mcpServers": {
"pricepilot": {
"url": "https://pricepilot-mcp.onrender.com/mcp"
}
}
}No API key. Rate limited to 60 requests/minute, 1000/day.
Claude Desktop (one-click, recommended)
Use the official .mcpb extension at https://github.com/vantage-meridian-group/pricepilot-mcpb/releases/latest — drag-and-drop into Claude Desktop.
Local stdio (for development)
pip install -e .
DATABASE_URL=postgresql://... python -m pricepilot_mcpTools
Tool | What it returns |
| Percentile rank, Price Index, position (Value / Parity / Premium) for a single price |
| 30-day trend direction (Rising / Stable / Falling) with sample size |
| Tier breakdown (budget / midmarket / premium bands) and median |
| Per-SKU stack rank for a list of products against the category |
| Available categories with product counts and trend — call this first |
| Health and data freshness (degraded if seed is >10 days old) |
All tools are readOnlyHint=true, destructiveHint=false, openWorldHint=false.
Categories
A point-in-time snapshot from Amazon Buy Box scans (see server_status for the snapshot date):
Grocery & Gourmet Food
Health & Beauty
Household
Pet Supplies
Architecture
FastMCP with Streamable HTTP and stdio transports
SQLAlchemy + PostgreSQL for benchmark snapshots (read-only from the server's perspective)
Rate-limited per-consumer with daily and per-minute buckets
Dockerfile included; deploys to any container host (production runs on Render)
Run with Docker
docker build -t pricepilot-mcp .
docker run -p 8081:8081 -e DATABASE_URL=postgresql://... pricepilot-mcpOperator note
The MCP server is a free, category-level, point-in-time snapshot of PricePilot data. The paid per-SKU analysis platform is not currently available. More about the team at https://vantagemeridiangroup.com.
License
MIT — see LICENSE.
Available Tools
6 toolscompare_productsCompare Multiple ProductsARead-only
Compare multiple product prices against an Amazon CPG category's peers.
Use when a multi-channel CPG brand needs to stack-rank their SKUs — e.g. identifying which SKUs are underpriced relative to Amazon peers, flagging products where the Amazon Buy Box sits materially below the retail MSRP, or building a cross-channel price-audit table for an ops review. Replaces manual store walks and spreadsheet comparisons.
Returns: comparisons (list, per product: name, price, percentile_rank, position, vs_median), category, category_trend, sample_size, last_refreshed, cta.
Args: products: List of items, each a dict with 'name' (string) and 'price' (number in dollars). Minimum 1 item; 3-20 is the useful range. category: Exact category name — Grocery & Gourmet Food, Health & Beauty, Household, or Pet Supplies. Case-insensitive.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| products | Yes | ||
| category | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of comparisons and returns is consistent. It adds value by detailing the return structure and typical use cases. However, it does not explicitly state that no data is modified, but the annotations already cover that. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then use cases, then return fields, then args. It is slightly verbose with multiple example scenarios, but each sentence adds value. Could be tightened slightly but still effective.
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?
Given no output schema, the description lists all return fields. Input is fully described with constraints and examples. Usage context is thorough. The tool is self-contained and leaves little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description fully defines the 'products' parameter as a list of objects with 'name' and 'price' (number in dollars), including constraints (min 1, useful 3-20). The 'category' parameter is explained with case-insensitivity and example values. This compensates entirely for the lack of schema property descriptions.
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 uses a specific verb 'compare' and targets a clear resource: 'multiple product prices against an Amazon CPG category's peers'. It explicitly distinguishes from sibling tools like 'get_price_position' (single product) by framing the multi-product comparison use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios (e.g., stack-ranking SKUs, flagging underpriced products, building price-audit tables) and indicates a useful range of 3-20 items. It implies alternatives for single-product queries, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_category_overviewGet Category Pricing OverviewARead-only
Return pricing-tier breakdown and category stats for an Amazon CPG category.
Use when a brand is sizing up a shelf — e.g. evaluating whether a new SKU should enter at budget / midmarket / premium tier, benchmarking their retail pricing against Amazon tier structure, or preparing for a retail buyer meeting that will ask "what's the typical shelf price here?".
Returns: category (resolved name), product_count (bucketed, e.g. "100+ products"), price_tiers (dict with budget / midmarket / premium dollar bands, rounded to nearest $0.50 for abstraction), median_price, trend_direction, last_refreshed, cta.
Args: category: Exact category name — Grocery & Gourmet Food, Health & Beauty, Household, or Pet Supplies. Case-insensitive.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=true, so no destructive concern. The description adds detail on return fields (product_count bucketed, price_tiers with dollar bands) and notes case-insensitivity, but does not address error handling or latency.
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?
The description is well-structured with a clear first line, bullet points for returns, and an Args section. No redundancy; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, the description covers purpose, usage, return fields, and parameter constraints. Lacks details on error cases or data freshness guarantees, but sufficient for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully documents the single parameter: it lists allowed enum-like values and states case-insensitivity, adding critical meaning beyond the schema's minimal type and title.
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 clearly states it returns pricing-tier breakdown and category stats for an Amazon CPG category, with specific return fields listed. It distinguishes from siblings like get_category_trend and compare_products by focusing on overview and tier analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided (sizing up a shelf, evaluating entry tiers, benchmarking), and it mentions exact allowed category values. It implicitly suggests when not to use (for product-level comparison) by contrasting with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_category_trendSee Category Pricing TrendARead-only
Report the 30-day Amazon price-trend direction for a CPG category.
Use when a pricing ops lead asks whether category pricing is rising, stable, or falling — e.g. setting retail promo calendar against an Amazon backdrop, deciding whether to raise wholesale prices during inflationary windows, or catching a price war before it spills into their channel.
Returns: trend_direction (Rising / Stable / Falling / Insufficient Data), trend_window ("30 days"), confidence (note with product count), category (resolved name), last_refreshed, cta.
Args: category: Exact category name — Grocery & Gourmet Food, Health & Beauty, Household, or Pet Supplies. Case-insensitive.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. Description adds return fields (trend_direction, confidence with product count, etc.) and notes case-insensitivity. No contradictions; the added context is valuable but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections for purpose, usage, returns, and args. Around 150 words, front-loaded with purpose. Could be trimmed slightly but efficiently conveys necessary information.
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?
For a simple tool with one parameter and no output schema, the description covers purpose, usage, parameter constraints, and return fields. No gaps given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no enum or description (0% coverage). Description compensates by listing exact allowed category names and stating case-insensitivity. This is critical for correct invocation.
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?
Description clearly states the tool reports 30-day Amazon price-trend direction for a CPG category. It uses specific verb 'Report' and distinguishes from siblings like get_category_overview and get_price_position by focusing on trend direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (e.g., pricing ops lead asking trend, setting promo calendar, deciding wholesale prices, catching price war). Examples give clear context, though it does not mention when not to use; the vivid use cases fully suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_positionCheck Competitive Price PositionARead-only
Percentile-rank a single product price against tracked Amazon competitors in a CPG category.
Use when a multi-channel CPG brand asks where their Amazon listing price sits against 100+ tracked products — e.g. checking whether a $4.99 granola is competitively positioned on Amazon, auditing whether a retail MSRP is reasonable against Amazon reality before a buyer meeting, or sanity-checking a wholesale-to-retail markup.
Returns: percentile_rank (string, e.g. "72nd percentile"), price_index_label (ratio vs. category median), position (Value / Parity / Premium), category (resolved name), last_refreshed (ISO timestamp), cta (link to full per-SKU report).
Args: price: Product price in dollars (e.g. 4.99). Must be > 0 and <= 10000. category: Exact category name — Grocery & Gourmet Food, Health & Beauty, Household, or Pet Supplies. Case-insensitive. Call list_categories first to confirm available names.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | ||
| category | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds value by detailing the return fields (percentile_rank, price_index_label, position, category, last_refreshed, cta) and constraints (price must be >0 and <=10000). No contradictions with annotations.
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?
The description is well-structured with a clear purpose statement, bullet-point return values, and parameter explanations. It is concise, front-loaded, and every sentence adds value.
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?
Given the tool's simplicity (2 required params, no enums, no output schema), the description covers all necessary aspects: purpose, usage context, parameter constraints, and return values. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description compensates by providing clear explanations for both parameters: price format and range, category exact names and case-insensitivity, and a recommendation to use list_categories. This fully compensates for the schema gap.
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 clearly states the tool's function: 'Percentile-rank a single product price against tracked Amazon competitors in a CPG category.' It provides specific use cases (e.g., checking if a $4.99 granola is competitively positioned) and distinguishes it from sibling tools like compare_products and list_categories.
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 explicit guidance on when to use this tool ('Use when a multi-channel CPG brand asks where their Amazon listing price sits...') and suggests calling list_categories first to confirm category names. However, it does not explicitly state when not to use it or mention alternatives like compare_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList Available CategoriesARead-only
List Amazon CPG categories with current product counts and trend direction.
Use as the first call in any pricing-analysis workflow — returns the exact category names expected by other tools, plus product count and trend for each. Lightweight; safe to call before any category-specific query.
Returns: categories (list of {name, product_count, trend_direction, last_refreshed}), note (summary of coverage), cta.
Covers Grocery & Gourmet Food, Health & Beauty, Household, and Pet Supplies.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds context by stating it is lightweight and safe, and details the return structure, which goes beyond annotations.
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?
The description is concise with a clear first sentence, followed by usage guidance, return format, and coverage. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the return format and specific categories covered. Could include more detail on the 'note' and 'cta' fields, but overall sufficient for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. The description adds value by listing the categories covered (Grocery & Gourmet Food, etc.) and describing the return object structure, compensating for the lack of parameters.
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 clearly states the tool lists Amazon CPG categories with product counts and trend direction, using a specific verb and resource. It distinguishes itself from sibling tools by positioning as the first call in a pricing-analysis workflow.
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?
Explicitly states to use as the first call before category-specific queries and notes it is lightweight and safe. Could be improved by mentioning when not to use, but the context of siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
server_statusCheck Server StatusARead-only
Report PricePilot server health, data freshness, and degraded-state reason.
Use to check whether category seeding is current (staleness threshold is 10 days) before trusting downstream tool output. Returns degraded status with reason if data is overdue; healthy otherwise.
Returns: server (name), version, status (healthy / degraded), categories_available, data_freshness (ISO timestamp of last seed), degraded_reason (null if healthy).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description adds the staleness threshold (10 days), degraded reason behavior, and specific return fields. This fully discloses operational behavior.
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?
Description is concise, front-loads purpose and usage, then lists return fields. Every sentence adds value; no redundancy.
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?
Given no parameters and no output schema, the description fully explains all return fields with types and conditions. It is complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (0 params, 100% schema coverage). Baseline of 4 is appropriate since description has no need to explain parameters.
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 clearly states it checks server health, data freshness, and degraded-state reason. It distinguishes from siblings like compare_products and get_category_overview by focusing on server status rather than product or category data.
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 explicitly advises using this tool to verify category seeding currency before trusting downstream tools, providing clear context. It lacks explicit when-not-to-use but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
- First observed
compare_products - First observed
get_category_overview - First observed
get_category_trend - First observed
get_price_position - First observed
list_categories - First observed
server_status
TDQS
A4.6/5.0
Scored across 6 tools
Disambiguation5/5
Each tool has a distinct purpose: listing categories, getting overview, trend, single price position, multi-product comparison, and server health. No overlap.
Naming Consistency4/5
Most tools use verb_noun pattern (list_categories, get_category_overview, etc.), but 'server_status' is a noun_noun exception. Overall consistent and readable.
Tool Count5/5
6 tools is well-scoped for a pricing intelligence server; each tool serves a clear role without being too few or too many.
Completeness5/5
Covers all essential operations: listing categories, getting overview/trend, single and multi-product price analysis, and server health. No obvious gaps.
Maintenance
ActivityNo data
ResponsivenessNo issues
Related MCP Connectors
Free competitive pricing intelligence for CPG brands across Amazon categories.
Real-time product data across 450+ retailers — look up any UPC for prices, images, and margin data.
Unwrangle MCP — cross-retailer product + reviews data (unwrangle.com)
Cross-merchant product search with real price history, comparisons, and demand signals.
Related MCP Servers
- AlicenseAqualityCmaintenanceFree competitive pricing intelligence for SMB CPG brands. Check where any product price sits in its Amazon category, track pricing trends, and compare products — no NielsenIQ or SPINS subscription needed.6MIT
- FlicenseNot gradedqualityCmaintenanceMonitors and analyzes product prices across major e-commerce platforms (Taobao, JD, PDD, 1688, Amazon) with tools for price alerts, competitor comparison, market trends, and deal detection.-
- AlicenseAqualityAmaintenanceReal-time Amazon Sponsored Products (SP) ad placements, keyword tracking, and comprehensive review data for AI Agents. Enables LLMs to autonomously conduct competitor ad audits, consumer sentiment analysis (VOC), and product optimization.196MIT
