Bikefuchs — Bike Parts Price Comparison
Server Details
Price comparison & cart optimizer for bike parts across German & Austrian shops
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 4.3/5 across 7 of 7 tools scored.
The tools 'find_alternatives_for_product' and 'get_best_price' have nearly identical descriptions, both retrieving price and availability for a product by EAN. This creates confusion and likely causes misselection. Other tools are distinct, but this overlap significantly reduces clarity.
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_best_price, resolve_product, search_product). No mixing of conventions or irregular naming.
With 7 tools, the set is well-scoped for a bike parts price comparison server. Each tool serves a clear purpose in the shopping workflow, and the count is neither excessive nor insufficient.
The tool surface covers the core workflow: searching, resolving URLs, looking up by EAN, obtaining shipping info, and optimizing cart splits. The only minor gap is the redundancy between two nearly identical tools, but no essential operations are missing.
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.
| 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
| Name | Required | Description |
|---|---|---|
| ean | Yes | |
| alternatives | Yes | |
| product_name | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate safe read-only operation. Description adds sorting and return details (prices and availability), but does not mention limits (e.g., pagination, max shops) or behavior for invalid EANs. Moderate additional value.
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, front-loaded with purpose, no fluff. Every word earns its place.
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 simplicity, the description covers the key aspects: input, output, sorting. However, it lacks mention of error handling (e.g., no shops found) or output schema details. Since an output schema exists, the description is mostly sufficient.
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 descriptions for both 'ean' and 'country'. The description adds context that the EAN is for a product and country affects pricing, but this is implicit in the schema already. Minimal added value.
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 action (return shops), the input (EAN barcode), and the output (prices, availability, sorted cheapest-first). It distinguishes from siblings like 'search_product' which searches by name, and 'get_best_price' which likely returns a single price.
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 when you have an EAN barcode, but does not explicitly mention when not to use it or contrast with sibling tools like 'search_product' or 'get_best_price'. No guidance on prerequisites or alternatives.
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.
| 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
| Name | Required | Description |
|---|---|---|
| ean | Yes | |
| prices | Yes | |
| next_step | No | |
| product_name | Yes | |
| cheapest_shop | Yes | |
| cheapest_price | Yes | |
| reference_comparison | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: sorted cheapest-first, stock status, and purchase links. It does not contradict 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?
Single sentence, no wasted words, directly states the action and key outputs. Appropriately 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?
For a simple read tool with an output schema, the description covers purpose, input, behavior, and output format adequately. No gaps identified.
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% so the schema fully documents parameters. The description adds minimal extra meaning beyond what the schema provides, meeting the baseline.
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-resource combination ('Look up a single product by its EAN barcode') and clearly distinguishes the tool from siblings like search_product (for non-exact EAN) and find_alternatives_for_product (for alternatives).
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 when to use (when you have an exact EAN and want prices) but doesn't explicitly state when not to use or name alternatives. It is clear enough for the context.
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.
| 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
| Name | Required | Description |
|---|---|---|
| shop | Yes | |
| country | Yes | |
| currency | Yes | |
| cart_value | Yes | |
| shipping_cost | Yes | |
| free_shipping_threshold | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the output includes 'all shipping tiers' and 'how much more needed for next free-shipping threshold,' providing context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word adds value – it states the action, inputs, and output details. No wasted 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?
For a tool with 3 well-documented parameters and an output schema, the description explains the output (shipping tiers, next threshold) sufficiently. It gives the agent a complete picture of what the tool computes and returns.
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%, so the schema already documents all parameters. The description repeats the parameter concepts ('shop, country, and cart value') without adding new semantic details. 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 returns 'exact shipping cost' for specific inputs (shop, country, cart value) and includes details about shipping tiers and free-shipping thresholds. It uses a specific verb ('Return') and distinguishes from sibling tools like 'get_best_price' or 'optimize_cart' that 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 does not explicitly state when to use this tool over siblings. It implies usage when shipping cost details are needed, but lacks direct comparisons or exclusions (e.g., 'Use this when you need shipping cost breakdown, not total price'). Context signals show sibling tools but no guidance in text.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Filter output to a specific country (optional — omit for both DE and AT) |
Output Schema
| Name | Required | Description |
|---|---|---|
| shops | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as readOnly/idempotent/non-destructive. Description adds valuable context about the specific data returned (shipping cost tiers, thresholds, supported countries). Does not disclose rate limits or auth needs, but annotations suffice.
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 key details. No redundant words, efficiently conveys purpose and output scope.
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 tool, annotations, and presence of output schema, the description completely covers what the tool does and the optional parameter. No 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?
Schema covers both parameters with descriptions (100% coverage). Description adds value by explaining that omitting the optional country parameter returns data for both DE and AT, which is not explicitly in 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?
Clearly states the tool returns an overview of supported shops with specific details (shipping cost tiers, free-shipping thresholds, supported countries). Effectively distinguishes from sibling tools like get_best_price or get_shipping_breakdown 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?
Implies usage context by listing the returned information and optional country filter, but does not explicitly state when to use vs alternatives or exclude certain scenarios (e.g., unsupported countries). Still, the description is clear enough for typical use.
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.
| 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
| Name | Required | Description |
|---|---|---|
| optimization | Yes | |
| savings_info | No | |
| stale_cache_warning | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds context about shipping costs and free-shipping thresholds, enhancing transparency. Could mention rate limits or performance, but not critical.
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: first explains purpose and output, second gives prerequisite and action. No wasted words, front-loaded with key info.
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 output schema present, description covers all needed context: prerequisite call, parameter role, and expected computation. Complements sibling tools well.
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 has 100% parameter coverage with descriptions. Description adds value by explaining the overall workflow and the role of EAN barcodes, not just repeating 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 finds the cheapest way to buy multiple products by computing optimal split across shops. Distinguishes from sibling tools like get_best_price which is per-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?
Explicitly instructs to call get_best_price first for accurate results, providing a clear usage workflow. Could mention when not to use, but the prerequisite is well-stated.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Product page URL from a supported shop (e.g. 'https://www.bike24.de/p2462871.html') | |
| country | No | Country for pricing (DE or AT, default DE) | DE |
Output Schema
| Name | Required | Description |
|---|---|---|
| ean | No | |
| axis | No | Variant axis of the options: 'size', 'colour' or 'mixed'. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds value by detailing the variant handling behavior and the output structure, going beyond the annotation hints.
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 paragraph with three sentences, each serving a distinct purpose: core function, output usage, variant handling. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters, high schema coverage, and an existing output schema, the description is complete. It explains the tool's purpose, output, variant handling, and references sibling tools for next steps. No 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?
Schema description coverage is 100%, so baseline is 3. The description adds contextual semantics by explaining the overall purpose and how parameters fit in (e.g., URL from supported shop, country for pricing). It also provides an example URL format in the schema itself.
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 converts a product URL into structured data (EAN, price, stock, purchase link). It distinguishes from siblings by explaining the EAN's use with get_best_price or optimize_cart, and specifically handles multi-variant products with a user selection step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (when a supported product URL is available) and how to proceed with the output. For multi-variants, it instructs to ask the user. It does not explicitly state when not to use it, but the guidance is clear and practical.
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.
| 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
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| next_steps | No | |
| total_results | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds behavioral details: sort order (cheapest-first), return fields (price, stock, EAN, link), and country-specific pricing. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then return details and country support, ends with alternative. No wasted 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 output schema (implied), parameter descriptions, and annotations, description covers key aspects: search scope, sorting, returned fields, pricing countries, and alternative tool. Suitable for a search 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?
Schema coverage is 100%, but description adds value by explaining multi-word AND logic for 'q' parameter. Does not repeat all schema descriptions but provides helpful context 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?
The description clearly states it searches for bicycle parts/accessories by name/brand/model number, returns results sorted cheapest-first with price, stock, EAN, and link. It distinguishes from sibling get_best_price by noting EAN alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on country support (DE/AT) and explicitly suggests using get_best_price when EAN is known. Lacks explicit when-not conditions for other siblings but is sufficient.
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!