Verified table jobs and RPC-free payment verification (Base/Ethereum). Pay per call via x402.
Scored across 14 tools
Most tools target clearly distinct actions (table transforms vs. payment verification vs. credential status vs. market data), and the detailed descriptions help. However, the verification cluster (verify_payment, try_verify_payment, verify_payments_batch, get_verification(s), watch_verification, check_x402_receipt) has overlapping-sounding names where the sole differentiator between try_verify and verify is a free-tier quota, which risks misselection.
Names are uniformly snake_case and mostly verb_noun (verify_payment, get_verification, prove_xrpl_transaction, convert_to_csv). Minor deviations exist—verb-only names (reconcile, deduplicate), noun-only (credential_status), and a full-phrase name (what_should_i_build)—but the convention is predictable enough to navigate.
14 tools is well within a reasonable range for a server offering both table utilities and a payment-verification pipeline. Each tool appears to earn its place, with batching, status, and callback variants justified by the paid verification workflow.
The surface covers the core verification lifecycle (single, batch, free try, status by id, bulk status, watch/callback, signed receipts) plus XRPL proof, credential standing, table transforms, job status, and demand data. Minor gaps remain—no explicit create/update for tables or a way to cancel/clean up registered watchers/jobs—but core workflows are covered.
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.
Free. The exchange's on-ledger ProvenPayer credential (XLS-70): issued to an XRPL account after 2 settled, Plumb-proven payments to the house; readable by any seller with ledger_entry. Returns the account's standing, the issued credential (with the CredentialCreate hash, provable with plumb-xrpl), how to accept it, and the challenge format for the holder unlock.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose cost ('Free'), read access ('readable by any seller with ledger_entry'), and the full return surface (standing, issued credential with CredentialCreate hash, acceptance steps, unlock challenge). It omits auth/rate-limit specifics and never explicitly confirms read-only behavior, keeping it from 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?
It is front-loaded with the 'Free' cost signal and then packs purpose, credential mechanics, and return contents into two dense sentences with little waste. The jargon makes it heavy, but nothing is redundant.
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 annotations and no output schema, the description usefully enumerates return contents, which is the main gap it needed to fill. However, it leaves the input parameter's semantics (optional account, default behavior) and any access/prerequisite conditions unexplained for a fairly specialized credential tool.
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?
The single 'account' parameter has 0% schema description coverage, and the description never explains whose account it is, that it is optional (required=0), or what happens when it is omitted. For a schema with an undocumented parameter, the description fails to compensate.
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 resource (the ProvenPayer credential / XLS-70 standing) and what is returned, so an agent knows this reports credential state rather than performing a payment or verification. It does not explicitly differentiate itself from siblings like get_verification or prove_xrpl_transaction, and the jargon (Plumb-proven, ledger_entry) assumes domain familiarity, so it falls short of a 5.
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?
Only implicit signals exist: 'Free' and 'readable by any seller with ledger_entry' hint at cost and access, but there is no explicit statement of when to call this versus siblings such as get_verification or prove_xrpl_transaction. No exclusions or alternatives are named.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose two useful traits: the call is free and it may internally re-check once a retry/challenge time has elapsed. It does not mention auth requirements, whether the re-check has side effects beyond the read, rate limits, or what the state payload looks like.
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 compact statements with the cost attribute ('Free.') front-loaded and the core purpose immediately following. No wasted words, though the semicolon clause packs two ideas into one sentence.
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 multi-chain verification-status tool with no output schema and no annotations, the description is serviceable but thin: it omits return payload shape, the meaning of releasability relative to requiredLevel, and any auth/ownership requirements. The 'free' and re-check details partially compensate.
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 50%. checkId is named in the description but given no extra meaning beyond the schema, and requiredLevel — the parameter whose ordering across Base/Ethereum/XRPL determines releasability — is documented only in the schema, not reinforced or clarified in the description. Baseline 3 for a mid-coverage schema fits.
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+resource: retrieving the current state of a verification identified by checkId. It also discloses that the check is re-run once a retry/challenge window has passed, which sharpens what the call actually returns. It does not explicitly distinguish itself from siblings get_verifications or watch_verification, so it stops short of 5.
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?
Usage is only implied: 'current state ... by checkId' plus the re-check timing signals a polling pattern for a single verification. It never says when to prefer this over watch_verification (streaming) or get_verifications (bulk), nor states prerequisites such as owning the check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose real behavior: cost ('Free'), batch cap (50), and that checks are 're-checked when due', implying a possible side effect, plus the CSV reconciliation output. It omits auth requirements, rate limits, and what 're-checking' actually mutates, so context is 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 dense clauses with zero filler; the cost and batch constraint are front-loaded. The telegraphic style is efficient, though 'Free.' as a fragment and terse phrasing border on cryptic.
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?
No annotations, no output schema, and 3 parameters at 33% coverage leave the description as the main information source, yet it omits what a verification is, auth needs, and the return shape beyond 'rows'. For a batch tool that may trigger re-checks, this is inadequate.
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 only 33% (requiredLevel is documented in-schema; checkIds and format are not). The description partially compensates by explaining that format "csv" adds a reconciliation CSV and that the count is capped at 50, but it says nothing about what checkIds represent or how requiredLevel interacts with the response.
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 conveys a batch retrieval of 'checks ... as rows' with a 50-item scope, and the name get_verifications anchors the resource. However, it never states plainly what is being retrieved (verification statuses/results) and does not differentiate itself from the singular sibling get_verification. Purpose is inferable but not explicit.
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?
'Free' and 'Up to 50 checks at once' imply this is the economical batch path, which hints at when to prefer it. But there is no explicit when-to-use statement and no routing to alternatives such as get_verification for a single item or verify_payments_batch. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prove any XRP Ledger transaction without trusting a server: validator-list quorum, hash links, rebuilt tx tree. Returns full fields, metadata (balances, escrows, channels, credentials as of the tx), quorum evidence and a signed receipt. Unvalidated tx keeps your payment.
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It discloses the verification mechanism and return payload well, and hints that an unvalidated tx 'keeps your payment,' but it omits the safety profile: whether the call is read-only/side-effect free, whether it incurs a payment or authorization, and latency/cost traits.
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 front-loaded sentences with minimal waste; the mechanism comes first, then the return contents. The parenthetical catalog of metadata is long but each item is informative.
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 appropriately enumerates the return shape (full fields, metadata, quorum evidence, signed receipt) and describes the verification basis. For a single-parameter tool the input side is adequately covered, leaving only the review of usage conditions and auth/cost behavior as gaps.
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 for the single txHash parameter. It identifies that an XRP Ledger transaction is the input, but says nothing about the hash format (the schema's 64-hex pattern) or optional 0x prefix, so it adds only marginal meaning here.
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 (prove) and resource (XRP Ledger transaction) and adds the distinguishing mechanism (validator-list quorum, hash links, rebuilt tx tree). The XRP Ledger specificity separates it from the generic verify_payment/verify_payments_batch siblings.
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?
'without trusting a server' implies the context of use (trust-minimized verification), but the description never states when to prefer it over verify_payment, try_verify_payment, or the batch variant, nor any exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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). Holders of the exchange's on-ledger ProvenPayer credential get more: pass xrplProof (see credential_status).
| 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 | |
| xrplProof | No | ||
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningfully: it discloses a concrete rate limit (3 new claims per client per day), a free re-query carve-out, and a credential-gated higher tier. It does not describe the response format or receipt/auth requirements for the proof path, but the quota and pricing behavior is genuinely beyond what structured fields provide.
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 dense sentences, front-loaded with the key differentiator ('Free:') and the quota constraint before the credential upsell. Every clause earns its place; only minor compression is possible.
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 10-parameter tool with a nested object and no output schema, the description covers pricing/quota and the proof path but says nothing about return values or the signed-receipt behavior, deferring entirely to 'the same verification as verify_payment.' That deferral only works if the agent already knows the sibling, leaving a real gap.
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 90%, so the baseline is 3, but the description adds real meaning the schema lacks for xrplProof: it explains why/when to pass it (ProvenPayer credential holders) and points to credential_status. The remaining parameters are already well documented in the schema.
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+resource ('verification') and immediately anchors it to its sibling: 'the same verification as verify_payment.' The pricing/quota qualifier ('Free', 'limited to 3 NEW claims') makes it instantly distinguishable from verify_payment without opening either 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?
Clearly signals when this tool is the right pick (free tier, re-checks always free) and routes credential holders to the xrplProof path with a cross-reference to credential_status. It stops short of explicitly stating the alternative condition (e.g. 'use verify_payment when you exceed the daily quota'), leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discharges it well: it discloses per-chain proof mechanisms, the reclaimable challenge window on Base, that results include re-checkable evidence and an Ed25519-signed receipt, that it will never answer not_paid for a still-pending payment, and that it abstains when proof is incomplete. Pricing ($0.02 / $0.002, free on repeat claims) and the x402 payment requirement are also surfaced.
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?
One dense paragraph, but front-loaded with the core question and tightly ordered: trust model, proof mechanics, return contents, semantics, cost, optional params. Nearly every clause carries information; it is long only because the tool is genuinely complex.
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 10-parameter tool with no output schema and no annotations, the description fills the gaps: it names what is returned (proof level, challenge window, evidence, signed receipt), the cost model, and the abstention/pending semantics. Nothing an agent needs to decide and invoke correctly appears missing.
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 100%, so the schema already documents every parameter, setting the baseline at 3. The description adds only marginal value here (default token USDC, that requiredLevel is optional and drives a 'releasable' answer, callbackUrl fires on the three specified events), essentially paraphrasing what the schema already states.
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 (verify an on-chain payment) with the distinctive qualifier 'without trusting any RPC', and frames the exact question it answers (did this tx transfer at least this amount to this payee). An agent can separate it from try_verify_payment or verify_payments_batch by the trust model and proof narrative alone.
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?
Usage context is implied rather than stated: 'asking again about the same claim costs nothing' hints at idempotent re-checking, and the pending/abstain rules explain when an answer is meaningful. But it never names when to prefer this over the sibling try_verify_payment (likely a dry run) or verify_payments_batch, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the x402/USDC payment model, exact pricing tiers, a caching rule (already-checked claims are free), and the return shape (one row per claim). It omits error/partial-failure behavior and any rate or size limits beyond the 25-claim cap.
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 dense single paragraph that front-loads cost and capacity before inputs and outputs. Every sentence adds information, though the pricing parenthetical is slightly awkward to parse.
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 explain returns and does ('one row per claim', plus reconciliation CSV). Inputs, pricing, and return shape are covered; missing only failure-mode behavior and guidance on choosing between the batch and single-claim siblings.
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 only 25% (only requiredLevel is documented), but the description compensates substantially: it gives the exact CSV header order for `csv` and equates `claims` to verify_payment's fields, and explains that `format=csv` adds a reconciliation CSV. Only the requiredLevel proof-level interaction is left entirely to the schema.
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 with scope: 'Verify up to 25 payments in one call.' It distinguishes itself from the single-payment sibling by referencing 'same fields as verify_payment', so an agent can see this is the batch variant without opening either 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?
Batching and cost signals ('already checked cost nothing; if all of them were, nothing is charged') imply when this is economical, but the description never explicitly says to prefer this over verify_payment for multiple claims or when to fall back to the single-call tool. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose useful behavior: the payload is signed, the feature is free for a paid check, re-checking is automatic, and the four event triggers. However, it omits re-registration semantics, retry/failure behavior, and any permission requirements.
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 sentences with no padding, and the event list is front-loaded. The opening 'Free for a PAID check:' is slightly cryptic and delays the actual action, which keeps it from a 5.
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 webhook-registration tool with no annotations, no output schema, and a partially documented schema, the description covers triggers, cost, and payload signing. It still leaves gaps around checkId usage, lifecycle of an existing watch, and error behavior, so it is adequate but not complete.
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 33%: only requiredLevel is documented in the schema, and its enum is well explained with per-chain ordering. The description adds that callbackUrl must be https, which compensates partially, but checkId is never explained and callbackUrl semantics beyond https remain unclear.
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 a specific action on a specific resource: registering an https callback for a verification check to receive signed events. It is clearly distinguishable in spirit from polling siblings like get_verification, but it never names or contrasts them explicitly, so it falls short of a 5.
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?
Usage is only implied: 'The service re-checks on its own' suggests this is the push-based alternative to polling, and the event list hints at when the callback fires. There is no explicit when-to-use statement, no condition for choosing this over get_verification or try_verify_payment, and no prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it discloses data provenance (public chain data on Base USDC + XRPL), the de-noising methodology (testers, self-paying sellers, loops removed; wallet fleets collapsed to one buyer), and freshness (rolling 7 days, refreshed every 2 h). It does not address auth requirements, rate limits, or failure behavior, 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?
Front-loaded with the core purpose, then layers provenance, filtering rules, freshness, and verifiability in three tight sentences with no filler. The leading rhetorical question is slightly gimmicky but doubles as a compact statement of intent.
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 and no parameters, the description must explain what comes back, and it does: a signed answer with checkable sample transactions plus a dashboard link. The methodology and freshness window are also covered, leaving only operational details (latency, error modes, auth) unstated.
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?
The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify or compensate for. Schema coverage is reported at 100% and the input schema is an empty object, consistent with the description.
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 names a specific resource (x402 agent demand by category from Base USDC + XRPL chain data) and a specific output (ranked gaps by repeat buyers per seller), which is far more concrete than the question-form name suggests. It is clearly distinguishable from the verification/reconciliation siblings, though it never explicitly contrasts itself with them.
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?
Usage is strongly implied by the framing question 'What should I build?' and by the emphasis on ranked gaps, so an agent can infer this is a discovery/decision tool rather than a payment-checking tool. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
credential_statustry_verify_payment1 field changedInput schema / properties / xrplProofAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "account": {
+ "pattern": "^r[1-9A-HJ-NP-Za-km-z]{24,34}$",
+ "type": "string"
+ },
+ "publicKey": {
+ "pattern": "^[0-9A-Fa-f]{66}$",
+ "type": "string"
+ },
+ "signature": {
+ "pattern": "^[0-9A-Fa-f]{64,160}$",
+ "type": "string"
+ },
+ "timestamp": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "account",
+ "publicKey",
+ "timestamp",
+ "signature"
+ ],
+ "type": "object"
+}prove_xrpl_transactiontry_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_jobreconcile34 pay-per-call AI and data tools over x402; USDC on Base; no API keys.
Pay-per-call onchain reads (Base, Ethereum, Gnosis), token verdicts and LLM chat over x402 USDC
Pay-per-call onchain reads (Base, Ethereum, Gnosis), token verdicts and LLM chat over x402 USDC
Signed x402 attestations and bounty-packet preflight checks, paid per call in USDC on Base.
Add one secure layer between your agents and this server.
