vet402
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VOUCH_API_KEY | No | Optional vet402 API key. The trust checks answer without one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_agent_trustA | ERC-8004 agent trust check on Base. Decide on decision (ALLOW_PAY | REFUSE) and safe_to_pay (boolean); pay only on ALLOW_PAY. An error result is REFUSE too — no answer is not an ALLOW. measurement carries the full score body as evidence, not as the decision. |
| check_wallet_trustA | Trust check for a wallet address. Resolves ERC-8004 agents when registered. Decide on decision (ALLOW_PAY | REFUSE) and safe_to_pay (boolean); pay only on ALLOW_PAY. An error result is REFUSE too — no answer is not an ALLOW. measurement carries the full score body as evidence, not as the decision. |
| check_payee_trustA | Buyer-side check before paying a wallet. Read these two fields and nothing else to decide:
Pay only on ALLOW_PAY. REFUSE already accounts for a degraded read, a partial measurement, a stale score, and a non-ALLOW recommendation; refuse_reasons names which. An error result is also REFUSE with safe_to_pay false — no answer is not an ALLOW. measurement carries the full score body (score, dataDepth, signals) for explanation and logging. It is evidence, not the decision. |
| explain_trust_scoreB | Explain a trust score breakdown in plain language for an agent or wallet. |
| attest_x402_paymentB | Record an x402 payment attestation after settlement verification (idempotent on txHash). |
| check_resource_decisionA | Pre-payment decision for an x402 resource (role=payer) or pre-service decision for a payer (role=payee). Decide on decision (ALLOW_PAY | REFUSE) and safe_to_pay (boolean); pay only on ALLOW_PAY. WARN and BLOCK are both REFUSE under the default allow-only policy. An error is REFUSE too. measurement carries the full decision body: facts (L0 liveness, L1 settle-through, L2 conformance), reason_codes, freshness, evidence, and the rules_version that produced the recommendation. The L1 reason codes name whose gap it is: l1_not_attempted (vet402 signed no paid attempt), l1_inconclusive (settled purchases exist, but each paid response was a 4xx vet402 attributes to its own request shape - a gap in vet402's measurement, not evidence against the seller; facts.l1.n_inconclusive carries the count and those rows do not count toward a BLOCK), l1_never_delivered (a conclusive paid response existed and nothing was delivered), l1_delivered. Each row of evidence[] names its own source: vet402 for a row from vet402's own L0-L2 record, subgraph for a row read from The Graph's x402 subgraph with the caller's own Graph key (that row carries subgraphId, block.number, deployment and queriedAt, which is what shows live index data rather than a static snapshot). This route returns vet402 rows. Do not add counts across sources: they count different things, and the two can disagree about the same wallet. Your own policy (role=payer only): pass amountUsd (what the 402 asks), maxPerTxUsd (your ceiling, default 1), minL1Deliveries (floor on vet402's delivered L1 purchases) and/or requireVet402Allow (default true: a WARN refuses with payee_recommendation_not_allow, as in the SDK; false waives the WARN and needs minL1Deliveries >= 1 or the server answers 400 invalid_policy). The server then adds measurement.caller_policy with verdict ALLOW | REFUSE and reason_codes in the SDK's own words: price_above_ceiling, insufficient_delivery_evidence, payee_recommendation_block, payee_recommendation_not_allow, evidence_unavailable. A caller_policy REFUSE makes this tool REFUSE and those words are in refuse_reasons. caller_policy never rewrites recommendation; not_evaluated lists what the server did not check (min_subgraph_receipts is always there - The Graph is read only with your own key, through pay_if_trusted). |
| pay_if_trustedA | 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:
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). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Three tools — check_agent_trust, check_wallet_trust, and check_payee_trust — all perform essentially the same address/agent trust lookup, and their descriptions repeat the identical "decide on decision and safe_to_pay" boilerplate rather than drawing a clear boundary. check_resource_decision also overlaps with all three while adding policy, leaving an agent unsure which entry point to use. Only explain_trust_score, attest_x402_payment, and pay_if_trusted are clearly distinct.
All names are snake_case with a leading verb (check_*, explain_*, attest_*, pay_if_*), which reads predictably. Minor deviations like pay_if_trusted (conditional phrasing) and attest_x402_payment (embedded protocol token) are still legible and do not break the pattern.
Seven tools is well within a comfortable range for a trust-gating server, and each remaining tool (explain, attest, decide, pay) maps to a distinct stage of the x402 flow. The only count concern is redundancy among the three check_* tools, not raw volume.
The surface covers check → explain → attest → decide → pay, which is the full payment-gating lifecycle. Gaps exist around reading back attestations or querying score history, but an agent can work around them via the check tools.