Verified table jobs and RPC-free payment verification (Base/Ethereum). Pay per call via x402.
Scored across 11 tools
Each tool has a clearly distinct purpose: data processing (convert, deduplicate, reconcile), payment verification (verify, try_verify, batch, check_x402), status retrieval (get_job, get_verification, get_verifications), and event subscription (watch_verification). The descriptions precisely differentiate overlapping-sounding tools, e.g., free vs paid verification and singular vs batch retrieval.
Mostly consistent snake_case with verb-first patterns (get_*, verify_*, watch_*). Minor deviations: some tools are bare verbs (deduplicate, reconcile) and one uses a preposition (convert_to_csv), but overall the convention is predictable and readable.
11 tools is well within the ideal 3–15 range for a focused service. Each tool covers a specific operation or verification mode, and there is no redundancy that would suggest bloat.
The surface covers core data processing (convert, deduplicate, reconcile), payment verification (single, batch, trial, x402 receipt), status polling, and event watching. Minor gaps include no job cancellation or listing and no direct tool to create x402 offers, but these are likely out of scope for a verifier/buyer client.
Free. Cross-check a seller's signed x402 offer + receipt (offer-and-receipt extension): verifies the signatures (official x402 functions; pin the seller with sellerAddress for EIP-712 or sellerJwk for JWS), checks offer and receipt agree, and returns the exact claim to prove with verify_payment. Pass that verification's checkId to learn which side failed.
| Name | Required | Description | Default |
|---|---|---|---|
| offer | No | ||
| checkId | No | ||
| receipt | Yes | ||
| sellerJwk | No | ||
| sellerAddress | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does add real context (free, uses official x402 signature functions, pins seller via EIP-712 or JWS, returns the exact claim). However it never says whether the tool persists state or writes a checkId record, nor what a failed verification looks like, which matters for a tool whose output feeds another call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded with the cost hint and purpose before the workflow detail; every clause carries information. The trailing parenthetical nesting and the ambiguous "Pass that verification's checkId" clause slightly hurt readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-param tool with nested objects, no annotations, and no output schema, the description covers the verification logic and the handoff to verify_payment but omits the receipt/offer structure, optionality rules, and failure semantics. Adequate for orientation, incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% across five params, so the description must compensate. It usefully explains sellerAddress vs sellerJwk (EIP-712 vs JWS pinning) and checkId, but says nothing about the shape of `offer` vs `receipt`, or that only `receipt` is required, leaving the two nested object params undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: cross-check a seller's signed x402 offer + receipt, verify signatures, confirm offer and receipt agree, and return the claim. It also positions itself relative to verify_payment, so an agent can distinguish it from the verification siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The leading "Free." signals cost, and the description lays out the intended workflow: call this first, then feed the returned `claim` into verify_payment, and use checkId to diagnose which side failed. It doesn't state when-not to use it (e.g., when you already have a claim or a checkId), so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a table to CSV without changing any value; verified by round-trip. Costs $0.05 USDC (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | A string table: at most 1000 rows x 32 columns, 65536 characters total |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It does contribute two valuable traits: values are preserved exactly (round-trip verified) and each call costs $0.05 USDC via x402, which is a real precondition an agent must know before invoking. However, it says nothing about error behavior, failure handling, or how the CSV is delivered, so the behavioral picture remains partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses with zero filler: the conversion guarantee comes first, the cost second. Every fragment earns its place and nothing is repeated from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the caller receives (inline CSV text, a URL, or an async job handled by get_job). Combined with the paid x402 call, the agent cannot tell what happens after payment or how to retrieve the result. The nested table input and absent annotations also raise the disclosure bar that this short description does not meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter exists and schema description coverage is 100%, with the nested 'columns' and 'records' fields already documented in the schema (including size limits). The description adds no parameter-level detail, so the schema does the work and baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Convert a table to CSV') plus a fidelity guarantee ('without changing any value; verified by round-trip'). None of the siblings (deduplicate, get_job, reconcile) perform conversion, so the agent can route unambiguously without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the siblings or any prerequisite/alternative. The only guidance is implicit in the verb, leaving the agent to infer that this is the conversion step in a pipeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove duplicate rows by exact key, keeping the first or last, and report conflicting columns per group. Costs $0.05 USDC (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| keep | Yes | Which duplicate to keep | |
| table | Yes | A string table: at most 1000 rows x 32 columns, 65536 characters total | |
| keyColumns | Yes | Columns that together identify a row (exact string match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers real context: exact-string key matching semantics, the first/last keep policy, conflict-column reporting, and — notably — a paid-call cost of $0.05 USDC via x402, which an agent must know before invoking. It still omits whether the operation is pure/non-destructive and whether the cost is per-call or per-row, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The functional behavior is front-loaded and the pricing caveat is separated cleanly at the end where it belongs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input schema is fully documented and there is no output schema, so return-shape explanation is not strictly required. However, for a transformation tool the description only alludes to one output artifact ('conflicting columns per group') and says nothing about the deduplicated table or row counts, leaving the result contract thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (table, keyColumns, keep) are already documented in the schema. The description reinforces the 'exact key' and 'first or last' semantics but adds no format, sizing, or constraint detail beyond what the schema states; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Remove duplicate rows') plus the operative policy ('by exact key, keeping the first or last') and an output side-effect ('report conflicting columns per group'). It does not distinguish itself from the sibling 'reconcile', which an agent could plausibly confuse with a dedup/conflict-reporting operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus convert_to_csv, reconcile, or get_job, and no prerequisites or exclusions. The reader must infer applicability entirely from the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Status and (once verified) the result of a paid job, using the accessToken its paid call returned.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| accessToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the operation is free and that the result may require verification, adding useful context. However, it omits error handling, idempotency, or what happens when the job isn't verified, leaving significant gaps for a tool with no structured behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with 'Free.' leading, then the core purpose. No wasted words; appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters, no output schema, and no annotations, the description provides basic purpose and usage context. However, it lacks details about jobId, expected output, or error conditions, leaving an agent with gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the accessToken parameter as coming from the paid call, but does not explain the jobId parameter at all. Thus it only partially compensates for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns status and result of a paid job, clearly identifying the resource. It distinguishes the operation from sibling tools, which are unrelated. The verb is implicit but understood from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates when to use: with the accessToken returned by the paid call that initiated the job, and notes it is free. This provides context for invocation after a paid job, though it does not explicitly mention polling or alternatives (which are not needed given distinct siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Current state of a verification by checkId; re-checks it once its retry or challenge time has passed.
| Name | Required | Description | Default |
|---|---|---|---|
| checkId | Yes | ||
| requiredLevel | No | Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable. |
Free. Up to 50 checks at once (re-checked when due), as rows; format "csv" adds a reconciliation CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | ||
| checkIds | Yes | ||
| requiredLevel | No | Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable. |
Compare two versions of a table by key: rows added, removed and changed (with the changed columns). Costs $0.05 USDC (x402).
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | ||
| before | Yes | A string table: at most 1000 rows x 32 columns, 65536 characters total | |
| keyColumns | Yes | Columns that together identify a row (exact string match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a non-obvious trait the schema cannot express: the $0.05 USDC (x402) payment requirement. However, it omits error behavior, handling of duplicate keys, and whether the operation is purely read-only analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence: the operation and its output are front-loaded, and the cost caveat is appended last where it belongs. Zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey the return shape, and it does so compactly (added/removed/changed plus changed columns). The pricing disclosure is a bonus. Minor gaps remain around tie-breaking/duplicate keys and payment flow, but the essentials for correct invocation are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with before/after fully described and keyColumns partially. The description adds the concept of matching 'by key' and clarifies the output relates changed rows to their changed columns, but adds no format or constraint detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (compare) plus resource (two versions of a table) plus the exact output shape (rows added, removed, changed with changed columns). It is clearly distinguishable from siblings like deduplicate (which operates on one table) and convert_to_csv. An agent can select this without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The comparison semantics imply when the tool applies, but there is no explicit when-to-use, when-not-to-use, or named alternative among the siblings. Prerequisites (both tables must share key columns) are only implied by the required params. Minimum viable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: the same verification as verify_payment, limited to 3 NEW claims per client per day (asking again about a claim already checked is always free).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain of the payment | base |
| payee | Yes | Address that should have received the money (XRPL: an r... account) | |
| payer | No | Only count transfers from this address (the token holder who paid) | |
| token | No | ERC-20 contract (default: USDC on the chain). XRPL: RLUSD (default), XRP, or CURRENCY.rIssuer | |
| txHash | Yes | Transaction hash (0x + 64 hex; XRPL: 64 hex) | |
| logIndex | No | Bind to one transfer: its position within the tx's logs | |
| invoiceId | No | XRPL only: the InvoiceID (64 hex) the payment must carry; binds the answer and its signed receipt to your invoice | |
| minAmountRaw | No | Minimum amount in base units, e.g. "50000" = 0.05 USDC (default: any). XRPL: XRP drops, or millionths of an issued currency | |
| requiredLevel | No | Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable. |
Verify an on-chain payment without trusting any RPC: did this tx transfer at least this amount of a token (default USDC) to this payee, optionally from this payer? Proven by Plumb (Base via proof-backed L1 checkpoints, Ethereum via a light client, XRP Ledger via a quorum of Ripple's validator list: RLUSD, XRP or any issued currency). Bound to the exact transfer (log index); returns the proof level, how long a Base checkpoint can still be challenged, the evidence to re-check, and an Ed25519-signed receipt. Never answers not_paid while a payment is still pending; abstains (unverifiable) whenever the proof is incomplete. Costs $0.02 USDC (x402) ($0.002 for an XRP Ledger payment); asking again about the same claim costs nothing. Optional requiredLevel (releasable or not) and callbackUrl (signed events when the level is reached, the answer changes, or checking gives up).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain of the payment | base |
| payee | Yes | Address that should have received the money (XRPL: an r... account) | |
| payer | No | Only count transfers from this address (the token holder who paid) | |
| token | No | ERC-20 contract (default: USDC on the chain). XRPL: RLUSD (default), XRP, or CURRENCY.rIssuer | |
| txHash | Yes | Transaction hash (0x + 64 hex; XRPL: 64 hex) | |
| logIndex | No | Bind to one transfer: its position within the tx's logs | |
| invoiceId | No | XRPL only: the InvoiceID (64 hex) the payment must carry; binds the answer and its signed receipt to your invoice | |
| callbackUrl | No | https URL to notify (signed, retried) when requiredLevel is reached, when the answer changes, or when checking gives up | |
| minAmountRaw | No | Minimum amount in base units, e.g. "50000" = 0.05 USDC (default: any). XRPL: XRP drops, or millionths of an issued currency | |
| requiredLevel | No | Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable. |
Verify up to 25 payments in one call for $0.25 ($0.05 when every claim is on the XRP Ledger) USDC (x402): give claims (same fields as verify_payment) or csv (header: chain,txHash,payee,token,minAmountRaw,payer,logIndex,invoiceId). Claims already checked cost nothing; if all of them were, nothing is charged. Returns one row per claim (format "csv" adds a reconciliation CSV).
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | ||
| claims | No | ||
| format | No | ||
| requiredLevel | No | Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable. |
Free for a PAID check: add a callback (https) that receives signed events when requiredLevel is reached, when the answer changes, when it becomes final, or when checking gives up. The service re-checks on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| checkId | Yes | ||
| callbackUrl | Yes | ||
| requiredLevel | No | Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable. |
What should I build? x402 agent demand by category from public chain data (Base USDC + XRPL), with fake demand removed (testers, sellers paying themselves, loops; wallet fleets counted as one buyer) and gaps ranked (repeat buyers per seller). Rolling 7 days, refreshed every 2 h. Signed answer with sample transactions you can check, plus a dashboard link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
try_verify_payment1 field changedInput schema / properties / invoiceIdAdded value: +{
+ "description": "XRPL only: the InvoiceID (64 hex) the payment must carry; binds the answer and its signed receipt to your invoice",
+ "type": "string"
+}verify_payment1 field changedInput schema / properties / invoiceIdAdded value: +{
+ "description": "XRPL only: the InvoiceID (64 hex) the payment must carry; binds the answer and its signed receipt to your invoice",
+ "type": "string"
+}get_verification2 fields changedInput schema / properties / requiredLevel / descriptionPrevious value: -"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable."New value: +"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable."Input schema / properties / requiredLevel / enumPrevious value: -[
- "tee_attested",
- "zk_proven",
- "resolved",
- "finalized"
-]New value: +[
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized",
+ "unl_quorum"
+]get_verifications2 fields changedInput schema / properties / requiredLevel / descriptionPrevious value: -"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable."New value: +"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable."Input schema / properties / requiredLevel / enumPrevious value: -[
- "tee_attested",
- "zk_proven",
- "resolved",
- "finalized"
-]New value: +[
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized",
+ "unl_quorum"
+]try_verify_payment7 fields changedInput schema / properties / chain / enumPrevious value: -[
- "base",
- "ethereum"
-]New value: +[
+ "base",
+ "ethereum",
+ "xrpl"
+]Input schema / properties / minAmountRaw / descriptionPrevious value: -"Minimum amount in base units, e.g. \"50000\" = 0.05 USDC (default: any)"New value: +"Minimum amount in base units, e.g. \"50000\" = 0.05 USDC (default: any). XRPL: XRP drops, or millionths of an issued currency"Input schema / properties / payee / descriptionPrevious value: -"Address that should have received the money"New value: +"Address that should have received the money (XRPL: an r... account)"Input schema / properties / requiredLevel / descriptionPrevious value: -"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable."New value: +"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable."Input schema / properties / requiredLevel / enumPrevious value: -[
- "tee_attested",
- "zk_proven",
- "resolved",
- "finalized"
-]New value: +[
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized",
+ "unl_quorum"
+]Input schema / properties / token / descriptionPrevious value: -"ERC-20 contract (default: USDC on the chain)"New value: +"ERC-20 contract (default: USDC on the chain). XRPL: RLUSD (default), XRP, or CURRENCY.rIssuer"Input schema / properties / txHash / descriptionPrevious value: -"Transaction hash (0x + 64 hex)"New value: +"Transaction hash (0x + 64 hex; XRPL: 64 hex)"verify_payment7 fields changedInput schema / properties / chain / enumPrevious value: -[
- "base",
- "ethereum"
-]New value: +[
+ "base",
+ "ethereum",
+ "xrpl"
+]Input schema / properties / minAmountRaw / descriptionPrevious value: -"Minimum amount in base units, e.g. \"50000\" = 0.05 USDC (default: any)"New value: +"Minimum amount in base units, e.g. \"50000\" = 0.05 USDC (default: any). XRPL: XRP drops, or millionths of an issued currency"Input schema / properties / payee / descriptionPrevious value: -"Address that should have received the money"New value: +"Address that should have received the money (XRPL: an r... account)"Input schema / properties / requiredLevel / descriptionPrevious value: -"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable."New value: +"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable."Input schema / properties / requiredLevel / enumPrevious value: -[
- "tee_attested",
- "zk_proven",
- "resolved",
- "finalized"
-]New value: +[
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized",
+ "unl_quorum"
+]Input schema / properties / token / descriptionPrevious value: -"ERC-20 contract (default: USDC on the chain)"New value: +"ERC-20 contract (default: USDC on the chain). XRPL: RLUSD (default), XRP, or CURRENCY.rIssuer"Input schema / properties / txHash / descriptionPrevious value: -"Transaction hash (0x + 64 hex)"New value: +"Transaction hash (0x + 64 hex; XRPL: 64 hex)"verify_payments_batch2 fields changedInput schema / properties / requiredLevel / descriptionPrevious value: -"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable."New value: +"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable."Input schema / properties / requiredLevel / enumPrevious value: -[
- "tee_attested",
- "zk_proven",
- "resolved",
- "finalized"
-]New value: +[
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized",
+ "unl_quorum"
+]watch_verification2 fields changedInput schema / properties / requiredLevel / descriptionPrevious value: -"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable."New value: +"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable."Input schema / properties / requiredLevel / enumPrevious value: -[
- "tee_attested",
- "zk_proven",
- "resolved",
- "finalized"
-]New value: +[
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized",
+ "unl_quorum"
+]what_should_i_buildcheck_x402_receiptget_verificationsverify_payments_batchget_verification1 field changedInput schema / properties / requiredLevelAdded value: +{
+ "description": "Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable.",
+ "enum": [
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized"
+ ],
+ "type": "string"
+}try_verify_payment1 field changedInput schema / properties / requiredLevelAdded value: +{
+ "description": "Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable.",
+ "enum": [
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized"
+ ],
+ "type": "string"
+}verify_payment2 fields changedInput schema / properties / callbackUrlAdded value: +{
+ "description": "https URL to notify (signed, retried) when requiredLevel is reached, when the answer changes, or when checking gives up",
+ "maxLength": 500,
+ "type": "string"
+}Input schema / properties / requiredLevelAdded value: +{
+ "description": "Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable.",
+ "enum": [
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized"
+ ],
+ "type": "string"
+}watch_verificationget_verificationtry_verify_paymentverify_paymentconvert_to_csvdeduplicateget_jobreconcilePay-per-call x402 tools: crypto data, web fetch/extract, x402 checks. MCP pays USDC on Base only.
Pay-per-call x402 Base/Ethereum: prices, DEX prices, ENS/Basenames, gas, tokens, balances, txs.
Pay-per-call onchain reads (Base, Ethereum, Gnosis), token verdicts and LLM chat over x402 USDC
Pay-per-call agent tools via x402 (USDC on Base): chat, prices, funding, RNG. No account or keys.
Add one secure layer between your agents and this server.