Skip to main content
Glama

Bikefuchs — Bike Parts Price Comparison

by com.bikefuchs

Get Best Price by EAN

get_best_price
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eanYesEAN barcode (8–14 digits, e.g. '4524667749493')
countryNoCountry for pricing (DE or AT, default DE)DE
reference_shopNoShop id or display name to compare against. When set, the response states how much cheaper the cheapest shop is vs. this shop.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
eanYes
pricesYes
next_stepNo
product_nameYes
cheapest_shopYes
cheapest_priceYes
reference_comparisonNo

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.

All Bikefuchs — Bike Parts Price Comparison toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation2/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources