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
PricePilot MCP 서버
다채널 CPG 브랜드를 위한 무료 Amazon 가격 인텔리전스로, Model Context Protocol 서버로 제공됩니다. 식료품, 건강 및 미용, 가정용품, 반려동물 용품 전반에 걸쳐 매주 수행되는 Buy Box 스캔을 기반으로 6가지 읽기 전용 도구를 제공합니다.
NielsenIQ / SPINS 신디케이트 카테고리 데이터에 대한 무료 대안으로, 모든 MCP 클라이언트(Claude Desktop, Claude.ai, Cursor, Continue, 에이전트 프레임워크)에서 액세스할 수 있습니다.
기능
가격과 카테고리가 주어지면 서버는 다음과 같은 질문에 답변합니다:
이 Amazon 가격은 추적 중인 100개 이상의 경쟁사와 비교했을 때 어느 위치에 있는가?
지난 30일 동안 해당 카테고리는 상승세, 안정세, 하락세 중 어디에 속하는가?
예산/중급/프리미엄 가격대는 어떻게 형성되어 있는가?
이 N개의 SKU는 선반 위에서 서로 어떻게 비교되는가?
서버는 백분위수 순위, 가격 지수, 추세 방향, 등급 대역과 같은 파생 통계만 반환합니다. 원본 경쟁사 가격은 노출되지 않습니다.
Related MCP server: PricePilot for Claude Desktop
연결
호스팅 엔드포인트 (설치 불필요)
{
"mcpServers": {
"pricepilot": {
"url": "https://pricepilot-mcp.onrender.com/mcp"
}
}
}API 키가 필요 없습니다. 분당 60회, 일일 1000회 요청으로 제한됩니다.
Claude Desktop (원클릭, 권장)
https://github.com/vantage-meridian-group/pricepilot-mcpb/releases/latest 에서 공식 .mcpb 확장자를 사용하여 Claude Desktop으로 드래그 앤 드롭하세요.
로컬 stdio (개발용)
pip install -e .
DATABASE_URL=postgresql://... python -m pricepilot_mcp도구
도구 | 반환 내용 |
| 단일 가격에 대한 백분위수 순위, 가격 지수, 위치(가치/동등/프리미엄) |
| 표본 크기를 포함한 30일 추세 방향(상승/안정/하락) |
| 등급별 분석(예산/중급/프리미엄 대역) 및 중앙값 |
| 카테고리 대비 제품 목록에 대한 SKU별 스택 순위 |
| 제품 수와 추세가 포함된 사용 가능한 카테고리 — 가장 먼저 호출 |
| 상태 및 데이터 신선도(시드 데이터가 10일 이상 경과하면 저하됨) |
모든 도구는 readOnlyHint=true, destructiveHint=false, openWorldHint=false로 설정되어 있습니다.
카테고리
Amazon Buy Box 스캔을 통해 매주 새로 고침:
식료품 및 미식 식품
건강 및 미용
가정용품
반려동물 용품
아키텍처
Streamable HTTP 및 stdio 전송을 사용하는 FastMCP
벤치마크 스냅샷을 위한 SQLAlchemy + PostgreSQL(서버 관점에서 읽기 전용)
일일 및 분당 버킷을 통한 소비자별 속도 제한
Dockerfile 포함; 모든 컨테이너 호스트에 배포 가능(프로덕션은 Render에서 실행)
Docker로 실행
docker build -t pricepilot-mcp .
docker run -p 8081:8081 -e DATABASE_URL=postgresql://... pricepilot-mcp운영자 참고 사항
MCP 서버는 PricePilot의 무료 카테고리 수준 인터페이스입니다. SKU별 가격 책정 권장 사항(R1 가격 조정은 라이브 상태이며, R2 / R3 / R5는 2분기까지 확장 예정)은 유료 플랫폼(https://app.pricepilot.vantagemeridiangroup.com)을 통해 제공됩니다.
라이선스
MIT — 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
