check-payment-recipient

check_payment_batch

Paid ($0.50, x402 v2 exact): batch pre-signing safety check — 1 to 20 payment checks in ONE paid call. Each item takes exactly the same fields as check_payment_recipient and gets its own decision; the result carries per-item decisions plus a summary {total, allow, escalate, block, input_error}. An item with invalid fields is reported per item as INPUT_ERROR and does not fail the batch. Envelope errors (missing batch idempotency_key, items not an array of 1-20) are returned before payment and are never charged. On an uncertain outcome, reuse the same batch idempotency_key; a replay returns the stored result without a new payment.

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": {
      "items": "<items>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "check_payment_batch"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes
`idempotency_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description covers the cost ($0.50, x402 v2 exact), the payment and error model (envelope errors are returned before payment and are never charged), the per-item failure isolation (INPUT_ERROR does not fail the batch), and idempotency replay behavior. This is exactly the operational detail an agent needs to use the tool safely.

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 is dense and front-loads the key facts (paid, batch, purpose), then moves to error and idempotency semantics. It is somewhat long, but nearly every sentence carries distinct and useful information, so little is wasted.

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?

There is no output schema, and the description still explains the return shape (per-item decisions plus a summary with total/allow/escalate/block/input_error), which is what an agent needs to interpret the result. The main remaining gap is that item-level field semantics are deferred to the sibling tool rather than restated.

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 0% and the required item fields (recipient_address, amount, asset, network, requested_at, per-item idempotency_key) are not enumerated; the description instead defers to check_payment_recipient's field set. It does add real meaning for the batch-level idempotency_key (reuse on uncertain outcome, replay returns stored result) and the 1-20 array envelope, but it only compensates for part of the coverage gap.

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 capability (batch pre-signing safety check for payments), the limits (1 to 20 payment checks in one paid call), and how it relates to the sibling check_payment_recipient. An agent can immediately tell what the tool does and when the batch version applies.

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 makes clear this is for pre-signing safety checks across multiple recipients, with items mirroring check_payment_recipient, which implicitly contrasts it with the single-recipient sibling. It does not explicitly say 'use check_payment_recipient for a single check', so the routing guidance is strong but inferred rather than spelled out.

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

All check-payment-recipient 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?