Skip to main content
Glama

Revisar respuesta de liquidación x402

x402-payment-response-verify
Read-onlyIdempotent

Comprueba una liquidación X-PAYMENT-RESPONSE / PAYMENT-RESPONSE de x402 frente a los PaymentRequirements dados (y opcionalmente el pago): éxito, formato del hash, red, pagador, payTo y monto. Solo consistencia de los datos dados, no lo registrado en la cadena. Cuándo: hay que cotejar una respuesta de liquidación x402 con lo ofrecido y pagado antes de entregar o registrar. No para: decodificar una cabecera de pago x402 y revisar su estructura (x402-payment-decode); ni revisar el vínculo de entrega de un recibo pagado de Burs-IA (SKU x402 de pago aparte de Burs-IA verify-x402-delivery-receipt, por llamada en USDC en Base). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Checks an x402 X-PAYMENT-RESPONSE / PAYMENT-RESPONSE settlement value against given PaymentRequirements (and optionally the payment… [EN completo / full EN: inputSchema.description]

Input Schema

NameRequiredDescriptionDefault
paymentNoOptional X-PAYMENT / PAYMENT-SIGNATURE value or decoded payload the client sent, to check payer, payTo and amount (string or object; optional; up to 16448 chars).
responseYesX-PAYMENT-RESPONSE (v1) or PAYMENT-RESPONSE (v2) value: base64 JSON string or the decoded object (string or object; required; up to 16448 chars).
requirementsYesThe PaymentRequirements the seller offered: one accepts[] entry, the accepts array or the whole 402 body (object or array; required; up to 100 items).

Output Schema

NameRequiredDescriptionDefault
noteNo
payerNo
checksNo
errorsNo
networkNo
settledNo
warningsNo
consistentNo
transactionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"EN: Checks an x402 X-PAYMENT-RESPONSE / PAYMENT-RESPONSE settlement value against given PaymentRequirements (and optionally the payment sent): success, transaction hash format, network, payer, payTo, amount. Consistency of given data only, not on-chain truth. When: an x402 settlement response has to be matched with what was offered and paid before delivering or recording. Not for: decoding an x402 payment header and checking its structure (x402-payment-decode); nor checking the delivery binding of a Burs-IA paid receipt (separate paid Burs-IA x402 SKU verify-x402-delivery-receipt, per call in USDC on Base). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description adds critical behavioral context, such as stating that it checks 'data consistency only' and 'not on-chain' truth. It also provides essential operational limits (64 KB input, 1s latency, 1 MB result) and safety guarantees (read-only, deterministic).

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?

Despite being highly technical, the definition is structured logically using bulleted constraints for scope (When/Not for). Every sentence is essential, making it dense but maximally efficient.

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?

Given the specialized nature and complexity of payment responses, the description is exceptionally complete. It clarifies limitations (data-only), required inputs, and operational boundaries, leaving no ambiguity for the AI agent.

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?

Schema description coverage is 100%. The description adds significant semantic value by detailing what specific fields are checked (hash format, network, payer, payTo, amount) and clarifying that the check is limited to the provided data, ensuring the agent knows the depth of the verification.

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 clearly states its purpose: to check an X-PAYMENT-RESPONSE/PAYMENT-RESPONSE against PaymentRequirements. It distinguishes itself effectively from sibling tools like x402-payment-decode by specifying that it verifies data consistency, not structural format.

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?

The tool provides perfect usage guidelines, including both 'When' and 'Not for' sections. It explicitly tells the agent when to use this tool (matching response vs. requirements) and when to use alternatives (decoding a header or checking delivery status).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources