A
licenseA
qualityA
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.
48
3
MIT
pricepilot-mcp
Servidor MCP PricePilot
Inteligencia de precios de Amazon gratuita para marcas de CPG multicanal, expuesta como un servidor del Protocolo de Contexto de Modelo (MCP). Seis herramientas de solo lectura sobre escaneos semanales de Buy Box en comestibles, salud y belleza, hogar y artículos para mascotas.
Una alternativa gratuita a los datos de categorías sindicados de NielsenIQ / SPINS, accesible desde cualquier cliente MCP (Claude Desktop, Claude.ai, Cursor, Continue, marcos de trabajo de agentes).
Qué hace
Dada un precio y una categoría, el servidor responde preguntas como:
¿Dónde se sitúa este precio de Amazon frente a más de 100 competidores rastreados?
¿La categoría tiene una tendencia al alza, estable o a la baja en los últimos 30 días?
¿Cuáles son las bandas de precios económicos / de gama media / premium?
¿Cómo se comparan estos N SKU entre sí en el estante?
El servidor devuelve solo estadísticas derivadas: rango percentil, índice de precios, dirección de la tendencia, bandas de nivel. No se exponen precios brutos de la competencia.
Related MCP server: PricePilot for Claude Desktop
Conectar
Punto final alojado (sin instalación)
{
"mcpServers": {
"pricepilot": {
"url": "https://pricepilot-mcp.onrender.com/mcp"
}
}
}Sin clave API. Límite de tasa de 60 solicitudes/minuto, 1000/día.
Claude Desktop (un clic, recomendado)
Utilice la extensión oficial .mcpb en https://github.com/vantage-meridian-group/pricepilot-mcpb/releases/latest: arrastre y suelte en Claude Desktop.
stdio local (para desarrollo)
pip install -e .
DATABASE_URL=postgresql://... python -m pricepilot_mcpHerramientas
Herramienta | Qué devuelve |
| Rango percentil, índice de precios, posición (Valor / Paridad / Premium) para un precio único |
| Dirección de la tendencia de 30 días (En aumento / Estable / En descenso) con tamaño de muestra |
| Desglose de niveles (bandas económicas / de gama media / premium) y mediana |
| Clasificación por SKU para una lista de productos frente a la categoría |
| Categorías disponibles con recuentos de productos y tendencia: llame a esto primero |
| Estado de salud y frescura de los datos (degradado si la semilla tiene más de 10 días) |
Todas las herramientas son readOnlyHint=true, destructiveHint=false, openWorldHint=false.
Categorías
Actualizado semanalmente desde escaneos de Amazon Buy Box:
Comestibles y alimentos gourmet
Salud y belleza
Hogar
Artículos para mascotas
Arquitectura
FastMCP con transportes HTTP transmitibles y stdio
SQLAlchemy + PostgreSQL para instantáneas de referencia (solo lectura desde la perspectiva del servidor)
Límite de tasa por consumidor con cubos diarios y por minuto
Dockerfile incluido; se implementa en cualquier host de contenedor (la producción se ejecuta en Render)
Ejecutar con Docker
docker build -t pricepilot-mcp .
docker run -p 8081:8081 -e DATABASE_URL=postgresql://... pricepilot-mcpNota del operador
El servidor MCP es la superficie gratuita a nivel de categoría de PricePilot. Las recomendaciones de precios por SKU (la alineación de precios R1 está activa; R2 / R3 / R5 se expandirán durante el segundo trimestre) se entregan a través de la plataforma paga en https://app.pricepilot.vantagemeridiangroup.com.
Licencia
MIT: consulte 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
ActivityMaintained
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.
Amazon competitor research for Claude, ChatGPT and other MCP clients: complaint topics from Amazon's "Customers say" summary of all reviews, 90-day price/rank/review history, listing audits (0-100), keyword rankings with who's advertising, and daily Competitor Watch emails when a rival's price, stock, rank or complaints change. 12 Amazon marketplaces, plus Shopify store teardowns and tracking. 25 free credits. Sample: zonrival.com/sample
Unwrangle MCP — cross-retailer product + reviews data (unwrangle.com)
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.-
- AlicenseAqualityCmaintenanceReal-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
