cyclesite-mcp-server

Check a frame number

check_stolen

Idempotent

Check whether a UK bike's frame (serial) number matches a theft report held by Cyclesite. Live data, checked on every call. Rate-limited per serial number (3 an hour) to prevent enumeration. Example: 'does frame number WTU123456 match a theft report?'. Someone who has found a bike, rather than bought one, can check the frame number and leave the owner a message at https://www.cyclesite.co.uk/stolen-bikes/found.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "serial": "<serial>"
    },
    "name": "check_stolen"
  }
}

Input Schema

Name	Required	Description	Default
`serial`	Yes	Frame/serial number (4-50 chars).

Output Schema

Name	Required	Description
`url`	No
`action`	No
`status`	Yes
`message`	No
`checkedAt`	No
`confidence`	No
`attribution`	Yes	Citation string for the data in this result.
`sourcesChecked`	No
`confidenceLabel`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / properties / attribution / description

Previous value: -"Citation string — include verbatim when surfacing data."New value: +"Citation string for the data in this result."

Changed2 schema fields changedJul 3, 2026
- removedOutput schema / properties / sourcesChecked / items
```
Removed value: -{
-  "type": "string"
-}
```
- changedOutput schema / properties / sourcesChecked / type
```
Previous value: -"array"New value: +"integer"
```
First observedMay 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: live data checked on every call, a rate limit of 3 per hour per serial number, and the anti-enumeration rationale behind it. This is exactly the quota information an agent needs before deciding how often to call.

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?

Front-loads the purpose, then layers behavior, then usage. The example query and the found-bike link are both short and useful, and there is no filler.

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?

An output schema exists, so return values need not be described, and the description covers purpose, limits, and the adjacent workflow. It does leave open why the annotation marks this non-read-only when the tool reads live data, which an agent might wonder about for side effects or quota accounting.

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?

With a single parameter at 100% schema coverage, the schema already documents the serial parameter and its 4-50 char constraint. The description contributes meaning only indirectly, by framing the serial as a UK bike frame number, so it cannot exceed the baseline.

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?

Names a specific verb and resource: check whether a UK bike's frame (serial) number matches a Cyclesite theft report. This clearly distinguishes it from the sibling report_stolen, which files a report instead of looking one up.

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?

Gives a concrete example query and a clear alternate use case — someone who found a bike can check and message the owner via the given URL. It does not explicitly rule out adjacent cases (e.g. checking a bike you are about to buy vs. one you already own) or name report_stolen as the tool for the inverse action.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?