Price comparison across partner retailers. Read-only, 90-day history, disclosed affiliate.
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.3/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: compare_offers is for a specific product's offers across retailers, compare_products for side-by-side comparison of multiple products, find_best_deal for a single recommendation, search_products for keyword search, semantic_search for natural language search, and get_categories/get_product for navigation and details. The overlap between search_products and semantic_search is explicitly resolved by their descriptions.
Most tool names follow a consistent verb_noun pattern (compare_offers, compare_products, get_categories, get_product, search_products). find_best_deal is a slight deviation with an adjective in the middle, and semantic_search does not strictly follow verb_noun (it could be search_semantic). However, the naming is still readable and predictable overall.
The server provides 7 tools, which is well within the ideal 3-15 range. Each tool covers a necessary function for a price comparison service: searching, browsing categories, getting details, comparing, and finding deals. No tool feels redundant or missing.
The tool set covers the core price comparison workflow end-to-end: users can search (keyword or natural language), browse categories, retrieve product details, compare products, find the best deal, and get multi-retailer offers for a specific product. This is a complete lifecycle for the domain, with no obvious missing operations.
compare_offersAExact multi-retailer offers for one product from WEM's own catalogue, cheapest first, with a 90-day price-history low. Identity is resolved by barcode or catalogue slug — no text matching — so every offer IS the product, and the lookup spends no retailer API quota. Use this FIRST when you have a barcode (EAN/UPC/GTIN) or a wem3.ai/pl/{slug} URL; fall back to search_products when the product is not in the catalogue yet.
| Name | Required | Description | Default |
|---|---|---|---|
| gtin | No | Product barcode: EAN-13, UPC-A, EAN-8 or GTIN-14. Preferred key. | |
| slug | No | WEM canonical product slug, as in wem3.ai/pl/{slug}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses exact-match guarantees ('no text matching — so every offer IS the product'), that no retailer API quota is consumed, and the ordering behavior (cheapest first). This adds meaningful context beyond annotations, though it does not detail return structure or error cases.
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 front-load the core purpose, then add differentiating details and usage guidance. Each sentence contributes valuable information without redundancy or fluff.
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, matching logic, API quota impact, ordering, price history, and usage guidance for two optional parameters. However, since there is no output schema, the description does not fully explain the return structure or error behavior, which leaves a 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?
The input schema already fully documents both gtin and slug with detailed descriptions. The description reinforces the barcode-or-slug identity mechanism but does not add significant new parameter-level meaning beyond what the schema already 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?
Clearly states it returns exact multi-retailer offers for a single product, sorted cheapest first, with a 90-day price-history low. It distinguishes itself from siblings by specifying exact identity via barcode or slug, not text matching.
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 instructs to use this tool FIRST when a barcode or wem3.ai/pl/{slug} URL is available, and to fall back to search_products when the product is not in the catalogue. This provides clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_productsACompare 2-5 products side by side. Returns a structured comparison of price, rating, shipping, and key features. Use when the user is deciding between options.
| Name | Required | Description | Default |
|---|---|---|---|
| products | Yes | List of products to compare (2-5 items) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds that it returns a structured comparison and specifies which fields are compared, which is useful context beyond the annotations. However, it does not disclose any potential side effects, data freshness, or external dependencies. With annotations covering the safety profile, this is adequate but not exceptional.
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 two sentences, front-loaded with the core action and followed by return details and usage guidance. Every sentence earns its place with no redundant 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?
This is a simple tool with one parameter and no output schema. The description explains the return value (structured comparison) and specifies the compared fields, which is sufficient. Annotations cover safety and open-world behavior. No additional context is missing for effective selection and invocation.
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% (the products array is fully described with min/max items and item structure). The description adds the comparison attributes (price, rating, shipping, key features), which helps interpret what 'compare' means, but it does not add detail about individual parameter semantics beyond what the schema already provides. Baseline 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's function: comparing 2-5 products side by side, with specific attributes (price, rating, shipping, key features). It identifies the resource (products) and the action (compare). However, it does not explicitly differentiate from sibling tool compare_offers, which likely overlaps in 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?
The description provides a usage context: 'Use when the user is deciding between options.' This gives clear guidance on when to invoke the tool. It does not mention alternatives or when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_dealAFind the single best product matching constraints. Ranks by value (price vs rating vs shipping). Use when the user wants a recommendation rather than a list. Candidates are filtered to plausible matches for the query first, so a cheap accessory cannot be returned as the cheapest way to buy the product itself; recommendation may be null with a reason when nothing matched confidently, and that must be reported as "no confident match" rather than softened into a suggestion. recommendation.verified marks an offer whose identity WEM has resolved rather than inferred.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for | |
| max_price | No | Budget cap (GBP) | |
| priorities | No | What matters most (in order of importance) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, open-world, and non-destructive. The description adds important behavioral nuances: candidate filtering to avoid accessory mismatches, the null outcome with a required 'no confident match' phrasing, and the verified flag's meaning. This exceeds annotation coverage.
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 front-loaded with purpose, then usage, then edge-case behaviors. Every sentence earns its place without fluff, despite moderate length.
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 decision-making complexity, the description covers the essential behavioral contract: single recommendation, value ranking, filtering, null outcome handling, and verification semantics. No output schema exists, but the description compensates with the `recommendation` and `verified` 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?
All three parameters have schema descriptions, and the description does not add further parameter-level detail. It references 'price vs rating vs shipping' but the schema already enumerates priorities. Therefore the baseline of 3 applies.
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 phrase 'Find the single best product' and clarifies the output is a recommendation, distinguishing it from sibling search/list tools. The ranking and null-with-reason behavior further specify scope.
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 states 'Use when the user wants a recommendation rather than a list,' setting a clear usage boundary. It also explains the candidate filtering rationale, which aids in deciding when to invoke this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_categoriesAGet available product categories and the approximate price range for each. Use to guide the user when their request is vague.
| 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 the safety profile is known. The description adds context like 'approximate' price ranges, but does not describe pagination or error behavior, which is acceptable given 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?
Two short sentences, front-loaded with the primary action and output. Every word earns its place, and the usage hint is integrated without 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?
Given the simple nature of the tool (no params, no output schema), the description sufficiently explains the return value (approximate price ranges) and the intended use case. It is complete for a straightforward read-only category listing.
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, and the schema is empty thus covering 100% of parameters. Per rubric, 0 params gets a baseline of 4. The description adds no parameter details, but none 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 clearly states the specific action: getting available product categories and their approximate price ranges. It distinguishes from sibling tools like search or compare by focusing on category listing.
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 states when to use the tool: 'Use to guide the user when their request is vague.' This provides a clear context, though it does not mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productAGet full details for a specific product by its provider and ID. Use after search results to get more info before recommending.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider name (e.g. "ebay", "awin") | |
| product_id | Yes | Product ID from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and non-destructive, so the safety profile is covered. The description adds the purpose but not concrete behavioral details such as what 'full details' includes or how missing products are handled. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and then the usage context. Every word earns its place; 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 simple read-only lookup with two well-documented parameters, the description is adequate. It explains when to use it and what it does. However, without an output schema, 'full details' remains somewhat vague, so it doesn't fully describe the return value.
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 provides 100% coverage: both 'provider' and 'product_id' have descriptive explanations. The description adds no additional parameter semantics beyond repeating 'provider and ID', so the baseline 3 applies.
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 function: 'Get full details for a specific product by its provider and ID.' It uses a specific verb and resource, and the phrase 'Use after search results' differentiates it from sibling search/list tools.
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 gives explicit usage context: 'Use after search results to get more info before recommending.' This clearly indicates when to use the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsASearch for products across all connected marketplaces (eBay, Amazon, Awin merchants, etc.) using keywords. Returns a list of matching products with prices, images, and affiliate links. Best for specific keyword searches like "airpods pro" or "nike running shoes". When the query names a product in WEM's own catalogue, a catalogMatch block is also returned: its offers are identity-resolved rather than title-matched, so prefer them and cite its prices over anything in products. Weak matches are withheld and tallied by reason in filtered — report that count rather than implying the search was exhaustive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 10, max 30) | |
| query | Yes | Search keywords | |
| sort_by | No | Sort order for results | |
| category | No | Filter by category (electronics, fashion, beauty, home, sports, collectibles) | |
| max_price | No | Maximum price filter (GBP) | |
| min_price | No | Minimum price filter (GBP) | |
| providers | No | Limit to specific providers (e.g. ["ebay", "awin"]). Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description explains the returned product list contents, the special catalogMatch block with identity-resolved offers, and the filtered tally of weak matches with an instruction to report that count. This adds meaningful behavioral context for result interpretation.
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 around 100 words, but each sentence contributes essential information—purpose, returns, usage scenario, special handling, and filtered reporting. It is well-structured and 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?
Given no output schema, the description adequately covers the return structure and semantics, including the optional catalogMatch block and filtered object. It also provides prescriptive guidance on how to present results, making it complete for an autonomous agent.
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?
All 7 parameters have schema descriptions (100% coverage), so the description need not enumerate parameter semantics. It reinforces the 'query' parameter with examples but adds no further detail 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 explicitly states 'Search for products across all connected marketplaces' with a specific verb and resource, and details the return format and special behaviors (catalogMatch, filtered). This clearly distinguishes it from sibling tools like compare_offers or get_product.
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?
It provides clear usage context: 'Best for specific keyword searches' with concrete examples, indicating when to invoke it. However, it does not explicitly name alternatives or state exclusion criteria, so it lacks the full when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_searchASearch for products using natural language descriptions. Uses AI embeddings for semantic understanding — handles vague requests like "comfortable shoes for standing all day" or "gift for a 10 year old who likes science". Falls back to keyword search when vector data is unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 20) | |
| category | No | Optional category filter | |
| max_price | No | Maximum price (GBP) | |
| min_price | No | Minimum price (GBP) | |
| description | Yes | Natural language description of what the user is looking for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds valuable behavioral context: it uses AI embeddings, handles vague requests, and falls back to keyword search when vector data is unavailable. This goes beyond annotations, though it does not describe return format or potential rate limits.
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 two sentences, front-loaded with the core purpose, and includes concrete examples in the second sentence. Every word earns its place—no fluff or irrelevant details. It is appropriately sized for the tool's complexity.
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 has 5 parameters, no output schema, and good annotations, the description is reasonably complete. It covers the core behavior, fallback, and example usage. It doesn't mention pagination or return format, but for a search tool with read-only semantics, this is not critical. The description sufficiently supports tool selection and invocation.
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 baseline is 3. The description does not add substantial meaning beyond the schema. It mentions natural language handling and fallback, but the parameters (limit, category, prices) are not elaborated beyond their schema descriptions. The tool description reinforces the 'description' parameter's purpose but doesn't introduce new semantics.
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: 'Search for products using natural language descriptions.' It specifies the resource (products) and the mechanism (semantic embeddings), and distinguishes it from siblings like search_products by emphasizing natural language and vague-request handling. The fallback to keyword search also clarifies its scope.
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 context: it's for natural language queries and vague requests, providing examples. It also notes a fallback to keyword search when vector data is unavailable, indicating a clear scenario. However, it does not explicitly name alternative tools like search_products for exact-match queries, so it lacks explicit exclusion guidance.
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!
