bitroad-mcp

Services accept quote

services_accept_quote

Accept a submitted service quote and charge the payment method immediately, with spending caps enforced and funds held in escrow until the deliverable is accepted.

Instructions

Accept a submitted quote and charge immediately. Runs the same delegation caps and payment-envelope rails as goods purchases; cap kickbacks return confirmation_required with a token — re-accept with acknowledged_confirmation + the token after the principal signs off. Funds are held in escrow until the deliverable is accepted.

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": {
      "service_quote_id": "<service_quote_id>",
      "acknowledged_confirmation": "<acknowledged_confirmation>"
    },
    "name": "services_accept_quote"
  }
}

Input Schema

Name	Required	Description
`service_quote_id`	Yes	UUID of the quoted thread to accept and pay.
`payment_method_id`	No	UUID of a saved payment method to charge. Omitted = envelope-bound card, else the principal's default.
`confirmation_token`	No	Token from the confirmation_required kickback; must match to complete the charge.
`__outcomeForTesting`	No	Test-only: force a simulated card outcome. Never set in production.
`acknowledged_confirmation`	Yes	Set true when retrying after a confirmation_required kickback, together with confirmation_token.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes far beyond annotations. It reveals that this operation charges immediately, shares rails with goods purchases, can return a confirmation_required kickback with a token, requires re-acceptance after principal sign-off, and holds funds in escrow until deliverable acceptance. This is rich behavioral disclosure that the annotations (only readOnlyHint=false, etc.) do not provide. No contradiction with annotations.

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 two sentences but packs substantial information without redundancy. It front-loads the primary action, then explains the special kickback scenario and escrow behavior. Every clause adds value, and there is no fluff. The structure is efficient and easy to parse.

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 tool with 5 parameters, no output schema, and complex behavior (kickbacks, escrow, delegation), the description covers the essential flow: immediate charge, potential confirmation_required retry, and escrow holding. It doesn't detail return values, but with no output schema, that is not required. The description is sufficiently complete for an agent to call it correctly in most scenarios.

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?

The schema has 100% coverage for all 5 parameters with descriptive text. The description adds semantic context by explaining the relationship between confirmation_token and acknowledged_confirmation, and how payment_method_id is optional with a fallback to envelope-bound card. This goes beyond the schema's individual parameter descriptions, enhancing the agent's understanding of the flow.

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 ('Accept a submitted quote and charge immediately') with a clear resource and effect. It distinguishes from sibling tools like services_purchase (which likely handles direct purchase) and services_submit_quote (which is for providers). The verb 'accept' plus the immediate charge clearly differentiates it from reject/counter flows.

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 implies the primary use case: accepting a quote and initiating payment. It explicitly describes the retry flow when a confirmation_required kickback occurs, telling the agent to re-accept with acknowledged_confirmation and the token. It doesn't explicitly state alternatives, but the context (services workflow) and the mention of 'delegation caps' and 'payment-envelope rails' give enough guidance for when to use this vs. other services tools.

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

Deploy Server