cyclesite-mcp-server

Reserve listing (24h hold)

reserve_listing

Idempotent

Hold a Cyclesite listing for 24 hours so other buyers can't claim it while the user decides. The hold is free and advisory: the seller isn't obligated to honour it. We never take a deposit or any payment for a bike; the buyer and seller arrange payment between them. Requires OAuth scope listings:manage. Example: 'put a hold on that Trek for me, I want to view it Saturday'.

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": {
      "listingId": "<listingId>"
    },
    "name": "reserve_listing"
  }
}

Input Schema

Name	Required	Description	Default
`listingId`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

removedInput schema / properties / depositGbp

Removed value: -{
-  "description": "COMING SOON — deposits are not yet available; omit this field (the server refuses it with payments_unavailable). When live: optional refundable deposit (£10-£500) via Stripe Checkout.",
-  "type": "number"
-}

Changed1 schema field changedJul 15, 2026

changedInput schema / properties / depositGbp / description

Previous value: -"Optional refundable deposit (£10-£500). When set, user pays via Stripe Checkout."New value: +"COMING SOON — deposits are not yet available; omit this field (the server refuses it with payments_unavailable). When live: optional refundable deposit (£10-£500) via Stripe Checkout."

First observedMay 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the 24-hour duration, that the hold is free and non-binding on the seller, that no payment or deposit is taken, and the required OAuth scope `listings:manage`. The annotations only declare it a non-destructive, idempotent mutation; the description supplies the consequences and prerequisites an agent actually needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and duration, then caveats, then auth requirement, then an example — a sensible order with no wasted sentences. The payment disclaimer is slightly tangential but has practical value in a buyer-facing conversational context, preventing the agent from promising payment handling.

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?

For a one-parameter tool with an output schema and rich annotations, the description covers prerequisites (scope), semantics (24h, advisory), and trigger phrasing. The only real omission is any detail on the listingId argument or what happens on a repeat call, which idempotentHint already signals.

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 single required parameter `listingId` has no description in the schema (0% coverage), and the description never explains its form or provenance beyond the example reference to 'that Trek'. The name is largely self-explanatory, so this is adequate but not compensating for the coverage gap.

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?

States a specific verb and resource with exact scope: 'Hold a Cyclesite listing for 24 hours so other buyers can't claim it.' The temporary, non-exclusive nature of the hold makes it unmistakably distinct from siblings like make_enquiry or save_search.

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?

Usage context is clear from 'while the user decides' and reinforced by a concrete utterance example ('put a hold on that Trek for me, I want to view it Saturday'). It lacks an explicit when-not or a named alternative tool, which keeps it 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.

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?