Skip to main content
Glama
Sign In

ExchangeRebel — pay-per-call APIs for AI agents (x402 on Solana)

by com.exchangerebel
OverviewDiscussionsAdmin

chain_reconcile_reconcile

$0.05 USDC on Solana per report - the payment buys one signed multi-hop payment-chain reconciliation report: the submitted hop record set (a parent reference with its cap, plus per-hop payment references with expected fields and per-hop caps) is chain-verified hop by hop with the settlement-evidence/v1 engine, ancestor-cap arithmetic is applied over the submitted caps, and one verdict is returned (CHAIN-SETTLED / CHAIN-UNSETTLED / CHAIN-MISMATCH / CHAIN-CAP-EXCEEDED, named hop, factors per hop). No composite score. Records leg only.

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": {
      "parent": "<parent>",
      "hops": "<hops>"
    },
    "name": "chain_reconcile_reconcile"
  }
}

Input Schema

NameRequiredDescriptionDefault
hopsYes1 to 20 hop records in chain order: {hop_id, signature (the on-chain payment transaction), expected {payTo, amountUnits, memo?}, capUnits (decimal string; this hop's cap)}. Processed against the chain; hop-set content is never stored beyond the ledger's closed field list.
parentYesThe chain parent: {reference (caller-chosen label, echoed never graded), capUnits (decimal string; the ancestor cap over all hops)}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses the $0.05 USDC Solana charge, one signed report per payment, the settlement-evidence/v1 engine, cap arithmetic, and the four possible verdicts with per-hop detail. It does not explain payment execution, failure or refund behavior, or the precise meanings of the verdicts.

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?

The description packs cost, processing, outputs, and scope into a compact passage with no filler. Its main sentence is nevertheless long and densely nested, and leading with the price slightly delays the core operation.

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 complex paid tool with nested inputs, no annotations, and no output schema, it adequately covers the required record set, verification process, cap handling, report signature, and possible verdicts. Workflow prerequisites, payment mechanics, and verdict interpretation remain the main omissions.

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%, and both parameters already document their nested fields and roles. The description usefully reinforces how parent and per-hop caps participate in reconciliation, but mostly restates information already present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource and operation: producing a signed multi-hop payment-chain reconciliation report through hop-by-hop chain verification and ancestor-cap arithmetic. The records-only scope and absence of a composite score clarify its limits, but it does not explicitly differentiate itself from chain_reconcile_precheck or chain_reconcile_criteria.

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?

It implies use when a submitted parent-and-hops record set needs paid chain verification and cap reconciliation, while explicitly excluding composite scoring and other legs. It does not explain when to run the precheck or criteria siblings first, or name an alternative for out-of-scope needs.

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

All ExchangeRebel — pay-per-call APIs for AI agents (x402 on Solana) toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources