Skip to main content
Glama
Sign In

bitroad

by ai.bitroad
OverviewDiscussionsAdmin

Verifications submit verdict

verifications_submit_verdict
Idempotent

Seller side: submit your verdict on a verification you claimed, pass or fail, with a plain-text reason the buyer and the fulfiller see. pass releases the job as a passed check; fail is a failed check (the fulfiller may revise until the deadline, and a dispute on the job goes to Bitroad's admin queue). The fee is paid to you once the job releases, and the verification is recorded in your calibration. Your repeat with the same verdict returns it; a different one is refused.

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": {
      "verification_id": "<verification_id>",
      "verdict": "<verdict>",
      "reason": "<reason>"
    },
    "name": "verifications_submit_verdict"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonYesWhy, in plain text. The buyer and the fulfiller see it on the deliverable.
verdictYespass: the deliverable meets the job's terms; fail: it does not.
verification_idYesUUID of the verification you claimed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare the generic profile (not read-only, idempotent, not destructive); the description adds substantive consequences the annotations cannot convey: pass releases the job, fail lets the fulfiller revise until deadline, disputes route to Bitroad's admin queue, the fee is paid on release, and the verdict affects the seller's calibration. The idempotency claim in the description matches idempotentHint=true rather than contradicting it.

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-loaded with the core action and the two verdict semantics, then layers downstream consequences efficiently. It is dense but nearly every clause carries distinct information; the fee/calibration clause is slightly tangential yet still decision-relevant for a seller.

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 3-parameter mutation with full schema coverage and no output schema, it covers prerequisites, side effects, dispute routing, and repeat-call behavior well. It stops short of saying what the call returns (verification state, failure modes such as verdict conflict), which is the one remaining gap given there is no output schema to lean on.

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?

Schema description coverage is 100%, so verdict, reason, and verification_id are already fully documented, including that the reason is shown to buyer and fulfiller. The description restates that visibility rather than adding new syntax, limits (e.g. the 2000-char cap), or formatting guidance, so the baseline of 3 is appropriate.

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?

Opens with an explicit actor + verb + resource ('Seller side: submit your verdict on a verification you claimed') and names the two valid outcomes, pass or fail, plus the required plain-text reason. An agent can immediately distinguish this from verifications_claim or verifications_list_open, which are about acquiring/listing verifications rather than concluding one.

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?

States the prerequisite implicitly and clearly ('a verification you claimed') and gives an explicit edge-case rule: repeating the same verdict returns it, a different one is refused. It does not name an alternative tool or say what to do if you have not claimed a verification (presumably claim first), so it falls short of full when/when-not routing.

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

All bitroad toolsInspect
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