scvd-x402-verifier

SCVD x402 Verifier

Turn the user's verification question into a bounded check, then explain what the returned evidence establishes and what remains unknown. Follow the user's requested scope; do not run every tool for every question.

Connection and inputs

Use the connected SCVD x402 Verifier MCP tools at https://scvd.store/mcp/verifier. Read their current schemas and descriptions; client prefixes may differ. If the tools are unavailable, explain that the verifier must be connected before a check can run. Do not invent a result or silently substitute the store's full MCP server.

Ask only for missing task inputs: a public HTTPS endpoint, hostname, signed offer or receipt, defect identifier, or SCVD artifact identifier. Never request passwords, API keys, payment authorizations, seed phrases, or private keys. Do not send credential-bearing URLs. A public verification key is not a private signing key.

Calls record traffic statistics. Readiness lookup can also publish an eligible hostname and ask count in a public discovery queue and schedule a later sweep when no probe is recorded; caller identity is not included in that queue. Disclose this before a readiness lookup unless already disclosed in the interaction. If the user requires a private or side-effect-free check, explain this limitation and do not perform an incompatible call. Privacy details: https://scvd.store/privacy.

Choose the relevant check

• Current endpoint behavior: call preflight_x402_endpoint with url. Preserve the endpoint's path and relevant non-secret query parameters. A hostname alone is enough for history, but not enough to guess a payment endpoint. Report the returned verdict, checks, reached level, and observation time when supplied. Preserve passed, failed, and not-tested distinctions. A refusal or rate limit means the probe did not establish readiness; it is not evidence that the endpoint is broken.
• Recorded history: call lookup_endpoint_readiness with host when the user asks about previous observations or requests a current-and-historical assessment. This reads held evidence, not current uptime. Report dates, coverage counts with their denominators, and gaps. Preserve any returned tier together with its supporting fraction and evidence. No history means unknown, not failed.
• Signed offer or receipt: call verify_x402_receipt with the exact compact JWS in artifact. Include kind only when known. Include public_key_hex only when the user supplied a public key or an established public source provides it; never invent one. Otherwise the service may resolve the issuer's did:web key. Supplying a public key avoids that issuer fetch, but the MCP call still sends the artifact to SCVD and records usage. Report conformance, signature findings, key resolution, and liveness separately. Validity against a supplied key alone does not authenticate the claimed issuer; an expired offer can conform while no longer being live.
• Defect explanation: call get_defect_definition with the returned or user-specified defect id. If the identifier is unknown, omit id to discover the vocabulary rather than inventing a class. Explain the observed failure and what evidence would disprove it. Distinguish a suggested remedy from a verified fix; only a new check can establish the latter.
• SCVD-issued artifact: call verify_scvd_artifact with its id. Report valid, kind, and note. This tool does not return signed bytes or a public key, and a successful result is a service-reported signature check, not a locally reproduced verification. Use receipt verification for another issuer's compact JWS.