idealo MCP Serverofficial
A
licenseNot graded
qualityF
maintenanceEnables product search, price comparison, and price history analysis across 6 European marketplaces (DE, AT, GB, FR, IT, ES).
15
MIT
Bikefuchs — Bike Parts Price Comparison
Server Details
Price comparison & cart optimizer for bike parts across German & Austrian shops
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- bikefuchs/bikefuchs-mcp-stub
- GitHub Stars
- 0
- Server Listing
- bikefuchs-mcp-stub
Available Tools
7 toolsfind_alternatives_for_productFind Alternative ShopsARead-onlyIdempotentInspect
Given a product's EAN barcode, return every shop that carries it with prices and availability, sorted cheapest-first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ean | Yes | EAN barcode (8–14 digits, e.g. '4524667749493') | |
| country | No | Country for pricing (DE or AT, default DE) | DE |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ean | Yes | |
| alternatives | Yes | |
| product_name | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that results are 'sorted cheapest-first' and includes 'prices and availability', which provides useful context beyond annotations. However, it does not detail error handling, pagination, or limitations, keeping it at a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and context. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema present, the description does not need to explain return values. It covers purpose, input format (EAN), and behavioral ordering (cheapest-first). The tool is simple with only 2 params, and the description covers the essential aspects adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for both parameters. The description adds that the EAN is a barcode and country is for pricing, but these are restatements of schema. No additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (return), resource (shops carrying a product), and sorting (cheapest-first). It distinguishes from siblings like get_best_price, which likely returns only the best price, and search_product, which may handle non-EAN queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the trigger condition: 'Given a product's EAN barcode.' It implies when to use by specifying the required input. However, it does not mention when not to use or provide alternatives, leaving some room for misinterpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_best_priceGet Best Price by EANARead-onlyIdempotentInspect
Look up a single product by its EAN barcode and return the price at every shop that carries it, sorted cheapest-first, with stock status and direct purchase links.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ean | Yes | EAN barcode (8–14 digits, e.g. '4524667749493') | |
| country | No | Country for pricing (DE or AT, default DE) | DE |
| reference_shop | No | Shop id or display name to compare against. When set, the response states how much cheaper the cheapest shop is vs. this shop. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ean | Yes | |
| prices | Yes | |
| next_step | No | |
| product_name | Yes | |
| cheapest_shop | Yes | |
| cheapest_price | Yes | |
| reference_comparison | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context (sorted cheapest-first, stock status, links) beyond annotations. No contradictions. Slightly lower due to lack of detail on rate limits or other constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 18 words, front-loaded with action and resource, then efficiently lists key output details (sorted, stock, links). No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, input (by EAN), output (prices, stock, links, sorted), and is complete given the presence of output schema and annotations. No missing information for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for each parameter (ean pattern, country enum, reference_shop). The tool description does not add new parameter-specific information, so it does not exceed the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Look up' and resource 'single product by its EAN barcode', and clearly states the output format (prices sorted cheapest-first, stock status, purchase links). This distinguishes it from sibling tools like search_product (fuzzy search) and get_shipping_breakdown (shipping details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly implies usage for looking up a specific product by EAN, which distinguishes it from search-oriented siblings. However, it does not explicitly state when not to use it or mention alternatives, leaving room for slight ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shipping_breakdownGet Shipping CostARead-onlyIdempotentInspect
Return the exact shipping cost for a specific shop, country, and cart value, including all shipping tiers and how much more is needed to reach the next free-shipping threshold.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| shop | Yes | Shop name or ID (e.g. 'rosebikes', 'boc24', 'bike24', 'fahrradteile', 'Rose Bikes') | |
| country | Yes | Country (DE or AT) | |
| cart_value | Yes | Total cart value in EUR (e.g. 49.99) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| shop | Yes | |
| country | Yes | |
| currency | Yes | |
| cart_value | Yes | |
| shipping_cost | Yes | |
| free_shipping_threshold | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, ensuring safety. The description adds value by specifying the output includes shipping tiers and next free-shipping threshold, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loaded with the verb and resource, no wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations, the description fully covers what the agent needs to know: the parameters are clear, the return includes tiers and thresholds, and safety is assured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description does not add new parameter details beyond what the schema already provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the exact shipping cost' with specific resources (shop, country, cart value) and distinguishes from siblings by focusing on shipping breakdown, not product prices or shop info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying shipping costs but does not explicitly state when to use this tool versus alternatives like get_best_price or optimize_cart. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shop_infoGet Shop OverviewARead-onlyIdempotentInspect
Return an overview of the supported shops, including their shipping cost tiers, free-shipping thresholds, and supported countries (DE and AT).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Filter output to a specific country (optional — omit for both DE and AT) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| shops | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds value by specifying the output content (shipping tiers, thresholds, countries) and scope (optional country filter), which is beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the purpose key details without any fluff. Every word serves the goal of describing the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the high-level purpose and key parameters sufficiently. A minor gap is lack of mention of the output schema or example, but overall adequate for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the only parameter. The description reinforces that DE and AT are supported but does not add new semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an overview of supported shops, listing specific contents (shipping cost tiers, free-shipping thresholds, supported countries). This distinguishes it from sibling tools that focus on products, prices, or shipping breakdowns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to get shop overview) but does not explicitly state when not to use or how it differs from alternatives like get_shipping_breakdown or search_product. No exclusions or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
optimize_cartOptimize Shopping CartARead-onlyIdempotentInspect
Find the cheapest way to buy multiple products together: computes the optimal split across shops — which items to order from which shop — accounting for each shop's shipping costs and free-shipping thresholds, and returns the lowest achievable total including shipping. Takes an array of EAN barcodes. For accurate results, call get_best_price for each EAN first, then call optimize_cart.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| eans | Yes | Array of EAN barcodes (8–14 digit numbers as strings, e.g. '4524667749493'). NOT URLs. | |
| country | No | Country for pricing and shipping (DE or AT, default DE) | DE |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| optimization | Yes | |
| savings_info | No | |
| stale_cache_warning | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description reinforces this by describing a computation that does not modify state, and adds behavioral context (dependency on prior pricing calls). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences tightly packed with essential information: function, input, and prerequisite. No redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with annotations and schema, the description provides all necessary context: what the tool does, when to call it, and what it needs. Output schema covers return values, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minor clarification (e.g., 'NOT URLs') but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool computes the optimal split across shops to minimize total cost, including shipping. It specifies input (EAN barcodes) and clearly distinguishes from sibling tools by prescribing a prior call to get_best_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: call get_best_price for each EAN first. Suggests appropriate usage context (after pricing) but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_productResolve Product URLARead-onlyIdempotentInspect
Turn a product page URL from a supported shop into structured product data — EAN barcode, price, stock status, and a purchase link — so the EAN can then be used with get_best_price or optimize_cart. Multi-variant product families return a labeled candidate list (size/colour, price, EAN per variant): ask the user to pick a variant, then use that exact variant's EAN with the other tools.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Product page URL from a supported shop (e.g. 'https://www.rosebikes.de/p/<product-name>-<id>') | |
| country | No | Country for pricing (DE or AT, default DE) | DE |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ean | No | |
| axis | No | Variant axis of the options: 'size', 'colour', 'mixed', 'size_name' or 'name'. |
| shop | Yes | |
| brand | No | |
| price | No | |
| status | No | 'not_resolved' when the exact variant could not be determined; 'pick_variant' when labeled variant options are returned to choose from. |
| message | No | |
| options | No | Variants of ONE product. Ask the user to pick one, then use that variant's EAN. |
| resolved | No | |
| family_url | No | Branded /go/ link to the product family page so the user can pick the variant. |
| product_name | Yes | |
| affiliate_url | No | Affiliate link for this product. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond that: multi-variant families return a labeled candidate list and require the agent to ask the user for the exact variant and use that variant's EAN. This is material and not present in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the transformation and outputs are front-loaded, followed by the important variant-selection behavior and downstream tool references. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description only needs to cover the flow, and it does: supported-shop URL input, core outputs, multi-variant candidate handling, and the relationship to get_best_price and optimize_cart. No important calling decision is left unexplained for this simple two-parameter idempotent tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both url and country are already described in the schema. The description reinforces that the URL must be a product page from a supported shop and that the EAN is the key output, but it does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Turn...into'), names the resource ('a product page URL from a supported shop'), and lists concrete outputs (EAN, price, stock status, purchase link). It also distinguishes itself from siblings by framing the EAN as the input to get_best_price or optimize_cart, so an agent can tell this resolver apart from search or pricing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool: when you have a product URL and need structured data (especially an EAN) for downstream tools. It also gives workflow guidance for multi-variant products (ask the user to pick a variant). It does not explicitly say when not to use it or name alternatives such as search_product, so it stops 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.
search_productSearch Bike ProductsARead-onlyIdempotentInspect
Search for bicycle parts, components, accessories, and cycling clothing by name, brand, or model number. Returns matching products sorted cheapest-first, each with its price, stock status, EAN barcode, and a direct purchase link. Supports DE and AT pricing. If you already have a product's EAN, use get_best_price instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search keyword, min 2 chars. Multi-word queries use AND logic across product name, description, and specifications (e.g. 'shimano xt bremsbeläge') | |
| shop | No | Restrict results to a single supported shop (by id or name) | |
| country | No | Country for pricing (DE or AT, default DE) | DE |
| category | No | Filter by merchant category (partial match, e.g. 'Fahrräder' or 'Bremsen') | |
| in_stock | No | Only return in-stock products (default true) | |
| max_price | No | Upper price bound in EUR (inclusive) | |
| max_results | No | Max results (1–20, default 10) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| next_steps | No | |
| total_results | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds sorting (cheapest-first), return fields (price, stock, EAN, link), and pricing support for DE/AT, providing behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering purpose, output, and alternative. Front-loaded and no redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and output schema, description covers purpose, usage, output, and sibling tool. Lacks mention of error handling or pagination, but with max_results and schema coverage, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. Description restates some (name, brand, model, DE/AT) but adds no new semantic meaning beyond schema. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Search' and resource 'bicycle parts... by name, brand, or model number'. It also distinguishes from sibling tool get_best_price by noting alternative use when EAN is available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use search (by keyword) and when to use alternative (get_best_price with EAN). Mentions supported countries (DE/AT). Could add more exclusions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
resolve_product1 field changed- changed
Input schema / properties / url / descriptionPrevious value: -"Product page URL from a supported shop (e.g. 'https://www.rosebikes.de/p/sram-pc-951-9-fach-kette-159128')"New value: +"Product page URL from a supported shop (e.g. 'https://www.rosebikes.de/p/<product-name>-<id>')"
1 tool update
- Changed
resolve_product1 field changed- changed
Input schema / properties / url / descriptionPrevious value: -"Product page URL from a supported shop (e.g. 'https://www.bike24.de/p2462871.html')"New value: +"Product page URL from a supported shop (e.g. 'https://www.rosebikes.de/p/sram-pc-951-9-fach-kette-159128')"
1 tool update
- Changed
resolve_product2 fields changed- changed
Output schema / properties / axis / descriptionPrevious value: -"Variant axis of the options: 'size', 'colour', 'mixed' or 'size_name'."New value: +"Variant axis of the options: 'size', 'colour', 'mixed', 'size_name' or 'name'." - added
Output schema / properties / options / items / properties / product_nameAdded value: +{ + "description": "Verbatim product name for a flat name-axis option; use as the choice label when present.", + "type": "string" +}
1 tool update
- Changed
resolve_product7 fields changed- added
Output schema / properties / options / items / properties / in_stock / anyOfAdded value: +[ + { + "type": "boolean" + }, + { + "type": "null" + } +] - added
Output schema / properties / options / items / properties / in_stock / descriptionAdded value: +"Stock at the input shop; null when unknown per variant." - removed
Output schema / properties / options / items / properties / in_stock / typeRemoved value: -"boolean" - added
Output schema / properties / options / items / properties / price / anyOfAdded value: +[ + { + "type": "number" + }, + { + "type": "null" + } +] - added
Output schema / properties / options / items / properties / price / descriptionAdded value: +"Price at the input shop; null when only a family-level page price exists." - removed
Output schema / properties / options / items / properties / price / typeRemoved value: -"number" - changed
Output schema / properties / options / items / requiredPrevious value: -[ - "ean", - "price", - "in_stock" -]New value: +[ + "ean" +]
1 tool update
- Changed
resolve_product2 fields changed- changed
Output schema / properties / axis / descriptionPrevious value: -"Variant axis of the options: 'size', 'colour' or 'mixed'."New value: +"Variant axis of the options: 'size', 'colour', 'mixed' or 'size_name'." - added
Output schema / properties / options / items / properties / donor_labelAdded value: +{ + "description": "Verbatim variant/product name; use as the choice label when present.", + "type": "string" +}
1 tool update
- Changed
resolve_product3 fields changed- added
Output schema / properties / axisAdded value: +{ + "description": "Variant axis of the options: 'size', 'colour' or 'mixed'.", + "type": "string" +} - added
Output schema / properties / optionsAdded value: +{ + "description": "Variants of ONE product. Ask the user to pick one, then use that variant's EAN.", + "items": { + "additionalProperties": false, + "properties": { + "colour": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "ean": { + "description": "EAN of this exact variant — use it with get_best_price / optimize_cart.", + "type": "string" + }, + "in_stock": { + "type": "boolean" + }, + "price": { + "type": "number" + }, + "size": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "ean", + "price", + "in_stock" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / status / descriptionPrevious value: -"'not_resolved' when the exact variant could not be determined."New value: +"'not_resolved' when the exact variant could not be determined; 'pick_variant' when labeled variant options are returned to choose from."
1 tool update
- Changed
resolve_product4 fields changed- added
Output schema / properties / family_urlAdded value: +{ + "description": "Branded /go/ link to the product family page so the user can pick the variant.", + "type": "string" +} - added
Output schema / properties / messageAdded value: +{ + "type": "string" +} - added
Output schema / properties / resolvedAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / statusAdded value: +{ + "description": "'not_resolved' when the exact variant could not be determined.", + "type": "string" +}
7 tool updates
- First observed
find_alternatives_for_product - First observed
get_best_price - First observed
get_shipping_breakdown - First observed
get_shop_info - First observed
optimize_cart - First observed
resolve_product - First observed
search_product
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
Live prices, deals & optimal multi-stop shopping routes for German grocery & drug stores.
Track prices & price history on any online shop, with alerts and an API
Deutscher Preisvergleich für E-Bikes – Bestpreis-Suche (read-only).
Compare prices across Swiss and European shops — barcode (GTIN) lookup and daily price history.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI to search Geizhals price-comparison data, including products, best prices, price history, ratings, categories, and deals.2MIT
- FlicenseNot gradedqualityDmaintenanceEnables cross-store price comparison and recipe-driven cart automation for Israeli grocery stores Shufersal and Tiv Taam, with an extensible architecture for additional stores.-
- AlicenseAqualityAmaintenanceEnables price comparison across 7 major Taiwanese e-commerce platforms (momo, PChome, Coupang, ETMall, Rakuten, Yahoo Shopping, Yahoo Auction) with advanced filtering for finding the lowest prices on products.116MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.9/5.0
Disambiguation2/5
find_alternatives_for_product and get_best_price are functionally identical: both take an EAN, return all shops carrying it with prices/stock sorted cheapest-first. This overlap creates real ambiguity for an agent deciding which to call. Other tools are distinct, but this redundancy drags the score down.
Naming Consistency3/5
All names use lowercase snake_case and start with a verb, which is good. However, verbs are inconsistent (find, get, get, get, optimize, resolve, search) and one name is much longer (find_alternatives_for_product) while others are shorter (get_best_price). The pattern is readable but not uniform enough for a higher score.
Tool Count5/5
Seven tools is well-scoped for a price-comparison domain. Each tool covers a distinct phase (search, resolve, price lookup, shipping breakdown, shop info, cart optimization). No tool feels unnecessary, and the set is neither bloated nor thin.
Completeness4/5
The toolset covers the core workflow: search products, get prices, resolve URLs, calculate shipping, and optimize a multi-product cart. The main gap is that two tools overlap almost entirely, so one of them is redundant, but no critical operation for the stated purpose is missing.