Vurto Swap

payout_charge

Idempotent

Step 2 of a payout_batch with checks, on Solana or EVM. After signing and sending payout_batch's charge.transaction, hand its signature or hash here with the loteId and payer. The server verifies the charge on-chain, runs the paid analysis on EVERY destination, EXCLUDES any wallet that is blocked or over the payer's risk threshold (it receives nothing, its money never moved), and returns { transactions[], evm?, approved[] (each with its scan result), rejected[] (wallet, reason) }. On Solana, sign each transactions[i].transaction (prepare_signing, POST to /v1/svm/execute) and call payout_report_payment with that signature and its invoiceIds. On EVM, sign evm.steps IN ORDER (approve, then pay the IBBs contract) and call payout_report_payment with the pay transaction hash and evm.invoiceIds. Idempotent with the same charge signature (re-returns the built batch, without the wallets already paid, listed in alreadyPaid). The charge hash goes only here, never to payout_report_payment. Errors: batch_charge_not_found, invalid_tx_hash, analysis_payment_pending (409, the network has not confirmed the charge yet, send the signature again shortly), analysis_payment_rejected (the transaction does not pay this charge; details.reason charge_not_tied when it is not the transaction payout_batch built: do not pay again, prove the wallet with destination_challenge (receiver = details.feeWallet, chargeId = the loteId, chargeTxHash = that hash), then destination_authorize, and call this again), tx_already_used.

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": {
      "loteId": "<loteId>",
      "payer": "<payer>"
    },
    "name": "payout_charge"
  }
}

Input Schema

Name	Required	Description
`payer`	Yes	The wallet that paid the charge (base58 on Solana, 0x on EVM).
`loteId`	Yes	The loteId from payout_batch's charge.
`txHash`	No	The Solana signature or EVM transaction hash of the charge payment. Omit only to rebuild a fully-reused batch (website session only).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

changedInput schema / properties / payer / description

Previous value: -"The wallet that paid the charge (base58)."New value: +"The wallet that paid the charge (base58 on Solana, 0x on EVM)."

changedInput schema / properties / txHash / description

Previous value: -"The Solana signature of the charge payment. Omit only to rebuild a fully-reused batch (website session only)."New value: +"The Solana signature or EVM transaction hash of the charge payment. Omit only to rebuild a fully-reused batch (website session only)."

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial behavior beyond that: on-chain verification, the block/risk-threshold exclusion rule ('it receives nothing, its money never moved'), idempotency details (alreadyPaid), and a full error taxonomy including the 409 pending case and tx_already_used. It stops short of stating permissions or rate limits, so it is not a perfect 5.

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 step number and the core action, then ordered into workflow, return shape, next steps, idempotency and errors. It is dense and long, with several multi-clause sentences (the analysis_payment_rejected sentence in particular), but nearly every sentence carries operational information that an agent needs.

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?

The tool has no output schema, and the description compensates by spelling out the return object shape (transactions[], evm?, approved[] with scan results, rejected[] with wallet and reason) plus alreadyPaid. For a multi-step, cross-chain, financially sensitive tool, the enumerated errors and follow-up calls make the definition complete for correct invocation.

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 coverage is 100%, so the schema already documents payer, loteId and txHash, and the description adds little field-level detail beyond what is there. It does add routing meaning for txHash ('goes only here, never to payout_report_payment') and ties loteId back to payout_batch's charge, which is useful, but the baseline of 3 is appropriate when the schema does the heavy lifting.

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?

States a specific action (verify a batch charge on-chain and build the payout batch) and anchors it in the workflow as 'Step 2 of a payout_batch'. It clearly distinguishes itself from payout_report_payment, which is named as the later step, and from payout_batch, which produces the charge.transaction this tool consumes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use is given: after signing and sending payout_batch's charge.transaction, hand its signature or hash here with loteId and payer. It also states the exclusions and alternatives explicitly: the charge hash goes only here, never to payout_report_payment, and the analysis_payment_rejected path routes to destination_challenge then destination_authorize before retrying.

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

All Vurto Swap tools Inspect

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

Need Help?