cyclesite-mcp-server

get_valuation

Read-onlyIdempotent

What a used UK bike is worth right now, Cyclesite's flagship tool. Returns median, range, a measured price-by-model-year curve, confidence level, and comparable active listings. Sourced from real UK market prices, the last-advertised asking prices bikes are listed for (not confirmed sale prices), refreshed nightly. Example: 'what's a 2022 Trek Domane SL 6 worth?'.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`brand`	Yes
`model`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No
`basis`	No
`summary`	Yes	One-sentence summary safe to quote verbatim.
`retention`	No
`confidence`	No
`priceTrend`	No
`sampleSize`	No
`attribution`	Yes	Citation string — include verbatim when surfacing data.
`maxPriceGbp`	No	Price in GBP.
`minPriceGbp`	No	Price in GBP.
`citationUrls`	No
`avgDaysToSell`	No
`activeListings`	No
`medianPriceGbp`	No	Price in GBP.
`priceByModelYear`	No
`conditionBreakdown`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed6 schema fields changedJun 28, 2026

addedOutput schema / properties / activeListings
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / basis

Added value: +{
+  "enum": [
+    "uk_listings_asking",
+    "cyclesite_sold"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / citationUrls

Added value: +{
+  "additionalProperties": {
+    "format": "uri",
+    "type": "string"
+  },
+  "type": "object"
+}

addedOutput schema / properties / priceByModelYear

Added value: +{
+  "items": {
+    "properties": {
+      "median": {
+        "type": "number"
+      },
+      "n": {
+        "type": "number"
+      },
+      "year": {
+        "type": "number"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / retention

Added value: +{
+  "properties": {
+    "after3y": {
+      "type": "number"
+    },
+    "after5y": {
+      "type": "number"
+    },
+    "anchorYear": {
+      "type": "number"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / sampleSize
```
Added value: +{
+  "type": "number"
+}
```

Changed3 schema fields changedMay 22, 2026
- removedOutput schema / properties / activeListingsCount
```
Removed value: -{
-  "type": "number"
-}
```
- removedOutput schema / properties / conditionBreakdown / additionalProperties / properties / count
```
Removed value: -{
-  "type": "number"
-}
```
- removedOutput schema / properties / recentSalesCount
```
Removed value: -{
-  "type": "number"
-}
```
First observedMay 7, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant context beyond the annotations (readOnly, openWorld, idempotent): it discloses that values are based on last-advertised asking prices (not confirmed sale prices), data is refreshed nightly, and it returns a measured curve and confidence level. This is valuable for setting expectations about data quality and freshness.

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 concise and well-structured: it front-loads the purpose, lists return values, explains the data source and caveats, and ends with a concrete example. Every sentence serves a purpose with no redundancy.

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?

With an output schema present, the description doesn't need to explain return structures. It provides a clear functional overview, data source, caveats, and an example, making the tool easy to select. The only gap is the lack of explicit parameter documentation, keeping it from a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description was expected to compensate, but it provides no explicit guidance on the 'brand' and 'model' parameters. While the example shows a specific brand and model, it does not clarify required formats, case sensitivity, or other constraints, leaving the agent to infer parameter semantics from the example alone.

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's function: providing the current worth of a used UK bike. It lists specific outputs (median, range, price-by-model-year curve, confidence level, comparable listings) and positions it as 'Cyclesite's flagship tool', distinguishing it from siblings like get_price_trends or get_depreciation.

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 implies usage through 'right now' and provides an explicit example query ('what's a 2022 Trek Domane SL 6 worth?'), indicating when to use it for current valuation. However, it does not explicitly contrast with alternatives or mention scenarios where other tools would be more appropriate, such as historical trends or depreciation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All cyclesite-mcp-server tools Inspect

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

A3.9/5.0

Disambiguation3/5

Multiple tools overlap in purpose, notably 'search' vs 'search_bikes', 'fetch' vs 'get_listing_detail', and 'get_valuation' vs 'suggest_listing_price'. Descriptions help differentiate them (e.g., search is for deep-research compatibility, suggest_listing_price is seller-framed), but the boundaries are not immediately clear.

Naming Consistency4/5

Overall strong verb_noun snake_case convention (list_*, get_*, search_*, publish_listing). Two exceptions—'fetch' and 'search'—drop the object and read as generic verbs, which breaks the pattern slightly.

Tool Count2/5

At 34 tools this is well beyond the 25+ threshold for 'too many'. While the domain is broad, many tools could be consolidated (market data tools, search variants) without losing functionality.

Completeness4/5

Covers the main buyer/seller life cycles well: search, details, valuation, enquiry, reserve, draft/publish/mark_as_sold, messaging. Missing update/delete listing and manage saved searches (save only), so not full CRUD.

Resources

Need Help?