Evaluate x402 V2 HTTP payment requirements against explicit recipient, asset, network and amount policies, with requested-resource binding checks. Returns pay, review or do_not_pay with explanations. Public offline tools require no account, wallet or API key. Does not sign, send payments or verify on-chain settlement. Documentation: https://settlens.com/mcp — Reproducible examples: https://settlens.com/blog/check-x402-payment-policy
Scored across 6 tools
Each tool targets a distinct artifact: policy evaluation (evaluate_payment_requirements), EVM signatures (verify_payment_signature), Solana transactions (verify_solana_transaction), attestations (verify_attestation), and reports (verify_report). The payment-related tools could momentarily be confused, but descriptions sharply separate chains and purposes. list_checks is clearly a meta/explanatory tool.
All six tools use consistent snake_case verb_noun form (evaluate_payment_requirements, list_checks, verify_attestation, verify_payment_signature, verify_report, verify_solana_transaction). The verbs vary appropriately to reflect distinct actions, and there is no mixing of conventions.
Six tools is well-scoped for an offline x402 verification server, with each tool covering a distinct verification concern. No tool feels redundant or out of place.
The surface covers the core verification lifecycle across EVM, Solana, attestations, and reports, plus a discovery tool for check ids. On-chain state, settlement, and replay checks are explicitly declared out of scope, which are the main gaps an agent might otherwise want.
Call this on every HTTP 402 response BEFORE paying. Give it the PAYMENT-REQUIRED header value, the URL you requested and your spending policy (pay_to, assets, networks and max_amount, optionally schemes). Offline: it decodes and validates the x402 V2 payment request with the official @x402/core schema, checks that it is bound to the URL you requested, validates every payment option (scheme, CAIP-2 network, amount, asset, payTo, timeout window) and applies your policy to each option, since you pay with only one. Returns decision 'pay', 'review' (ask the human first) or 'do_not_pay' (never pay), the reasons, and the payment options that satisfy your policy (acceptable). It does not check balances, settlement or what the token at asset does, and it never pays.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | No | Your spending policy, applied to each advertised payment option. Set at least pay_to, assets, networks and max_amount: without all four, the decision can never be 'pay'. | |
| resource_url | No | The exact URL you requested. Strongly recommended: without it the resource binding cannot be confirmed and the decision is at best 'review'. | |
| payment_required | Yes | The raw PAYMENT-REQUIRED response header value (Base64 JSON), the same object as a JSON string, or the decoded object. |
| Name | Required | Description |
|---|---|---|
| checks | Yes | |
| reasons | Yes | |
| summary | Yes | |
| decision | Yes | |
| acceptable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the evaluation is offline, uses the official @x402/core schema, enforces URL binding, validates each payment option (scheme, CAIP-2 network, amount, asset, payTo, timeout), applies the policy per option because only one is paid, and explicitly never pays. It also discloses a degradation path (missing resource_url caps the decision at 'review').
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?
The imperative action and timing are front-loaded in the first sentence, followed by inputs, then behavior, then the return contract and exclusions. It is dense and mostly earns its length, though the long middle sentence enumerating validated fields is heavier than needed.
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 an output schema present, the description still summarizes the return contract (decision values, reasons, acceptable options) without over-explaining. For a 3-parameter tool with nested policy objects and full schema coverage, an agent has everything needed to call it correctly and interpret the result.
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% and each policy field (pay_to, assets, networks, max_amount, schemes) is documented in the schema with examples and matching rules. The description restates which inputs to supply and adds the rationale that the policy is applied to each option 'since you pay with only one,' but adds no syntax or format 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?
The description names a specific verb and resource ('decodes and validates the x402 V2 payment request') and states the exact decision output ('pay', 'review', 'do_not_pay'). It is clearly distinguishable from siblings like verify_payment_signature or verify_attestation, which verify artifacts rather than evaluate requirements against a policy.
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 trigger is explicit and well-placed: 'Call this on every HTTP 402 response BEFORE paying.' It also scopes out adjacent concerns ('does not check balances, settlement or what the token at asset does, and it never pays'). It does not name alternative tools or say when NOT to call it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the checks Settlens can report, with what each verifies, why it matters and how to fix it. Use it to explain a check id returned by another tool.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Only return checks of this mode: offline (from the PaymentRequired content), passive (live request), active (authorized probe) or facilitator. | |
| category | No | Only return checks of this category. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| checks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds that results include remediation guidance, which is useful, but says nothing about filtering behavior or result ordering beyond what the schema and output schema already carry.
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 tightly written sentences with no filler; the purpose leads and the usage cue follows. Every clause earns its place.
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 an output schema and complete annotations, the description only needs to convey purpose and when to call it, which it does. A brief note that results can be narrowed by mode or category would fully close the loop, but nothing essential is 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 description coverage is 100% with both enums fully documented, so the schema does the heavy lifting. The description never mentions the mode/category filters, so it adds no meaning beyond the structured fields — baseline 3.
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 ('Lists the checks Settlens can report') and details the content of each entry (what it verifies, why it matters, how to fix it). It is clearly distinct from the verify_* siblings, though it names no sibling explicitly to route against.
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?
'Use it to explain a check id returned by another tool' gives an explicit triggering condition and implicitly positions it against the verify_* tools. No when-not or exclusion guidance is given, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offline check of a Settlens evidence attestation: verifies its ed25519 signature and, when the report is supplied, that the report is intact and is the one the attestation covers. A valid signature only proves the attestation was signed by the key it embeds; pass expected_public_key to require a specific signer.
| Name | Required | Description | Default |
|---|---|---|---|
| report | No | Optional Settlens JSON report the attestation should cover. | |
| attestation | Yes | The attestation JSON object. | |
| expected_public_key | No | Optional signer the attestation must come from: an ed25519 public key PEM, or the 0x-prefixed 32-byte hex key printed by evidence keygen. |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| reasons | Yes | |
| publicKey | Yes | |
| attestedAt | Yes | |
| reportMatches | Yes | |
| signatureValid | Yes | |
| publicKeyMatches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real context: the check is offline, and crucially warns that a valid signature only proves signing by the embedded key, not by a trusted signer. This security caveat is exactly the kind of behavioral disclosure an agent needs. It doesn't describe return shape or failure modes, but an output schema exists.
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?
Three sentences, front-loaded with the core action, then the conditional report behavior, then the signer requirement. Every sentence carries non-redundant information and nothing is padded.
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 verification tool with good annotations, full schema coverage, and an output schema, the description covers what is checked, the optional parameters' roles, and the trust caveat. An agent has everything it needs to call it correctly.
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%, setting a baseline of 3, but the description adds semantic meaning beyond the schema: it explains the report/attestation coverage relationship and the security implication of expected_public_key. That elevates it above the baseline.
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 ('verifies' a 'Settlens evidence attestation') and names the exact cryptographic operation (ed25519 signature check plus report integrity/coverage). It is clearly distinguishable from siblings like verify_report and verify_payment_signature because it defines the attestation-specific scope.
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?
Gives conditional usage: the report parameter is only relevant 'when the report is supplied', and expected_public_key should be passed 'to require a specific signer'. It does not explicitly name alternative sibling tools or state when-not to use this one, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offline cryptographic check of an x402 'exact' EVM payment authorization (EIP-3009 TransferWithAuthorization, EIP-712). Rebuilds the EIP-712 domain from the requirement (extra.name, extra.version, asset, chain id from the eip155 network), recovers the signer and checks it equals authorization.from, that the transfer is bound to the requirement's payTo, amount and asset, and that the time is inside validAfter/validBefore. It does NOT check on-chain balances, nonce reuse/replay or settlement, and needs no RPC.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Time to check the authorization window against, as an ISO 8601 string or Unix seconds. Defaults to the current time. | |
| payload | Yes | The payment payload { signature, authorization }, a full PaymentPayload object, or the raw Base64 PAYMENT-SIGNATURE header value. | |
| requirement | Yes | The payment requirement (one accepts entry) the payment was made for: scheme, network (eip155:<chainId>), amount, asset, payTo, maxTimeoutSeconds, extra { name, version }. |
| Name | Required | Description |
|---|---|---|
| fresh | No | |
| scheme | Yes | |
| reasons | Yes | |
| verified | Yes | |
| checkedAt | Yes | |
| recovered | No | |
| amountBound | No | |
| recipientBound | No | |
| signatureValid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond that: it states the check is fully offline, requires no RPC, describes the exact validation steps (domain rebuild, signer recovery, payTo/amount/asset binding, validAfter/validBefore window), and enumerates what it deliberately does not verify. That is genuinely useful behavioral context for trusting the result.
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?
Three sentences, front-loaded with the scope, then the validation logic, then the exclusions. Every clause carries information an agent needs and nothing is padded.
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 an output schema present, the description need not document return values; it covers the input contract, the verification semantics, and the boundaries of what a positive result means. Nothing material is missing 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 coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining how 'requirement' fields are consumed (extra.name/extra.version/asset/chain id from eip155 are used to rebuild the EIP-712 domain) and by noting that 'payload' can be an object or a raw Base64 PAYMENT-SIGNATURE header. It does not explain the 'now' override beyond 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?
The description names a precise verb+resource ('Offline cryptographic check of an x402 exact EVM payment authorization') and pins the standard (EIP-3009 TransferWithAuthorization, EIP-712). This cleanly separates it from the EVM-agnostic and Solana siblings (verify_solana_transaction, verify_attestation) without needing to open 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?
It gives strong context: use this for offline signature verification with no RPC, and it explicitly excludes balance, nonce/replay and settlement checks, which tells the agent when NOT to rely on it. It stops short of naming an alternative tool to use for those excluded concerns, so it is not a full when/when-not/alternative statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offline check that a Settlens JSON report has not been modified since it was generated, by recomputing its deterministic SHA-256 integrity digest.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | The complete Settlens JSON report. |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| actual | Yes | |
| reason | Yes | |
| expected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world behavior, so the safety profile is covered. The description adds genuine extra context: the check is performed offline and the verification is a deterministic digest recomputation, telling the agent the operation is pure and repeatable with no external calls.
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 sentence, front-loaded with the scope (offline check) and immediately followed by the resource and mechanism. No filler, no restating of the tool name or title.
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?
An output schema exists, so return values need not be explained, and the single nested-object parameter is fully described in the schema. The description is nearly complete for a one-input verification tool, though it could note what a 'Settlens JSON report' is or where one comes from.
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% for the single `report` parameter, so the schema already carries the burden. The description only adds the implication that the entire report object is hashed, without specifying format, size limits, or what constitutes a malformed report — 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?
States a specific verb (verify/offline check), a specific resource (a Settlens JSON report), and the mechanism (recomputing the deterministic SHA-256 integrity digest). This clearly distinguishes it from sibling verifiers such as verify_attestation, verify_payment_signature, and verify_solana_transaction, which operate on different artifacts.
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 word "Offline" implies the operating context (no network/chain access needed), which helps an agent choose it over the transaction/signature verifiers, but the description never states when to use this versus its siblings or what prerequisites (e.g., a previously obtained report) are required. 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.
Offline check of every ed25519 signature of a Base64 Solana transaction (legacy or versioned), for example payload.transaction of an x402 Solana payment. Each required signer slot is checked against its signer key. An x402 exact SVM payload is partially signed: the client signs, and the facilitator adds the fee-payer signature at settlement, so empty (all-zero) slots are reported as pendingSigners (feePayerPending is true when the fee payer has not signed yet) rather than as failures. verified is true only when at least one signature is present, every present signature is valid and the number of signature slots matches the message header. Transactions larger than 1232 bytes are refused. An optional reviewed requirement adds conservative offline TransferChecked inspection in payment: mint, merchant ATA, exact amount, signed client, sponsor isolation, compute caps and memo. payment.verified is separate from signature-only verified. Unsupported programs, unresolved address lookup tables and Token-2022 extensions cannot be verified offline. It does NOT check account state, balances, execution, replay or settlement.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | No | ||
| requirement | No | Reviewed exact SVM terms for optional conservative instruction inspection; never execution proof. | |
| transaction | Yes | The Base64-encoded serialized Solana transaction. |
| Name | Required | Description |
|---|---|---|
| scheme | Yes | |
| payment | No | |
| reasons | Yes | |
| signers | No | One entry per signature slot, in order (slot 0 is the fee payer), with its base58 publicKey and status: valid, invalid or pending. |
| version | No | |
| feePayer | Yes | |
| verified | Yes | |
| pendingSigners | No | |
| signatureCount | No | |
| signatureValid | Yes | |
| feePayerPending | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses the pendingSigners/feePayerPending semantics of partially signed payloads, the exact conditions for verified=true, the 1232-byte size limit, and offline-verification limits (lookup tables, Token-2022 extensions). This is exactly the kind of behavioral context an agent cannot infer from structured fields.
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?
Long but front-loaded with the core purpose in the first clause, and each sentence carries distinct information (pending-signer handling, verified criteria, size refusal, reviewed inspection, limitations). Some sentences are dense and could be split, but there is no filler or repetition.
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 an output schema present, return-format detail is unnecessary, and annotations cover the safety profile. The description still supplies the scope, edge cases, refusal criteria, and explicit non-goals, so an agent has everything needed to invoke and interpret it correctly.
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% and only the transaction field is self-described; the description compensates by explaining the optional reviewed requirement (mint, merchant ATA, exact amount, signed client, sponsor isolation, compute caps, memo) and clarifying that payment.verified is distinct from signature-only verified. It adds real meaning over the schema, though it doesn't map every field (e.g. maxPriorityFeeMicroLamports) explicitly.
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: "Offline check of every ed25519 signature of a Base64 Solana transaction (legacy or versioned)". It situates the tool in the x402 Solana payment flow and clearly separates itself from siblings like verify_payment_signature by scoping to signature verification only.
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?
Explicitly frames the use case (x402 exact SVM payloads, partially signed) and draws a strong negative boundary: "It does NOT check account state, balances, execution, replay or settlement." It stops short of naming which sibling handles those cases, so routing to alternatives is implied rather than directed.
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.
evaluate_payment_requirementslist_checksverify_attestationverify_payment_signatureverify_reportverify_solana_transaction
Add one secure layer between your agents and this server.