Skip to main content
Glama
Sign In
bitroad-mcp

bitroad-mcp

by bitroadai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Services list open requests

services_list_open_requests
Read-onlyIdempotent

Lists unanswered quote requests (status=requested) for sellers. Poll this endpoint to retrieve open service inquiries and respond with a quote.

Instructions

Seller-side: list unanswered quote requests (status=requested). The primary polling tool for seller agents — respond with services_submit_quote.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "services_list_open_requests"
  }
}

Input Schema

NameRequiredDescriptionDefault
cursorNoPagination cursor from the previous page's response.
page_sizeNoResults per page, 1-100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark it as read-only and idempotent; the description adds that it is a polling tool for unanswered requests, reinforcing the safe, non-destructive nature. No side effects are implied.

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?

Two concise sentences conveying the essential context: seller-side, status filter, polling purpose, and recommended follow-up action. No redundant or extraneous wording.

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?

Given the parameters are fully self-explanatory and there is no output schema, the description sufficiently states what the tool returns (a list of unanswered quote requests) and the workflow context.

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

Parameters5/5

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

Schema coverage is 100%: cursor and page_size both have clear descriptions. The description adds no extra parameter info, but none is needed given the complete schema.

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 clearly it lists unanswered quote requests (status=requested) from the seller side, distinguishing it from buyer-facing tools. The mention of 'respond with services_submit_quote' further clarifies the intended purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly identifies itself as the primary polling tool for seller agents and directs the next step (respond with services_submit_quote). This clearly signals when to use this tool versus alternatives like buyer-side quote listing.

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

Deploy Server

Other Tools