ExitProof MCP Server

Persist a privacy-minimized Exit Manifest for an eligible commitment, then return its manifest_id and secret access_token. Use only after check_reversibility says paidExitManifestAvailable=true; pass the exact commitment facts to preserve, with transaction-specific checkout_terms controlling the assessment when supplied. Use check_reversibility for evaluation only, or get_exit_manifest when a manifest already exists. This state-changing $0.25 stablecoin MPP operation checks eligibility before any payment challenge; a fresh authorization creates durable state, while an identical settled retry with the same payment credential recovers the same manifest without a second settlement. The plaintext access token is returned to the caller but stored only as a SHA-256 hash.

Retrieve one previously created Exit Manifest without charging or changing stored state. Pass manifest_id and access_token together: the ID selects the record and the secret token authorizes access to that same record, so neither value is sufficient alone. Use this for preserved evidence and terms; use build_exit_pack for an actionable cancellation/refund plan, or create_exit_manifest when no manifest exists. This free, repeatable read does not refresh, re-evaluate, or extend evidence; missing, expired, or mismatched credentials fail without modifying the manifest.

Inspect one autonomous HTTP purchase before the calling agent pays it. This $0.01 machine-payment operation validates a real 402 challenge, compares advertised price/protocol/network/asset/payment destination when supplied, checks x402 v2 exact resource binding when available, and surfaces retry or settled-delivery recovery signals. ExitProof never forwards payment credentials and never sends a live POST, PUT, PATCH, or DELETE probe; for those methods the caller supplies an already-observed 402 challenge. Conflicting, malformed, inaccessible, non-402, or unsafe targets are rejected before ExitProof issues its own payment challenge. Use check_reversibility instead for cancellation/refund terms on a real-world commitment, create_exit_manifest to preserve an eligible exit path, and build_exit_pack when an exit is actually needed. A successful check is not a recommendation, merchant-identity guarantee, delivery guarantee, legal opinion, or authorization to spend.

Build a bounded cancellation/refund action pack from an existing actionable Exit Manifest. Pass manifest_id and access_token together as the credential pair returned by create_exit_manifest or settlement recovery; use get_exit_manifest for retrieval only, or check_reversibility then create_exit_manifest when no manifest exists. This $1.00 MPP operation prefers Tempo stablecoin when available, retains Stripe card/link as a compatible fallback, and can charge but never contacts the merchant, executes a cancellation, files a chargeback, or guarantees success. Invalid or mismatched credentials and non-actionable manifests are rejected before payment; an identical settled retry with the same payment credential avoids a second settlement, while generatedAt and deadlineStatus can reflect the current time.

Evaluate one commitment’s cancellation/refund reversibility from transaction-specific checkout terms plus maintained policy evidence, without charging or creating durable state. Use before a purchase, booking, subscription, rental, service, ticket, digital purchase, or deposit when exit deadlines or loss matter; use list_supported_policies only for maintained-overlay coverage, and create_exit_manifest only after paidExitManifestAvailable=true. Do not use for purchase desirability, legal advice, chargeback decisions, or executing a cancellation. Supply checkout_terms whenever available because they control the transaction-specific assessment; expected_commitment_at moves deadline evaluation forward when the commitment is future-dated, and missing or conflicting evidence can return assessment=unknown rather than inventing an exit right.

List the maintained merchant policy overlays and snapshot version/date ExitProof can add to transaction-specific evidence. Use this only to inspect maintained coverage; use check_reversibility to evaluate an actual commitment, including an unlisted merchant when transaction-specific checkout_terms are available. An absent merchant means no maintained overlay, not that no cancellation, refund, contractual, or legal right exists. This is a free read-only snapshot: it creates no durable state, issues no payment challenge, and does not fetch or verify a merchant’s live policy at call time.