Free competitive pricing intelligence for CPG brands across Amazon categories.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 6 of 6 tools scored.
Each tool has a clear, distinct purpose: listing categories, comparing multiple products, getting category overview/trend, single price position, and server health. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., compare_products, get_category_overview), making them predictable and easy to understand.
6 tools cover the essential workflows for CPG pricing intelligence without being excessive or insufficient, fitting well within the ideal 3-15 range.
The set covers core operations: category discovery, overview, trends, single and multi-product price analysis, and health check. Minor gaps like historical trend data or product detail retrieval exist but don't hinder primary use cases.
compare_productsCompare Multiple ProductsACompare 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.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| products | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful context about return fields and input constraints (e.g., 3-20 items useful range), but does not disclose additional behavioral traits like rate limits or pagination.
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 well-structured with a clear purpose sentence, usage context, and sections for returns and arguments. It is somewhat lengthy but every section adds necessary detail, and the formatting makes it easy to scan.
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?
With no output schema, the description correctly explains return values. It covers purpose, usage, arguments, and returns, making it sufficient for a simple read-only tool. It could be improved by referencing sibling tools for alternative scenarios, but overall it is complete.
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 coverage is 0%, so the description carries the full burden. It provides detailed semantics for both parameters: products as list of dicts with 'name' and 'price' (number in dollars), minimum 1 item and useful range; category with exact allowed values and case-insensitivity. This fully compensates for the bare 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 first sentence clearly states the tool compares multiple product prices against Amazon CPG category peers. The description is specific but does not explicitly differentiate from sibling tools like get_price_position or get_category_overview, though the comparison aspect is distinct.
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 includes a clear 'Use when' section with concrete examples (stack-ranking SKUs, flagging underpriced products, building price-audit tables). It provides context for when to use the tool but does not mention alternatives or exclusions relative to 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_overviewGet Category Pricing OverviewAReturn 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.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral details beyond that: price tiers are rounded to nearest $0.50 'for abstraction', product_count is bucketed, and it lists the exact return fields. This gives the agent a solid understanding of what to expect without contradicting the annotations.
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 well-structured: purpose first, then usage scenarios, then a clear 'Returns' list, then 'Args.' Every sentence adds value. Despite moderate length, there is no redundancy or filler.
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 single-parameter read-only tool, the description is complete. It states the output fields, the input constraints, and the intended business context. No output schema exists, but the listed return fields suffice for the agent to know what to expect.
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 coverage is 0%, so the description carries full responsibility for the single parameter. It compensates excellently by listing the exact allowed category names (Grocery & Gourmet Food, Health & Beauty, Household, Pet Supplies) and noting case-insensitivity. This is more than sufficient for correct invocation.
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 opens with a specific verb and resource: 'Return pricing-tier breakdown and category stats for an Amazon CPG category.' This clearly distinguishes it from sibling tools like get_category_trend (trend analysis) or compare_products (cross-product comparison).
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 'Use when' section provides concrete scenarios (shelf sizing, SKU entry tier, pricing benchmark, buyer meeting prep) that clarify when to invoke this tool. It does not explicitly mention alternatives or exclusions, so it falls short of a 5, but the context is clear and actionable.
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 TrendAReport 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.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint/destructiveHint annotations by detailing the output fields (trend_direction, trend_window, confidence, etc.) and the requirement for an exact category name from a predefined list. It also notes the possibility of 'Insufficient Data,' which is important behavioral context.
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 well-structured with a one-sentence summary, a use-case paragraph, a Returns block, and an Args block. It is concise without being terse, and every section adds value.
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 parameter and no output schema, the description covers the necessary semantics: input constraints, output fields, and the fixed 30-day window. It anticipates confusion by offering resolved category name and confidence note, making it complete for the intended use.
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 input schema has 0% description coverage, but the description fully specifies the 'category' parameter by enumerating the allowed values (Grocery & Gourmet Food, Health & Beauty, Household, Pet Supplies) and noting case-insensitivity and exact-match requirement. This compensates entirely for the missing schema description.
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 opens with 'Report the 30-day Amazon price-trend direction for a CPG category,' specifying a clear verb, resource, and timeframe. This distinguishes it from sibling tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('Use when a pricing ops lead asks whether category pricing is rising, stable, or falling') with concrete examples such as promo calendar setting and wholesale pricing decisions. However, it does not mention alternative tools or when not to use this tool.
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 PositionAPercentile-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 (provenance note).
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.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | ||
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about single-product scope and the price_index_label being a ratio vs. category median, but doesn't disclose additional behavioral traits like rate limits, error handling, or whether the ranking is based on a cached snapshot. With annotation coverage, a 3 is appropriate.
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 well-structured with 'Returns:' and 'Args:' sections, front-loading the core purpose. It is slightly verbose with multiple usage examples and qualifies as a 'sanity-check' alongside 'auditing', but every sentence serves a purpose. The organization aids comprehension without being excessively wordy.
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?
With no output schema, the description enumerates all six return fields (percentile_rank, price_index_label, position, category, last_refreshed, cta) and explains their nature. It also covers parameter constraints and provides usage context. For a tool of this complexity, the description is complete and well-rounded.
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 descriptions are absent (0% coverage), so the description fully compensates. It specifies price must be >0 and ≤10000, gives an example (4.99), lists exact category values (Grocery & Gourmet Food, Health & Beauty, Household, Pet Supplies), notes case-insensitivity, and instructs calling list_categories first. This adds substantial semantic value beyond the bare schema types.
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 opens with a specific verb+resource+scope: 'Percentile-rank a single product price against tracked Amazon competitors in a CPG category.' This clearly distinguishes it from sibling tools like compare_products (then product comparison) and get_category_overview (category-level aggregation). The title 'Check Competitive Price Position' reinforces the purpose.
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?
Provides explicit usage scenarios ('checking whether a $4.99 granola is competitively positioned', 'auditing whether a retail MSRP is reasonable ... before a buyer meeting', 'sanity-checking a wholesale-to-retail markup') and advises calling list_categories first to confirm category names. It doesn't name specific alternative tools, but the context is clear enough that an agent would know when to use this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList Available CategoriesAList 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so additions like 'Lightweight; safe to call' reinforce safety. The description goes further by disclosing the return format ('categories (list of {name, product_count, trend_direction, last_refreshed})') and noting that it returns exact category names expected by other tools. This is meaningful behavioral context beyond the annotations.
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?
Every sentence adds value: a concise purpose statement, clear usage instruction, structured return description, and coverage note. It is well-organized with line breaks and no redundant verbiage.
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 listing tool with no output schema, the description is complete. It explains what is returned, which categories are covered, and its role in the workflow. The annotations cover safety, and the description fills the remaining context.
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 the baseline is 4 per the rubric. The description adds relevant context about the tool's coverage area (Grocery & Gourmet Food, Health & Beauty, etc.) and return fields, though no parameter-level semantics are 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 ('List') with a clear resource ('Amazon CPG categories') and adds distinguishing details ('current product counts and trend direction'). It also positions itself as the entry point for pricing-analysis workflows, clearly differentiating it from sibling tools like get_category_overview and get_category_trend.
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 explicitly states when to use the tool ('Use as the first call in any pricing-analysis workflow') and provides context ('safe to call before any category-specific query'), implying it should precede other category-specific tools. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
server_statusCheck Server StatusAReport 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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds substantial behavioral detail: it explains the staleness threshold, the degraded/healthy status logic, and the exact fields returned. This goes well beyond the annotations and gives the agent a precise expectation of behavior.
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 well-organized with a clear opening sentence, a direct usage note, and a bulleted return list. Every section adds value; there is no fluff or redundancy. It is appropriately sized given the absence of an output schema.
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?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what an agent needs: purpose, optimal use case, timeout threshold, status logic, and the complete set of returned fields. Nothing essential is missing.
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 the description carries no parameter burden. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output rather than input, adding no unnecessary parameter explanations.
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 opens with a clear action and subject: 'Report PricePilot server health, data freshness, and degraded-state reason.' This distinguishes server_status from its siblings (e.g., list_categories, compare_products), making its purpose unmistakable.
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 explicitly states when to use the tool: 'Use to check whether category seeding is current (staleness threshold is 10 days) before trusting downstream tool output.' This provides clear context, though it does not mention when not to use it or explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.
