scvd-store-MCP

Conformance Desk

check_conformance

Verify any issuer's x402 signed offer or receipt. Checks structure, signature, and liveness, returning a named verdict for offline reproduction.

Instructions

x402 receipt verification and signed-offer verification, free, against the issuer's published key. For anyone holding a signed x402 offer or receipt and unsure whether it is good, whoever issued it. Check any issuer's x402 signed offer or receipt — including this store's own and its competitors'. Send the compact JWS (three base64url segments separated by dots); the desk checks structure, signature against the issuer's did:web key, and liveness, and returns a verdict with every check named. Supply public_key_hex for a fully offline check (no network request is made in your name unless you leave the key off). NOT for artifact ids this store issued — that is verify_artifact. An evidence instrument: the verdict is written to be handed to the human behind you. The method is MIT-licensed and identical to the published verifier, so a verdict that matters should be reproduced offline rather than trusted.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "artifact": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJkaWQ6d2ViOmV4YW1wbGUuY29tIn0.c2lnbmF0dXJl"
    },
    "name": "check_conformance"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Optional. The artifact kind; detected from the artifact when absent.
`artifact`	Yes	The signed offer or receipt as a compact JWS: header.payload.signature, base64url.
`public_key_hex`	No	Optional ed25519 public key, hex. Supplying it makes the check fully offline.

Output Schema

Name	Required	Description
`kind`	Yes	The artifact kind, or null when it could not be detected.
`live`	No	Separate from conformance: an expired offer can conform and not be payable. Null for receipts.
`verdict`	Yes	The desk's finding on the artifact.
`key_resolution`	No	How the issuer's key was obtained, or why it was not.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.1Sep 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the sparse annotations, the description discloses network behavior (looks up the issuer's did:web key, makes no request when a public key is supplied), the checks performed (structure, signature, liveness), the verdict shape (every check named), and reproducibility via the MIT-licensed verifier. The false/unknown readOnly and idempotent hints are not contradicted by the description.

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?

The description is dense and front-loaded but slightly wordy: 'x402 receipt verification and signed-offer verification' and 'For anyone holding...' restate the same scope. Still, every sentence contributes a distinct fact (scope, exclusion, offline mode, evidence purpose, reproducibility), so the length is largely justified.

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?

For a 3-parameter tool with a full input schema and an output schema, the description covers the required JWS format, optional offline mode, issuer scope, exclusion, and even the trust caveat. No critical caller-facing behavior is missing.

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

Parameters4/5

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 semantics: artifact must be a compact JWS with three base64url dot-separated segments, and public_key_hex forces a fully offline check. This exceeds what the schema alone communicates.

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?

States a precise verb and resource: x402 receipt and signed-offer verification against the issuer's published key. It explicitly differentiates from verify_artifact by saying 'NOT for artifact ids this store issued — that is verify_artifact,' so an agent can disambiguate immediately.

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?

Tells exactly when to use it (holding a signed x402 offer or receipt and unsure whether it is good, for any issuer), how to invoke offline (supply public_key_hex), and when not to (artifact ids issued by this store → verify_artifact). This is explicit routing rather than implied usage.

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