Skip to main content
Glama
Sign In
bitroad-mcp

bitroad-mcp

by bitroadai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Seller accept return

seller_accept_return
Idempotent

Acknowledge a returned parcel as received after inspection, moving the return from approved to received and triggering the refund process.

Instructions

Acknowledge that a returned parcel arrived and was inspected. Moves return: approved → received. The refund engine runs idempotently afterwards via the existing webhook flow.

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": {
      "return_id": "<return_id>"
    },
    "name": "seller_accept_return"
  }
}

Input Schema

NameRequiredDescriptionDefault
return_idYesUUID of the return to accept. Acceptance refunds the buyer immediately (idempotent).
inspection_notesNoOptional inspection notes recorded on the return (max 2000 chars).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate idempotentHint=true and readOnlyHint=false, but the description adds the specific state change and the asynchronous refund via webhook, which is valuable behavioral context beyond the annotations. It does not contradict any annotation.

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 exactly two sentences, front-loaded with the core action, followed by the state transition and side effect. Every sentence adds value with no redundant phrasing.

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 simple two-parameter mutation with no output schema, the description covers the action, state transition, and side effect. It implies the precondition (return must be in 'approved' state) through the transition. It does not describe the response or error cases, but the idempotency annotation and the simplicity of the operation make this sufficient.

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 schema descriptions already cover both parameters with detailed meaning (return_id explains acceptance and immediate refund; inspection_notes explains its optional nature and limit). Schema coverage is 100%, so the tool description adds no extra parameter-specific information, placing it at the baseline of 3.

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 action (acknowledge arrival and inspection) and the exact state transition (approved → received), which clearly distinguishes it from sibling seller_reject_return. It also mentions the refund engine, giving a complete picture of the tool's 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 gives clear context on when to use the tool (when the parcel has arrived and been inspected) by describing the precondition for the state transition. However, it does not explicitly name alternatives like seller_reject_return or state when not to use it, though the sibling list makes the distinction implicit.

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