Skip to main content
Glama
Sign In
bitroad-mcp

bitroad-mcp

by bitroadai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Seller get listing

seller_get_listing
Read-onlyIdempotent

Fetch a seller's own listing by product ID to view full description, current and reserved stock, spec values, and moderation state; access is denied if the listing belongs to another seller.

Instructions

Fetch a single listing the bound seller owns, including its full description, current stock + reserved counts, spec values, and any moderation state. Refuses if the listing belongs to a different seller.

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": {
      "product_id": "<product_id>"
    },
    "name": "seller_get_listing"
  }
}

Input Schema

NameRequiredDescriptionDefault
product_idYesUUID of the listing to fetch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by revealing the ownership check ('refuses if the listing belongs to a different seller') and the exact data fields returned, which are not implied by annotations or schema. This is substantive behavioral disclosure beyond structured data.

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 a single, compact sentence that front-loads the primary action and resource, then lists the key return fields and the refusal condition. Every clause earns its place; there is no fluff or redundancy, making it optimally concise and well-structured.

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?

For a single-parameter read operation with full schema coverage and annotations covering idempotence and non-destructiveness, the description is complete: it states what is returned, the ownership constraint, and the refusal behavior. No output schema exists, but the description enumerates the content sufficiently. Nothing essential for correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 100% and the single parameter product_id is well-described as a UUID. The description enriches this by clarifying that the UUID must correspond to a listing owned by the bound seller, adding a semantic constraint not present in the schema's description. This is meaningful additional guidance for correct invocation.

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 states a specific verb ('fetch'), a precise resource ('a single listing the bound seller owns'), and enumerates the returned contents (description, stock/reserved counts, spec values, moderation state). This clearly distinguishes it from sibling tools like seller_list_listings (list all) and catalog_get_product (public product info), leaving no ambiguity about its function.

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 defines the scope as the bound seller's own listings and explicitly notes it refuses other sellers' listings, giving clear context for when it applies. It doesn't name alternative tools for other cases (e.g., public product lookup), but the ownership constraint effectively guides usage for seller-scoped retrieval, so it's nearly complete.

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