shoporacle
Server Details
E-Commerce Intelligence MCP — 11 tools: price comparison, stock, reviews. 18 countries.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ToolOracle/shoporacle
- GitHub Stars
- 0
- Server Listing
- ShopOracle
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.
Tool Definition Quality
Average 3.8/5 across 11 of 11 tools scored.
Each tool targets a distinct aspect of product research (search, comparison, history, alerts, reviews, stock, etc.) with no overlapping purposes. Descriptions clearly differentiate similar tools like compare_prices vs competitor_pricing.
Most tool names use noun_noun pattern (e.g., price_history, product_search), but a few use verb_noun (compare_prices, track_price). The pattern is mostly consistent, with minor deviations that don't cause confusion.
The 11 tools cover a comprehensive range of e-commerce market research functionalities without being overwhelming. Each tool serves a clear purpose, and the count feels well-scoped for the server's domain.
The tool set covers the full lifecycle of product research: search, compare, track history, set alerts, view reviews, check stock, and analyze market position. No obvious gaps for the intended use case of price monitoring and market analysis.
Available Tools
11 toolsbestseller_listAInspect
Get top-selling products in a category from Amazon or Google Shopping. Returns ranked list with prices, ratings, and reviews. Great for market research.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (1-20, default: 10) | |
| source | No | Source: 'amazon' (default), 'google', 'all' | |
| country | No | Country code (default: DE) | |
| category | No | Product category (e.g. 'headphones', 'laptops', 'gaming mice') (required) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses returning a ranked list with prices, ratings, and reviews but omits details on read-only nature, rate limits, or error handling.
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?
Two concise sentences with no fluff. Front-loaded with core purpose and output details.
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?
Covers main purpose and output for a simple tool, but lacks required parameter specification (description says required for category but schema omits required list) and no output schema details.
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 covers 100% of parameters with descriptions. The description adds context about output but not parameter-specific semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves top-selling products from specified sources and returns a ranked list with prices, ratings, and reviews. This distinguishes it from sibling tools like compare_prices or product_search which have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for market research but lacks explicit guidance on when to use this tool versus alternatives. No mention of when not to use or specific competitor tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_pricesAInspect
Compare prices for the same product across Google Shopping, Amazon, and eBay. Returns best price, worst price, potential savings, and a ranked price list.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per source (1-5, default: 3) | |
| query | No | Product to compare prices for (required) | |
| country | No | Country code (default: DE) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as whether results are real-time, any rate limits, or authentication requirements. Minimal transparency beyond basic function.
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?
Two sentences, front-loaded with action and sources, followed by return specifics. No unnecessary words.
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?
No output schema, but description adequately explains return values (best/worst price, savings, ranked list). Could mention currency or freshness of data, but sufficiently complete for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions (limit, query, country). Description adds return structure details but no additional parameter semantics beyond 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?
Description clearly states it compares prices across three specific retailers (Google Shopping, Amazon, eBay) and returns best/worst price, savings, and ranked list. This distinguishes it from sibling tools like competitor_pricing or price_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives. Implied cross-shopping use case, but no exclusions or context for choosing over siblings like bestseller_list or track_price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
competitor_pricingAInspect
Compare pricing of two specific products or brands side by side across all marketplaces. Shows which is cheaper, price difference, and offers from each source.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country code (default: DE) | |
| product_a | No | First product name or brand (required) | |
| product_b | No | Second product name or brand (required) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that it shows which is cheaper, price difference, and offers, but lacks details on error handling, permissions, or missing products.
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?
Two sentences, front-loaded with the core action, no redundant words.
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 no annotations or output schema, the description covers purpose and high-level behavior adequately for a simple comparison tool. Could mention return format but not essential.
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 100% (all parameters have descriptions). The description does not add new semantic meaning beyond the schema's 'required' hints and parameter roles.
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 ('compare') and resource ('pricing of two specific products or brands'), clearly distinguishing it from siblings like 'compare_prices' and 'price_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for side-by-side comparison but does not provide explicit when-not or alternatives. No guidance on when to use this vs. 'compare_prices' or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkAInspect
Server health, API connectivity status, supported sources and countries, tool list, pricing info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lists returned information types, but doesn't disclose if it is read-only, side effects, authentication needs, or rate limits. Without annotations, this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise list of items; no wasted words. Could be slightly more structured (e.g., bullet points), but effective.
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 no parameters and no output schema, the description adequately covers what the tool provides for a health check. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4. Description adds value by enumerating what the zero-parameter request returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: server health, API connectivity, supported sources/countries, tool list, and pricing info. It distinguishes itself from sibling tools which focus on specific data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for checking API status and available features. No explicit alternatives or exclusions given, but the context makes its purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_positionAInspect
Analyze where a product ranks in its category — price positioning (budget/mid/premium/luxury), rating comparison, cheaper and pricier alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Product to analyze (required) | |
| country | No | Country code (default: DE) | |
| category | No | Category to compare against (auto-derived if not set) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool analyzes and outputs price positioning, rating comparison, and alternatives, which implies read-only behavior. However, it does not explicitly state safety, authentication needs, or potential side effects.
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?
Single sentence of 20 words, well front-loaded with core action. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description sufficiently explains return values (price bracket, rating comparison, alternatives). For a simple analysis tool with 3 parameters, it covers the essential behavioral information.
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 100% with clear parameter descriptions. The tool description adds context on how parameters are used (e.g., 'category auto-derived') but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes product market position in terms of price, rating, and alternatives. It uses specific terms like 'budget/mid/premium/luxury' and 'cheaper and pricier alternatives,' which distinguishes it from siblings like 'bestseller_list' or 'compare_prices.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for market positioning analysis but does not explicitly state when to use it over siblings. It lacks 'when not to use' guidance or alternative tool referrals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_alertAInspect
Set, check, list, or delete price alerts. Get notified when a product drops below your target price. Actions: 'set' (create alert), 'check' (check current price vs target), 'list' (show all alerts), 'delete' (remove alert).
| Name | Required | Description | Default |
|---|---|---|---|
| asin | No | Amazon ASIN for exact product | |
| query | No | Product search query | |
| action | No | Action: 'check' (default), 'set', 'list', 'delete' | |
| country | No | Country code (default: DE) | |
| target_price | No | Target price to alert on (required for action='set') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists actions but omits behavioral details such as whether setting an alert overwrites existing ones, if delete is irreversible, or what happens on errors.
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?
Description is concise with two sentences, front-loading the primary actions and purpose. Every sentence adds value; no redundant or filler content.
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 5 parameters, complex action-based behavior, and no output schema, the description provides adequate but minimal completeness. It lacks details on output format, error handling, or constraints on ASIN vs query for certain actions.
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 covers all 5 parameters with descriptions, so baseline is 3. Description adds context (action defaults to 'check', target_price required for 'set') but does not significantly extend beyond 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?
Description clearly states the tool manages price alerts with specific actions (set, check, list, delete) and explains the notification purpose. However, it does not differentiate from sibling 'track_price' which may have overlapping functionality.
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?
Usage is implied through actions (e.g., use 'set' to create an alert), but no explicit guidance on when to use this tool versus alternatives like 'track_price', nor any conditions for avoiding use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_historyAInspect
View stored price history for a product with trend analysis (rising/falling/stable). Tracks min, max, average prices over time. Call track_price first to build up history data.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | No | Amazon ASIN for exact product | |
| limit | No | Max history entries to return (default: 50) | |
| query | No | Product search query |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions trend analysis and tracked metrics but does not specify behavior when no history exists, error handling, or that limit applies to history entries. Partially transparent.
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?
Three sentences, no redundancy. Purpose stated first, followed by useful context and prerequisite hint. Efficient.
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?
No output schema, yet description omits return format (e.g., JSON structure, array of price entries). With 10 sibling tools, only references 'track_price'. Agent lacks full context to invoke correctly.
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 100% and descriptions already explain asin and query. Description adds minimal value beyond schema (e.g., 'exact product' for asin). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: viewing stored price history with trend analysis, tracking min/max/average prices. It distinguishes from siblings like 'track_price' which is for initiating tracking.
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?
Explicitly advises calling 'track_price' first to build history data, guiding prerequisite usage. Does not explicitly state when not to use (e.g., when no history exists) but sufficiently differentiates from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
product_searchAInspect
Search for products across Google Shopping, Amazon, and eBay. Returns prices, ratings, links. Supports country-specific results (DE, US, UK, etc.) and sorting by price or reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per source (1-10, default: 5) | |
| query | No | Product name or search terms (required) | |
| country | No | Country code: DE, US, UK, FR, etc. (default: DE) | |
| sort_by | No | Sort: 'relevance' (default), 'price_low', 'price_high', 'review' | |
| sources | No | Which marketplaces: 'all' (default), 'google', 'amazon', 'ebay' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions return fields (prices, ratings, links) and capabilities (country-specific, sorting) but omits behavioral details like rate limits, latencies, or read-only nature.
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?
Two sentences, no fluff, front-loaded with key action and scope. Every word contributes 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?
Given 5 parameters, no output schema, and 11 sibling tools, the description adequately covers purpose, supported marketplaces, and key options. Brief mention of return values compensates for lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds minimal new meaning beyond the schema. It reiterates country-support and sorting, which are already in parameter descriptions.
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?
Description clearly states 'Search for products across Google Shopping, Amazon, and eBay' with verb+resource+scope. It uniquely identifies the tool's function among siblings like bestseller_list or compare_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for multi-source product search but does not explicitly specify when to use this tool versus alternatives like compare_prices or price_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_summaryAInspect
Get review ratings, score breakdown, and top customer reviews for a product from Amazon. Useful for purchase decisions and product quality assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | No | Amazon ASIN for exact product | |
| query | No | Product search query | |
| country | No | Country code (default: DE) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does not mention authentication requirements, rate limits, or what happens when a product is not found. It only states the basic function without 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?
Two efficient sentences: first defines the action and scope, second provides the use case. No wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should detail return values. It mentions 'review ratings, score breakdown, and top customer reviews' but does not clarify output format or how parameters like 'asin' and 'query' interact. Moderately complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description's role is reduced. It reinforces that the tool retrieves Amazon product reviews but adds no new details on parameter usage or format beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resources: review ratings, score breakdown, and top customer reviews. It specifies the source (Amazon) and distinguishes from sibling tools that focus on pricing, competition, or product search.
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?
Description provides a use case ('Useful for purchase decisions and product quality assessment') but does not explicitly state when not to use or mention alternative tools among the siblings. Guidance is implied but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stock_monitorAInspect
Check product availability and stock status across Amazon and Google Shopping. Shows in-stock/out-of-stock, prices, delivery info, and sellers.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | No | Amazon ASIN for exact product | |
| query | No | Product search query | |
| country | No | Country code (default: DE) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states what information is shown but lacks details on error handling, required permissions, rate limits, or whether the tool has side effects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and key details. Every word is informative and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters, no output schema, and no annotations, the description is adequate. It explains the overall functionality and main outputs, but lacks guidance on parameter interplay (e.g., using asin vs query) and precise return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters already described. The tool description adds no additional semantic context for the parameters beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks product availability and stock status across Amazon and Google Shopping, showing specific details like stock status, prices, delivery info, and sellers. It distinguishes itself from sibling tools like product_search and compare_prices, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking stock and availability but does not explicitly guide when to use this tool versus alternatives like product_search or price_alert. No exclusions or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
track_priceAInspect
Track the current price of a product and build price history over time. Supply an Amazon ASIN for exact product tracking, or a search query for best-price discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | No | Amazon ASIN for exact product tracking | |
| query | No | Product search query | |
| country | No | Country code (default: DE) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses the tool's action (track price, build history) and parameter usage, but does not mention authentication, rate limits, or side effects like storage for history. Adequate but not comprehensive.
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?
Two sentences, no filler, front-loaded with action and guidance. Every sentence adds essential information.
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?
Covers purpose, parameter usage, and default. Lacks detail on output format or how history is built, but tool is simple and parameters are well-documented. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the trade-off between ASIN (exact) and query (best-price discovery), which is not in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tracks current price and builds history over time, with specific guidance on using ASIN for exact tracking or query for best-price discovery. It distinguishes from sibling tools like price_history (which may only retrieve history) and compare_prices by combining tracking and history building.
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?
Explicitly advises when to use ASIN vs query, and notes default country. However, it does not provide explicit when-not-to-use scenarios or compare with sibling tools beyond implicit purpose.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.