vet402

Overview Schema Source Related Servers Discussions Admin

pay_if_trusted

Gates an x402 payment on vet402's ALLOW decision, stopping before any signature exists when trust checks refuse the payee.

Instructions

Pay an x402 resource ONLY if vet402's decision allows it. Unlike check_resource_decision, which returns a verdict for you to act on, this tool holds the signer: on anything other than ALLOW the payment module is never even loaded, so no signature can exist.

Read these two fields and nothing else to know what happened:

decision: PAID | REFUSE | FAILED
safe_to_pay: boolean (always equals decision === PAID)

REFUSE means it stopped BEFORE a signature existed; refuse_reasons carries the server's own reason_codes unchanged, plus one of evidence_unavailable, payee_recommendation_not_allow, payment_target_unknown, payer_not_configured, payee_mismatch, chain_or_asset_mismatch, price_above_ceiling (the 402 asks more than maxPerTxUsd), price_above_declared (the 402 asks more than the amountUsd you named). FAILED means it signed and the seller did not settle — signed and nonce are returned, not hidden, because the authorization stays live until validBefore.

settlement is at most settle_claimed: the seller's PAYMENT-RESPONSE header is a claim, not an on-chain confirmation. measurement carries the /decision body verbatim, including evidence[] with each row's own source (vet402 or subgraph) so you can check which ledger answered. A subgraph row also carries subgraphId, block.number, deployment and queriedAt - the proof it was read from a live index. Counts on rows from different sources are not added together.

A seller outside vet402's catalogue (/decision answers 404) is not a dead end: when resource is given, the 404 is handed to the SDK, which judges from the 402's payTo, the payee score for that address and your evidence floors (decision_record.verdict_source payee_score or caller_policy, reason_codes resource_uncatalogued). The same boundary holds there: payTo must equal payee, a BLOCK payee score refuses even with requireVet402Allow:false. Without resource a 404 refuses with evidence_unavailable - there is nothing to judge from.

Omit resource/payee/amountUsd to get the pre-payment checks alone (Graph-key presence, degraded, the server's caller_policy, ALLOW): it refuses with payment_target_unknown, and the evidence floors and The Graph read are not evaluated (they live inside the SDK's payOrRefuse, which is only reached with a payment target). Paying also requires VOUCH_PAYER_PRIVATE_KEY in this server's env and viem installed; without them resource/payee/amountUsd are dropped before the SDK, the same checks run, and the tool refuses with payer_not_configured (floors not evaluated on this path either).

policy is passed to the SDK's payOrRefuse unchanged. policy.evidence.source "subgraph" or "both" reads The Graph's x402 Base subgraph through the Graph Gateway and puts that read on decision_record.evidence[] as its own row (source subgraph, receipts, block.number). The Gateway key is read from GRAPH_API_KEY in this server's env, never from tool input; without it the tool refuses with graph_key_not_configured before reading anything. policy.requireVet402Allow:false waives only a WARN, and only if every declared floor (minSubgraphReceipts / minL1Deliveries) is met - BLOCK and degraded still refuse. decision_record then carries verdict_source caller_policy and policy_override (what was waived, which floors were met with which numbers).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "resourceId": "<resourceId>"
    },
    "name": "pay_if_trusted"
  }
}

Input Schema

Name	Required	Description
`payee`	No	Address you already expect to be paid; the 402's payTo must match it
`method`	No	HTTP method of the resource (default GET; The Graph's x402 endpoint is POST)
`policy`	No	Caller's own rule; forwarded to payOrRefuse unchanged. The Graph key is NOT an input - set GRAPH_API_KEY in the server env.
`resource`	No	URL that answers 402. Required to actually pay.
`amountUsd`	No	What you believe this costs, in USD
`resourceId`	Yes	resource_id — sha256(method + " " + canonical_url). Get it from /api/v1/resolve?q=<url>
`maxPerTxUsd`	No	Per-payment ceiling in USD (default 1)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that the payment module is never loaded on non-ALLOW, that FAILED means signed-but-unsettled with a live authorization until validBefore, that settlement is only a seller claim, and that GRAPH_API_KEY / VOUCH_PAYER_PRIVATE_KEY / viem are required from server env. These are exactly the safety and side-effect facts an agent cannot infer elsewhere.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly: the first sentence states the action and the second the sibling contrast, and it ends with the settlement/measurement caveats. Nearly every sentence carries new information, but the prose is thick with stacked parentheticals and repeats the "floors not evaluated on this path" idea for two separate paths, which slows scanning for a tool this consequential.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters, a nested policy object, and no output schema, so the description must define the return contract itself — and it does, naming decision, safe_to_pay, refuse_reasons, settlement/settle_claimed, measurement/evidence[], and decision_record fields such as verdict_source and policy_override. Nothing an agent needs to interpret the result or call it safely appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), but the description adds runtime meaning beyond it: it maps maxPerTxUsd and amountUsd to the specific reason codes they produce (price_above_ceiling vs price_above_declared), explains that policy is forwarded unchanged to payOrRefuse, clarifies that requireVet402Allow:false waives only a WARN and only when declared floors are met, and states that GRAPH_API_KEY is deliberately not an input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb+resource ("Pay an x402 resource ONLY if vet402's decision allows it") and immediately distinguishes itself from the sibling check_resource_decision by stating the key difference: this tool holds the signer and can therefore guarantee no signature exists on a refusal. An agent can choose between the two without inspecting either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative (check_resource_decision) and the condition that selects it, then goes further with routing rules for edge cases: omitting resource/payee/amountUsd yields pre-payment checks only, an uncatalogued seller answering 404 is handled via the SDK when resource is supplied, and missing env prerequisites downgrade the tool's behavior rather than erroring silently. Both when-to-use and when-not paths are covered.

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

Deploy Server