Burs-IA Utils

Revisar requisitos de pago x402

x402-requirements-lint

Read-onlyIdempotent

Revisa un cuerpo 402 de x402, un valor PAYMENT-REQUIRED, accepts[] o un PaymentRequirements (v1 o v2): campos obligatorios, redes CAIP-2, asset y payTo, montos atómicos, maxTimeoutSeconds, URL, mimeType, outputSchema y extensión Bazaar. Cuándo: hay que revisar una respuesta 402 o unos PaymentRequirements según el formato x402 antes de publicar o pagar. No para: decodificar una cabecera de pago x402 y revisar su estructura (x402-payment-decode); ni consultar en vivo la URL de un vendedor y revisar el 402 que devuelve (SKU x402 de pago aparte de Burs-IA verify-x402-seller, 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: Lints an x402 402 body, PAYMENT-REQUIRED value, accepts[] or one PaymentRequirements (v1 or v2): required fields, CAIP-2 networks, asset and payTo… [EN completo / full EN: inputSchema.description]

Input Schema

Name	Required	Description	Default
`requirements`	Yes	402 body object, base64 PAYMENT-REQUIRED header value or JSON text, accepts[] array, or one PaymentRequirements object (object or array or string; required; up to 16448 chars; up to 100 items).

Output Schema

Name	Required	Description	Default
`kind`	No
`valid`	No
`errors`	No
`entries`	No
`summary`	No
`warnings`	No
`x402_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / description

Added value: +"EN: Lints an x402 402 body, PAYMENT-REQUIRED value, accepts[] or one PaymentRequirements (v1 or v2): required fields, CAIP-2 networks, asset and payTo formats, atomic amounts, maxTimeoutSeconds, resource URL, mimeType, outputSchema and Bazaar extension shape. When: a 402 response or PaymentRequirements has to be checked against the x402 format before publishing or paying. Not for: decoding an x402 payment header and checking its structure (x402-payment-decode); nor fetching a live seller URL and checking the 402 it returns (separate paid Burs-IA x402 SKU verify-x402-seller, 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."

First observedNov 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, no-network, idempotent, non-destructive. The description reinforces these but adds genuinely new context: concrete limits (64 KB input, 1 s per call, 1 MB result) and an explicit determinism guarantee. This is valuable beyond annotations, though some phrases (solo lectura, sin red) restate what openWorldHint=false already conveys.

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?

Well front-loaded: purpose, then when, then not-for, then effects/limits, all clearly delimited. The main inefficiency is the duplicated ES and EN text, which repeats the same content and inflates length without adding new information.

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?

For a single-parameter, read-only lint tool with an output schema, this is complete: it covers what is validated, when to use it, what to avoid, side effects, determinism and hard limits. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100% and the schema already documents the single 'requirements' parameter's accepted shapes. The description adds a bit beyond the schema by specifying v1 vs v2 PaymentRequirements and the fields validated within them, giving the agent useful semantic context.

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 verb (lints/reviews) and precise resource: an x402 402 body, PAYMENT-REQUIRED value, accepts[] or PaymentRequirements (v1/v2), then enumerates the exact fields checked. This is unambiguous and clearly distinct from decoding or fetching siblings.

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 'Cuándo' section says to use it before publishing or paying, and the 'No para' section names two alternatives (x402-payment-decode for header decoding, verify-x402-seller for live URL fetching) with the condition that selects each. Nothing is left to inference.

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

All Burs-IA Utils tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?