Skip to main content
Glama

ExitProof

by com.davisvillelabs
OverviewDiscussionsAdmin

Server Details

Reversibility intelligence and durable exit evidence for AI agents before real-world commitments.

Ownership verified
Status
Healthy
Uptime
100.0% over 22 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.9/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct stage or concern: policy discovery, reversibility evaluation, manifest creation/retrieval, action-pack building, and HTTP purchase inspection. The descriptions explicitly cross-reference adjacent tools, so an agent can reliably tell them apart.

Naming Consistency5/5

All tool names use a consistent snake_case verb_noun pattern, such as check_reversibility, create_exit_manifest, get_exit_manifest, and list_supported_policies. The repeated check_ prefix is applied to different object nouns, preserving a clear and predictable convention.

Tool Count5/5

Six tools is well-scoped for the server's purpose: a tight lifecycle from policy lookup and reversibility checks through manifest creation, retrieval, and exit-pack construction, plus one related agent-purchase inspection tool. Each tool has a clear role without unnecessary redundancy.

Completeness5/5

The tool surface covers the full described workflow: discover policies, evaluate reversibility, create and retrieve manifests, and build an actionable exit pack from an existing manifest. There are no obvious dead ends or missing lifecycle operations required by the domain.

Available Tools

6 tools
build_exit_packBuild exit packAInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
manifest_idYesUnguessable Exit Manifest identifier returned by create_exit_manifest. It starts with xm_ followed by 32 lowercase hexadecimal characters.
access_tokenYesSecret bearer token returned by create_exit_manifest or deterministic settlement recovery. Required with manifest_id; treat it like a credential and do not log or expose it.

Output Schema

ParametersJSON Schema
NameRequiredDescription
stepsYesOrdered bounded next steps for pursuing cancellation or refund.
sourcesYesRecorded source references supporting the action pack.
currencyNoCurrency associated with recorded monetary values.
exitRouteYesRecorded cancellation/refund route or cited-source route to follow.
assessmentYesReversibility assessment preserved by the manifest.
manifestIdYesManifest used to build this action pack.
generatedAtYesTimestamp when the action pack was generated.
limitationsYesBoundaries and caveats; ExitProof does not execute the exit or guarantee success.
actionabilityYesWhy the stored manifest is actionable and which exit route is established.
prerequisitesYesChecks to complete before acting on the exit plan.
schemaVersionYesExit-pack response schema version.
deadlineStatusYesCurrent status of the recorded exit deadline at generation time.
reversibleUntilNoRecorded exit deadline when established.
suggestedRequestYesSuggested message the user or agent can adapt when requesting cancellation/refund.
evidenceChecklistYesEvidence to retain while pursuing the exit.
maximumStatedLossMinorNoMaximum stated loss in minor currency units when established.
unresolvedLossExposureNoTrue when the recorded evidence does not establish a complete maximum loss.

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond the annotations. It discloses that the tool can charge but never contacts the merchant, executes cancellation, files chargebacks, or guarantees success, and that invalid credentials or non-actionable manifests are rejected before payment. It also explains idempotent retry behavior and generatedAt/deadlineStatus semantics, which are not visible in structured fields. No contradiction with annotations.

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 information-dense but every sentence adds new information: purpose, credential sourcing, behavioral limitations, retry behavior, and edge-case handling. It is front-loaded with the core action and usage, and while it is longer than average, the complexity of the tool justifies it. No filler or repetition.

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?

Given the tool's complexity, an output schema is present, so return values are covered. The description covers usage context, alternatives, behavioral constraints, credential validation, retry semantics, and time-sensitive fields. Nothing an agent needs to decide whether and how to call it 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. The description adds value by explaining the two parameters must be passed together as a credential pair, that they are returned by create_exit_manifest or settlement recovery, and that invalid or mismatched credentials cause rejection. This contextualizes the parameters beyond the schema's individual descriptions.

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?

The description opens with a clear verb-resource statement: 'Build a bounded cancellation/refund action pack from an existing actionable Exit Manifest.' It specifies exactly what the tool produces and distinguishes it from siblings by name (get_exit_manifest for retrieval, create_exit_manifest for creation). No ambiguity about the tool's role.

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?

Explicit when-to-use and when-not-to-use guidance: pass the credential pair from create_exit_manifest or settlement recovery; use get_exit_manifest for retrieval only, or check_reversibility then create_exit_manifest when no manifest exists. Alternatives are named and the selection condition is stated, leaving no room for guesswork.

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

check_agent_purchaseCheck agent purchaseAInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
operationNoOptional caller label for the target operation. This is descriptive only and is included in the check digest.
advertisedNoOptional payment facts advertised by discovery metadata. ExitProof compares these to the observed 402 challenge and rejects material conflicts before its own payment challenge.
live_probeNoWhether ExitProof may make one anonymous, credential-free request to target_url. Defaults true for GET/HEAD and false for state-changing methods.
target_urlYesPublic HTTPS endpoint the agent is considering paying. Credentials, localhost, private-address literals, and non-HTTPS URLs are rejected.
request_methodNoHTTP method of the contemplated purchase. Live probing is allowed only for GET or HEAD. For state-changing methods supply observed_response instead.GET
retry_contractNoOptional retry, settled-delivery recovery, and refund/reversal facts advertised by the target. These remain caller-supplied unless independently verified elsewhere.
observed_responseNoA 402 response already observed by the calling agent. Required when live_probe is false. Supply payment challenge headers only, never a payment credential.

Output Schema

ParametersJSON Schema
NameRequiredDescription
checksYesIndividual safety checks. Conflicts reject before payment and therefore never appear as a paid result.
targetYesNormalized target endpoint and contemplated method.
evidenceYesEvidence provenance, including whether the 402 challenge was independently observed by ExitProof.
nextStepYesMachine-readable status and bounded instruction for the calling agent.
checkedAtYesTime the check result was produced.
advertisedNoNormalized caller-supplied advertised terms used for consistency checks.
assessmentYesBounded pre-payment status. This is not a recommendation to buy.
checkDigestYesSHA-256 digest of the normalized target, payment facts, recovery facts, and evidence provenance.
limitationsYesBoundaries on what the paid result establishes.
reversibilityYesPublished retry, settled-delivery recovery, and reversal metadata supplied for this target.
schemaVersionYesAgent purchase check schema version.
observedPaymentYesSelected machine-payment offer normalized from the observed 402 challenge.
receiptEnvelopeYesAdditive Davisville Receipt Envelope v1. The native ExitProof purchase-check result remains authoritative.
availablePaymentOffersYesAll parseable x402 or MPP offers found in the observed response.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behaviors: it never forwards payment credentials, never sends live POST/PUT/PATCH/DELETE probes, and only probes GET/HEAD. It also states that conflicting/malformed/inaccessible/non-402/unsafe targets are rejected before issuing its own payment challenge, and includes the $0.01 cost and disclaimers about non-guarantees. This is thorough and non-contradictory.

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

Conciseness5/5

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

Though longer than average, every sentence is information-dense and earns its place: purpose, cost, exclusions, alternatives, and caveats are logically sequenced with the core purpose front-loaded. There is zero fluff or repetition.

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 description, combined with the rich input schema (7 properties, nested objects) and the presence of an output schema, covers everything an agent needs to decide and invoke correctly: purpose, cost, exclusions, alternative tools, safety limits, and required inputs. The output schema handles return values, so the description need not describe them.

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

Parameters3/5

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

Schema coverage is 100% – every property (including nested objects) has a detailed description. The tool description adds minimal extra parameter meaning beyond reiterating what the schema already says (e.g., 'compares advertised price/protocol/network/asset/payment destination' mirrors the advertised object's fields). Since the schema carries the weight, baseline 3 applies; the description does not degrade it.

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?

The description opens with a precise verb+resource: 'Inspect one autonomous HTTP purchase before the calling agent pays it.' It enumerates exact checks (validates 402, compares advertised facts, checks x402 binding, surfaces retry signals) and explicitly differentiates from sibling tools by naming them. This is a model of purpose clarity.

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?

It explicitly states when to use this tool vs. alternatives: 'Use check_reversibility instead for cancellation/refund terms... create_exit_manifest to preserve an eligible exit path, and build_exit_pack when an exit is actually needed.' It also gives concrete usage conditions for state-changing methods (supply observed_response) and clarifies the cost ('$0.01 operation').

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

check_reversibilityCheck reversibilityA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
amountYesCommitment amount in major currency units, for example 125.50 for USD 125.50. Must be non-negative and uses currency below for all monetary interpretation.
regionNoOptional state, province, or region label when the commitment or merchant terms are region-specific.
countryNoOptional two-letter ISO 3166-1 alpha-2 country code, such as US. Used to scope maintained policy rules when geography matters.
currencyNoThree-letter ISO 4217 currency code for amount and all monetary checkout terms. Defaults to USD.USD
merchantYesMerchant, platform, provider, or counterparty name exactly enough to identify the commitment. Used to match maintained policy overlays; do not include account numbers, credentials, or secrets.
event_typeNoLifecycle event for this commitment. Use renewal for a recurring renewal, reservation for a booking event, deposit for a deposit event, or leave omitted for an initial commitment.initial
checkout_termsNoTransaction-specific cancellation, refund, renewal, charge, and loss terms observed for this exact commitment. Supply these whenever available; they control the transaction-specific assessment while maintained policy evidence remains contextual.
commitment_typeYesClosest category for the commitment being evaluated. This affects policy matching and should describe what the user is committing to, not the payment method.
client_referenceNoOptional caller-owned correlation reference. ExitProof stores only a SHA-256 hash; do not place secrets or sensitive personal data here.
purchase_channelNoWhere the commitment is being made or billed. Use apple or google_play when that billing platform controls cancellation/refund rules; use direct for the merchant itself.unknown
expected_commitment_atNoRFC 3339 timestamp with explicit timezone for when the commitment is expected to occur. ExitProof evaluates time windows at the later of now and this timestamp.

Output Schema

ParametersJSON Schema
NameRequiredDescription
reasonYesConcise evidence-grounded explanation of the assessment.
currencyYesNormalized three-letter currency code.
evidenceYesEvidence items supporting or limiting the assessment.
merchantYesNormalized merchant or platform name.
assessmentYesEvidence-bounded reversibility classification. unknown means current evidence is insufficient or conflicting.
caseDigestYesStable digest of the normalized commitment inputs used for this assessment.
amountMinorYesCommitment amount in minor currency units.
evaluatedAtYesTimestamp at which the commitment was evaluated.
limitationsYesImportant limits on what the assessment proves.
evidenceBasisNoWhether the assessment is based on checkout terms, maintained policy, both, or insufficient evidence.
evidenceStateNoCurrent evidence state, such as established, incomplete, conflicting, expired, or missing.
schemaVersionYesExitProof reversibility result schema version.
commitmentTypeYesNormalized commitment type.
decisionSupportNoDecision-support summary that does not decide whether the user should make the commitment.
reversibleUntilNoRecorded exit deadline when established, otherwise null.
evidenceConflictNoTrue when evidence conflicts and cannot safely support a confident paid result.
exitPackEligibilityNoReasoned actionability status for a future exit pack.
paidExitPackAvailableYesWhether the current evidence appears actionable enough for a later exit pack after a manifest exists.
currentExitEstablishedNoWhether current evidence establishes an exit route.
maximumStatedLossMinorNoMaximum stated loss in minor currency units when safely established, otherwise null.
paidExitManifestAvailableYesWhether current evidence passes the preflight required before create_exit_manifest can be challenged for payment.

TDQS

A4.9/5.0
Behavior5/5

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

The description adds behavioral context beyond the annotations: 'without charging or creating durable state' aligns with readOnlyHint/idempotentHint but is not stated in the annotations, and 'missing or conflicting evidence can return assessment=unknown rather than inventing an exit right' discloses a key failure mode. This enriches the safety profile already provided by annotations without contradicting it.

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

Conciseness5/5

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

Every sentence in the description earns its place: purpose, scope, alternatives, exclusions, and parameter prioritization are all covered in a compact block. The most important scoping statement is front-loaded, and no filler or redundancy is present.

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?

Despite the tool's complexity (11 parameters, nested objects, output schema), the description covers purpose, usage boundaries, sibling routing, failure behavior, and parameter prioritization. The presence of an output schema means return-value details need not appear in the description. Nothing an agent needs to call this tool correctly 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 description coverage is 100%, so the baseline is 3. The description adds actionable parameter guidance: 'Supply checkout_terms whenever available because they control the transaction-specific assessment' and 'expected_commitment_at moves deadline evaluation forward when the commitment is future-dated.' These go beyond the schema's field descriptions, earning an extra point.

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?

The description opens with a specific verb and resource: 'Evaluate one commitment’s cancellation/refund reversibility from transaction-specific checkout terms plus maintained policy evidence' and immediately disambiguates from siblings by stating 'without charging or creating durable state' and later directing to list_supported_policies and create_exit_manifest for other purposes. An agent can distinguish this tool from its siblings without opening the 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?

Explicit when-to-use ('Use before a purchase, booking, subscription, rental, service, ticket, digital purchase, or deposit when exit deadlines or loss matter'), when-not-to-use ('Do not use for purchase desirability, legal advice, chargeback decisions, or executing a cancellation'), and which alternative to pick ('use list_supported_policies only for maintained-overlay coverage, and create_exit_manifest only after paidExitManifestAvailable=true'). No inference is left to the agent.

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

create_exit_manifestCreate Exit ManifestAInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
amountYesCommitment amount in major currency units, for example 125.50 for USD 125.50. Must be non-negative and uses currency below for all monetary interpretation.
regionNoOptional state, province, or region label when the commitment or merchant terms are region-specific.
countryNoOptional two-letter ISO 3166-1 alpha-2 country code, such as US. Used to scope maintained policy rules when geography matters.
currencyNoThree-letter ISO 4217 currency code for amount and all monetary checkout terms. Defaults to USD.USD
merchantYesMerchant, platform, provider, or counterparty name exactly enough to identify the commitment. Used to match maintained policy overlays; do not include account numbers, credentials, or secrets.
event_typeNoLifecycle event for this commitment. Use renewal for a recurring renewal, reservation for a booking event, deposit for a deposit event, or leave omitted for an initial commitment.initial
checkout_termsNoTransaction-specific cancellation, refund, renewal, charge, and loss terms observed for this exact commitment. Supply these whenever available; they control the transaction-specific assessment while maintained policy evidence remains contextual.
commitment_typeYesClosest category for the commitment being evaluated. This affects policy matching and should describe what the user is committing to, not the payment method.
client_referenceNoOptional caller-owned correlation reference. ExitProof stores only a SHA-256 hash; do not place secrets or sensitive personal data here.
purchase_channelNoWhere the commitment is being made or billed. Use apple or google_play when that billing platform controls cancellation/refund rules; use direct for the merchant itself.unknown
expected_commitment_atNoRFC 3339 timestamp with explicit timezone for when the commitment is expected to occur. ExitProof evaluates time windows at the later of now and this timestamp.

Output Schema

ParametersJSON Schema
NameRequiredDescription
createdAtYesManifest creation timestamp.
expiresAtYesManifest expiration timestamp.
assessmentYesReversibility assessment preserved in the manifest.
manifestIdYesUnguessable identifier for the stored Exit Manifest.
accessTokenYesSecret bearer token required with manifestId for later retrieval or exit-pack creation. ExitProof does not store this token in plaintext.
privacyNoteYesHow ExitProof protects and may recover the access token.
paidExitPackAvailableNoWhether the stored manifest is eligible for an exit-pack preflight at creation time.
accessTokenReturnedOnceYesWhether this response is the first normal return of the access token.
accessTokenReissuedForSettlementRecoveryNoTrue only when deterministic settlement recovery re-derived the access token after a settled delivery failure.

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond annotations, disclosing that this is a state-changing $0.25 stablecoin MPP operation, that eligibility is checked before any payment challenge, that a fresh authorization creates durable state, and that retries with the same payment credential recover the same manifest without a second settlement. It also reveals that the access token is returned in plaintext but stored only as a SHA-256 hash, which is materially useful behavioral context.

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

Conciseness5/5

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

The description is dense but every sentence carries actionable information: function, prerequisite, alternatives, cost, retry behavior, and token storage. It is front-loaded with the core purpose and uses no filler.

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 complex 11-parameter, nested-object operation, the description provides everything needed for selection and invocation: eligibility prerequisite, sibling routing, cost, settlement behavior, retry semantics, and privacy handling. Since the output schema exists, the description does not need to explain return fields.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds some high-level guidance, such as passing 'exact commitment facts to preserve' and noting that checkout_terms control the assessment, but most parameter-level meaning is already fully covered by the schema's rich per-field descriptions.

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?

The description opens with a specific verb and resource: 'Persist a privacy-minimized Exit Manifest for an eligible commitment, then return its manifest_id and secret access_token.' It clearly names the tool's output and distinguishes it from siblings by directing users to check_reversibility for evaluation and get_exit_manifest when a manifest already exists.

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?

Usage guidance is explicit: 'Use only after check_reversibility says paidExitManifestAvailable=true.' It also states when NOT to use this tool, directing to check_reversibility for evaluation-only and get_exit_manifest for existing manifests, which is strong alternative selection guidance.

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

get_exit_manifestGet Exit ManifestA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
manifest_idYesUnguessable Exit Manifest identifier returned by create_exit_manifest. It starts with xm_ followed by 32 lowercase hexadecimal characters.
access_tokenYesSecret bearer token returned by create_exit_manifest or deterministic settlement recovery. Required with manifest_id; treat it like a credential and do not log or expose it.

Output Schema

ParametersJSON Schema
NameRequiredDescription
manifestYesStored Exit Manifest. This read does not refresh or reinterpret the original evidence.
schemaVersionYesManifest-read response schema version.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces and extends this with valuable specifics: the operation is free, repeatable, does not refresh/re-evaluate/extend evidence, and missing/expired/mismatched credentials fail without modifying the manifest. This adds meaningful behavioral context beyond the annotations.

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

Conciseness5/5

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

The description is dense but not bloated; each sentence earns its place. It front-loads the core purpose and read-only guarantee, then handles credential pairing, usage guidance, and behavioral caveats without redundant phrasing.

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?

Given the output schema, annotations, and sibling list, the description covers everything needed to call the tool correctly: what it returns conceptually, how the two parameters interact, when to choose alternatives, and what side effects do not occur. No critical operational gap remains.

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% with detailed patterns and descriptions for both parameters. The description adds cross-parameter semantics by stating that manifest_id and access_token must be passed together and that neither value is sufficient alone, plus a security caution to treat the token as a credential. This is useful context beyond the schema, though it does not need to repeat field-level details.

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?

The description opens with a specific verb and resource: 'Retrieve one previously created Exit Manifest.' It immediately clarifies the read-only nature ('without charging or changing stored state') and names the sibling alternatives it is not, so an agent can distinguish it from build_exit_pack and create_exit_manifest without opening schemas.

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?

The description explicitly states when to use this tool ('Use this for preserved evidence and terms') and gives concrete alternative conditions: build_exit_pack for an actionable cancellation/refund plan and create_exit_manifest when no manifest exists. This is strong routing guidance that goes beyond the sibling list.

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

list_supported_policiesList supported policiesA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
importantYesCoverage caveat explaining that transaction-specific checkout terms can be used for any merchant.
merchantsYesMerchants with maintained policy overlays.
schemaVersionYesSupported-policy response schema version.
policySnapshotYesVersion and verification date for the maintained policy snapshot.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful context beyond them: it is a free read-only snapshot, creates no durable state, issues no payment challenge, and does not fetch or verify a merchant's live policy at call time. This clarifies side effects and scope in a way annotations alone do not.

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

Conciseness5/5

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

Four sentences, each earning its place: scope, usage, interpretation caveat, and behavioral disclosure. The purpose is front-loaded, and there is no filler or repetition of structured fields.

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 zero-parameter read-only listing tool, the description fully covers its role, limitations, and interpretation pitfalls. An output schema exists, and annotations cover safety, so the description has no critical gaps.

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?

The tool has zero parameters and the schema already states this with 100% coverage. Per the rubric, a zero-parameter tool gets a baseline of 4; the description adds no parameter semantics because none are needed.

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?

The description opens with a specific verb and resource: 'List the maintained merchant policy overlays and snapshot version/date'. It also differentiates from siblings by naming check_reversibility as the tool for evaluating actual commitments, so an agent can immediately distinguish it without opening schemas.

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 states 'Use this only to inspect maintained coverage' and directs to check_reversibility for evaluating actual commitments, including unlisted merchants with checkout_terms. It also provides an interpretive caveat about absent merchants, preventing a common misunderstanding about legal rights. This is exemplary when-to-use/not-use guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedcheck_agent_purchase2 fields changed
      • addedOutput schema / properties / receiptEnvelope
        Added value: +{
+  "$ref": "https://davisvillelabs.com/agents/davisville-receipt-envelope.v1.schema.json",
+  "description": "Additive Davisville Receipt Envelope v1. The native ExitProof purchase-check result remains authoritative."
+}
      • changedOutput schema / required
        Previous value: -[
-  "schemaVersion",
-  "checkedAt",
-  "assessment",
-  "target",
-  "observedPayment",
-  "availablePaymentOffers",
-  "checks",
-  "reversibility",
-  "evidence",
-  "limitations",
-  "nextStep",
-  "checkDigest"
-]New value: +[
+  "schemaVersion",
+  "checkedAt",
+  "assessment",
+  "target",
+  "observedPayment",
+  "availablePaymentOffers",
+  "checks",
+  "reversibility",
+  "evidence",
+  "limitations",
+  "nextStep",
+  "checkDigest",
+  "receiptEnvelope"
+]
  2. 1 tool update
    • Addedcheck_agent_purchase
  3. 5 tool updates
    • Changedbuild_exit_pack4 fields changed
      • addedInput schema / description
        Added value: +"Credentials for one previously created Exit Manifest. Both values are required together and are returned by create_exit_manifest or settlement recovery."
      • addedInput schema / properties / access_token / description
        Added value: +"Secret bearer token returned by create_exit_manifest or deterministic settlement recovery. Required with manifest_id; treat it like a credential and do not log or expose it."
      • addedInput schema / properties / manifest_id / description
        Added value: +"Unguessable Exit Manifest identifier returned by create_exit_manifest. It starts with xm_ followed by 32 lowercase hexadecimal characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Bounded action pack derived from an actionable Exit Manifest.",
+  "properties": {
+    "actionability": {
+      "additionalProperties": true,
+      "description": "Why the stored manifest is actionable and which exit route is established.",
+      "type": "object"
+    },
+    "assessment": {
+      "description": "Reversibility assessment preserved by the manifest.",
+      "type": "string"
+    },
+    "currency": {
+      "description": "Currency associated with recorded monetary values.",
+      "type": "string"
+    },
+    "deadlineStatus": {
+      "description": "Current status of the recorded exit deadline at generation time.",
+      "enum": [
+        "open",
+        "passed",
+        "not_established"
+      ],
+      "type": "string"
+    },
+    "evidenceChecklist": {
+      "description": "Evidence to retain while pursuing the exit.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "exitRoute": {
+      "additionalProperties": true,
+      "description": "Recorded cancellation/refund route or cited-source route to follow.",
+      "type": "object"
+    },
+    "generatedAt": {
+      "description": "Timestamp when the action pack was generated.",
+      "type": "string"
+    },
+    "limitations": {
+      "description": "Boundaries and caveats; ExitProof does not execute the exit or guarantee success.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "manifestId": {
+      "description": "Manifest used to build this action pack.",
+      "type": "string"
+    },
+    "maximumStatedLossMinor": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Maximum stated loss in minor currency units when established."
+    },
+    "prerequisites": {
+      "description": "Checks to complete before acting on the exit plan.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "reversibleUntil": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Recorded exit deadline when established."
+    },
+    "schemaVersion": {
+      "const": "exitproof-exit-pack.v1",
+      "description": "Exit-pack response schema version."
+    },
+    "sources": {
+      "description": "Recorded source references supporting the action pack.",
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "steps": {
+      "description": "Ordered bounded next steps for pursuing cancellation or refund.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "suggestedRequest": {
+      "description": "Suggested message the user or agent can adapt when requesting cancellation/refund.",
+      "type": "string"
+    },
+    "unresolvedLossExposure": {
+      "description": "True when the recorded evidence does not establish a complete maximum loss.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "manifestId",
+    "generatedAt",
+    "assessment",
+    "actionability",
+    "exitRoute",
+    "prerequisites",
+    "deadlineStatus",
+    "steps",
+    "suggestedRequest",
+    "evidenceChecklist",
+    "sources",
+    "limitations"
+  ],
+  "type": "object"
+}
    • Changedcheck_reversibility27 fields changed
      • addedInput schema / description
        Added value: +"One contemplated or existing commitment to evaluate. merchant, commitment_type, and amount are required. Transaction-specific checkout_terms are the strongest input when available; maintained policy evidence can add context but never overrides conflicting transaction-specific terms."
      • addedInput schema / properties / amount / description
        Added value: +"Commitment amount in major currency units, for example 125.50 for USD 125.50. Must be non-negative and uses currency below for all monetary interpretation."
      • addedInput schema / properties / checkout_terms / description
        Added value: +"Transaction-specific cancellation, refund, renewal, charge, and loss terms observed for this exact commitment. Supply these whenever available; they control the transaction-specific assessment while maintained policy evidence remains contextual."
      • addedInput schema / properties / checkout_terms / properties / auto_renews / description
        Added value: +"Whether the supplied transaction terms explicitly state that the commitment renews automatically."
      • addedInput schema / properties / checkout_terms / properties / cancellable / description
        Added value: +"Whether the supplied transaction terms explicitly state that the commitment can be canceled."
      • changedInput schema / properties / checkout_terms / properties / cancellation_deadline / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 timestamp with explicit timezone for the stated cancellation deadline, even when cancellation may involve a loss."
      • addedInput schema / properties / checkout_terms / properties / cancellation_method / description
        Added value: +"Recorded method or path for cancellation/refund, such as an account page, support channel, or merchant instruction. This can make a later exit pack actionable."
      • addedInput schema / properties / checkout_terms / properties / cancellation_penalty_amount / description
        Added value: +"Stated cancellation penalty in major units of currency. Mutually exclusive with cancellation_penalty_percent."
      • addedInput schema / properties / checkout_terms / properties / cancellation_penalty_percent / description
        Added value: +"Stated cancellation penalty as a percentage from 0 to 100. Mutually exclusive with cancellation_penalty_amount."
      • addedInput schema / properties / checkout_terms / properties / charge_timing / description
        Added value: +"When the merchant states the charge will occur, such as immediately, at check-in, or 24 hours before renewal."
      • changedInput schema / properties / checkout_terms / properties / free_cancellation_until / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 deadline with explicit timezone through which the supplied terms state cancellation is free."
      • addedInput schema / properties / checkout_terms / properties / nonrefundable_amount / description
        Added value: +"Amount explicitly stated as nonrefundable, in major units of currency."
      • changedInput schema / properties / checkout_terms / properties / observed_at / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 timestamp with explicit timezone for when the caller observed these checkout terms."
      • addedInput schema / properties / checkout_terms / properties / refundable / description
        Added value: +"Whether the supplied transaction terms explicitly state that the committed amount is refundable."
      • addedInput schema / properties / checkout_terms / properties / renewal_interval / description
        Added value: +"Human-readable renewal interval from the supplied terms, such as monthly or annually. Use only when auto-renewal terms are stated."
      • addedInput schema / properties / checkout_terms / properties / source_url / description
        Added value: +"HTTP(S) source URL for the supplied transaction terms. ExitProof removes credentials, query parameters, and fragments before storing the URL."
      • changedInput schema / properties / client_reference / description
        Previous value: -"Optional caller-owned reference. ExitProof stores only a SHA-256 hash."New value: +"Optional caller-owned correlation reference. ExitProof stores only a SHA-256 hash; do not place secrets or sensitive personal data here."
      • addedInput schema / properties / commitment_type / description
        Added value: +"Closest category for the commitment being evaluated. This affects policy matching and should describe what the user is committing to, not the payment method."
      • addedInput schema / properties / country / description
        Added value: +"Optional two-letter ISO 3166-1 alpha-2 country code, such as US. Used to scope maintained policy rules when geography matters."
      • addedInput schema / properties / country / pattern
        Added value: +"^[A-Za-z]{2}$"
      • addedInput schema / properties / currency / description
        Added value: +"Three-letter ISO 4217 currency code for amount and all monetary checkout terms. Defaults to USD."
      • addedInput schema / properties / event_type / description
        Added value: +"Lifecycle event for this commitment. Use renewal for a recurring renewal, reservation for a booking event, deposit for a deposit event, or leave omitted for an initial commitment."
      • changedInput schema / properties / expected_commitment_at / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 timestamp with explicit timezone for when the commitment is expected to occur. ExitProof evaluates time windows at the later of now and this timestamp."
      • addedInput schema / properties / merchant / description
        Added value: +"Merchant, platform, provider, or counterparty name exactly enough to identify the commitment. Used to match maintained policy overlays; do not include account numbers, credentials, or secrets."
      • addedInput schema / properties / purchase_channel / description
        Added value: +"Where the commitment is being made or billed. Use apple or google_play when that billing platform controls cancellation/refund rules; use direct for the merchant itself."
      • addedInput schema / properties / region / description
        Added value: +"Optional state, province, or region label when the commitment or merchant terms are region-specific."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Bounded reversibility assessment with evidence, loss/deadline information, limitations, and paid-operation eligibility flags.",
+  "properties": {
+    "amountMinor": {
+      "description": "Commitment amount in minor currency units.",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "assessment": {
+      "description": "Evidence-bounded reversibility classification. unknown means current evidence is insufficient or conflicting.",
+      "enum": [
+        "fully_reversible",
+        "conditionally_reversible",
+        "low_reversibility",
+        "effectively_irreversible",
+        "unknown"
+      ],
+      "type": "string"
+    },
+    "caseDigest": {
+      "description": "Stable digest of the normalized commitment inputs used for this assessment.",
+      "type": "string"
+    },
+    "commitmentType": {
+      "description": "Normalized commitment type.",
+      "type": "string"
+    },
+    "currency": {
+      "description": "Normalized three-letter currency code.",
+      "type": "string"
+    },
+    "currentExitEstablished": {
+      "anyOf": [
+        {
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Whether current evidence establishes an exit route."
+    },
+    "decisionSupport": {
+      "additionalProperties": true,
+      "description": "Decision-support summary that does not decide whether the user should make the commitment.",
+      "type": "object"
+    },
+    "evaluatedAt": {
+      "description": "Timestamp at which the commitment was evaluated.",
+      "type": "string"
+    },
+    "evidence": {
+      "description": "Evidence items supporting or limiting the assessment.",
+      "items": {
+        "additionalProperties": true,
+        "description": "One evidence item used by ExitProof.",
+        "properties": {
+          "authority": {
+            "description": "Authority label for the source.",
+            "type": "string"
+          },
+          "evidenceOrigin": {
+            "description": "Origin classification, such as caller_supplied or maintained_policy.",
+            "type": "string"
+          },
+          "independentlyVerified": {
+            "description": "Whether ExitProof independently verified this evidence item.",
+            "type": "boolean"
+          },
+          "observedAt": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "When the evidence was observed, when available."
+          },
+          "sourceUrl": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "Source URL when one is available."
+          },
+          "type": {
+            "description": "Evidence type, such as checkout_terms or official_policy.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "evidenceBasis": {
+      "description": "Whether the assessment is based on checkout terms, maintained policy, both, or insufficient evidence.",
+      "type": "string"
+    },
+    "evidenceConflict": {
+      "description": "True when evidence conflicts and cannot safely support a confident paid result.",
+      "type": "boolean"
+    },
+    "evidenceState": {
+      "description": "Current evidence state, such as established, incomplete, conflicting, expired, or missing.",
+      "type": "string"
+    },
+    "exitPackEligibility": {
+      "additionalProperties": true,
+      "description": "Reasoned actionability status for a future exit pack.",
+      "type": "object"
+    },
+    "limitations": {
+      "description": "Important limits on what the assessment proves.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "maximumStatedLossMinor": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Maximum stated loss in minor currency units when safely established, otherwise null."
+    },
+    "merchant": {
+      "description": "Normalized merchant or platform name.",
+      "type": "string"
+    },
+    "paidExitManifestAvailable": {
+      "description": "Whether current evidence passes the preflight required before create_exit_manifest can be challenged for payment.",
+      "type": "boolean"
+    },
+    "paidExitPackAvailable": {
+      "description": "Whether the current evidence appears actionable enough for a later exit pack after a manifest exists.",
+      "type": "boolean"
+    },
+    "reason": {
+      "description": "Concise evidence-grounded explanation of the assessment.",
+      "type": "string"
+    },
+    "reversibleUntil": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Recorded exit deadline when established, otherwise null."
+    },
+    "schemaVersion": {
+      "const": "exitproof-reversibility.v1",
+      "description": "ExitProof reversibility result schema version."
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "assessment",
+    "merchant",
+    "commitmentType",
+    "amountMinor",
+    "currency",
+    "evaluatedAt",
+    "reason",
+    "evidence",
+    "limitations",
+    "paidExitManifestAvailable",
+    "paidExitPackAvailable",
+    "caseDigest"
+  ],
+  "type": "object"
+}
    • Changedcreate_exit_manifest27 fields changed
      • addedInput schema / description
        Added value: +"One contemplated or existing commitment to evaluate. merchant, commitment_type, and amount are required. Transaction-specific checkout_terms are the strongest input when available; maintained policy evidence can add context but never overrides conflicting transaction-specific terms."
      • addedInput schema / properties / amount / description
        Added value: +"Commitment amount in major currency units, for example 125.50 for USD 125.50. Must be non-negative and uses currency below for all monetary interpretation."
      • addedInput schema / properties / checkout_terms / description
        Added value: +"Transaction-specific cancellation, refund, renewal, charge, and loss terms observed for this exact commitment. Supply these whenever available; they control the transaction-specific assessment while maintained policy evidence remains contextual."
      • addedInput schema / properties / checkout_terms / properties / auto_renews / description
        Added value: +"Whether the supplied transaction terms explicitly state that the commitment renews automatically."
      • addedInput schema / properties / checkout_terms / properties / cancellable / description
        Added value: +"Whether the supplied transaction terms explicitly state that the commitment can be canceled."
      • changedInput schema / properties / checkout_terms / properties / cancellation_deadline / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 timestamp with explicit timezone for the stated cancellation deadline, even when cancellation may involve a loss."
      • addedInput schema / properties / checkout_terms / properties / cancellation_method / description
        Added value: +"Recorded method or path for cancellation/refund, such as an account page, support channel, or merchant instruction. This can make a later exit pack actionable."
      • addedInput schema / properties / checkout_terms / properties / cancellation_penalty_amount / description
        Added value: +"Stated cancellation penalty in major units of currency. Mutually exclusive with cancellation_penalty_percent."
      • addedInput schema / properties / checkout_terms / properties / cancellation_penalty_percent / description
        Added value: +"Stated cancellation penalty as a percentage from 0 to 100. Mutually exclusive with cancellation_penalty_amount."
      • addedInput schema / properties / checkout_terms / properties / charge_timing / description
        Added value: +"When the merchant states the charge will occur, such as immediately, at check-in, or 24 hours before renewal."
      • changedInput schema / properties / checkout_terms / properties / free_cancellation_until / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 deadline with explicit timezone through which the supplied terms state cancellation is free."
      • addedInput schema / properties / checkout_terms / properties / nonrefundable_amount / description
        Added value: +"Amount explicitly stated as nonrefundable, in major units of currency."
      • changedInput schema / properties / checkout_terms / properties / observed_at / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 timestamp with explicit timezone for when the caller observed these checkout terms."
      • addedInput schema / properties / checkout_terms / properties / refundable / description
        Added value: +"Whether the supplied transaction terms explicitly state that the committed amount is refundable."
      • addedInput schema / properties / checkout_terms / properties / renewal_interval / description
        Added value: +"Human-readable renewal interval from the supplied terms, such as monthly or annually. Use only when auto-renewal terms are stated."
      • addedInput schema / properties / checkout_terms / properties / source_url / description
        Added value: +"HTTP(S) source URL for the supplied transaction terms. ExitProof removes credentials, query parameters, and fragments before storing the URL."
      • changedInput schema / properties / client_reference / description
        Previous value: -"Optional caller-owned reference. ExitProof stores only a SHA-256 hash."New value: +"Optional caller-owned correlation reference. ExitProof stores only a SHA-256 hash; do not place secrets or sensitive personal data here."
      • addedInput schema / properties / commitment_type / description
        Added value: +"Closest category for the commitment being evaluated. This affects policy matching and should describe what the user is committing to, not the payment method."
      • addedInput schema / properties / country / description
        Added value: +"Optional two-letter ISO 3166-1 alpha-2 country code, such as US. Used to scope maintained policy rules when geography matters."
      • addedInput schema / properties / country / pattern
        Added value: +"^[A-Za-z]{2}$"
      • addedInput schema / properties / currency / description
        Added value: +"Three-letter ISO 4217 currency code for amount and all monetary checkout terms. Defaults to USD."
      • addedInput schema / properties / event_type / description
        Added value: +"Lifecycle event for this commitment. Use renewal for a recurring renewal, reservation for a booking event, deposit for a deposit event, or leave omitted for an initial commitment."
      • changedInput schema / properties / expected_commitment_at / description
        Previous value: -"RFC 3339 timestamp with explicit timezone."New value: +"RFC 3339 timestamp with explicit timezone for when the commitment is expected to occur. ExitProof evaluates time windows at the later of now and this timestamp."
      • addedInput schema / properties / merchant / description
        Added value: +"Merchant, platform, provider, or counterparty name exactly enough to identify the commitment. Used to match maintained policy overlays; do not include account numbers, credentials, or secrets."
      • addedInput schema / properties / purchase_channel / description
        Added value: +"Where the commitment is being made or billed. Use apple or google_play when that billing platform controls cancellation/refund rules; use direct for the merchant itself."
      • addedInput schema / properties / region / description
        Added value: +"Optional state, province, or region label when the commitment or merchant terms are region-specific."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Durable privacy-minimized Exit Manifest plus the bearer access token returned to the caller.",
+  "properties": {
+    "accessToken": {
+      "description": "Secret bearer token required with manifestId for later retrieval or exit-pack creation. ExitProof does not store this token in plaintext.",
+      "type": "string"
+    },
+    "accessTokenReissuedForSettlementRecovery": {
+      "description": "True only when deterministic settlement recovery re-derived the access token after a settled delivery failure.",
+      "type": "boolean"
+    },
+    "accessTokenReturnedOnce": {
+      "description": "Whether this response is the first normal return of the access token.",
+      "type": "boolean"
+    },
+    "assessment": {
+      "description": "Reversibility assessment preserved in the manifest.",
+      "type": "string"
+    },
+    "createdAt": {
+      "description": "Manifest creation timestamp.",
+      "type": "string"
+    },
+    "expiresAt": {
+      "description": "Manifest expiration timestamp.",
+      "type": "string"
+    },
+    "manifestId": {
+      "description": "Unguessable identifier for the stored Exit Manifest.",
+      "type": "string"
+    },
+    "paidExitPackAvailable": {
+      "description": "Whether the stored manifest is eligible for an exit-pack preflight at creation time.",
+      "type": "boolean"
+    },
+    "privacyNote": {
+      "description": "How ExitProof protects and may recover the access token.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "manifestId",
+    "createdAt",
+    "expiresAt",
+    "assessment",
+    "accessToken",
+    "accessTokenReturnedOnce",
+    "privacyNote"
+  ],
+  "type": "object"
+}
    • Changedget_exit_manifest4 fields changed
      • addedInput schema / description
        Added value: +"Credentials for one previously created Exit Manifest. Both values are required together and are returned by create_exit_manifest or settlement recovery."
      • addedInput schema / properties / access_token / description
        Added value: +"Secret bearer token returned by create_exit_manifest or deterministic settlement recovery. Required with manifest_id; treat it like a credential and do not log or expose it."
      • addedInput schema / properties / manifest_id / description
        Added value: +"Unguessable Exit Manifest identifier returned by create_exit_manifest. It starts with xm_ followed by 32 lowercase hexadecimal characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "description": "Authenticated read of one previously stored Exit Manifest.",
+  "properties": {
+    "manifest": {
+      "additionalProperties": true,
+      "description": "Stored Exit Manifest. This read does not refresh or reinterpret the original evidence.",
+      "type": "object"
+    },
+    "schemaVersion": {
+      "const": "exitproof-manifest-read.v1",
+      "description": "Manifest-read response schema version."
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "manifest"
+  ],
+  "type": "object"
+}
    • Changedlist_supported_policies2 fields changed
      • addedInput schema / description
        Added value: +"No parameters. This tool lists the current maintained policy-overlay catalog."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "description": "Maintained merchant-policy overlay catalog. This is coverage metadata, not a statement that unlisted merchants cannot be evaluated.",
+  "properties": {
+    "important": {
+      "description": "Coverage caveat explaining that transaction-specific checkout terms can be used for any merchant.",
+      "type": "string"
+    },
+    "merchants": {
+      "description": "Merchants with maintained policy overlays.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "aliases": {
+            "description": "Names that map to this merchant policy overlay.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "displayName": {
+            "description": "Human-readable merchant name.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Stable maintained-policy merchant identifier.",
+            "type": "string"
+          },
+          "ruleIds": {
+            "description": "Maintained rule identifiers available for this merchant.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "id",
+          "displayName",
+          "aliases",
+          "ruleIds"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "policySnapshot": {
+      "additionalProperties": true,
+      "description": "Version and verification date for the maintained policy snapshot.",
+      "type": "object"
+    },
+    "schemaVersion": {
+      "const": "exitproof-supported-policies.v1",
+      "description": "Supported-policy response schema version."
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "policySnapshot",
+    "important",
+    "merchants"
+  ],
+  "type": "object"
+}
  4. 4 tool updates
    • Changedbuild_exit_pack2 fields changed
      • addedInput schema / properties / access_token / pattern
        Added value: +"^xp_[A-Za-z0-9_-]{20,}$"
      • addedInput schema / properties / manifest_id / pattern
        Added value: +"^xm_[a-f0-9]{32}$"
    • Changedcheck_reversibility11 fields changed
      • addedInput schema / properties / checkout_terms / properties / cancellation_deadline / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / checkout_terms / properties / cancellation_deadline / format
        Added value: +"date-time"
      • addedInput schema / properties / checkout_terms / properties / free_cancellation_until / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / checkout_terms / properties / free_cancellation_until / format
        Added value: +"date-time"
      • addedInput schema / properties / checkout_terms / properties / observed_at / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / checkout_terms / properties / observed_at / format
        Added value: +"date-time"
      • addedInput schema / properties / currency / maxLength
        Added value: +3
      • addedInput schema / properties / currency / minLength
        Added value: +3
      • addedInput schema / properties / currency / pattern
        Added value: +"^[A-Za-z]{3}$"
      • addedInput schema / properties / expected_commitment_at / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / expected_commitment_at / format
        Added value: +"date-time"
    • Changedcreate_exit_manifest11 fields changed
      • addedInput schema / properties / checkout_terms / properties / cancellation_deadline / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / checkout_terms / properties / cancellation_deadline / format
        Added value: +"date-time"
      • addedInput schema / properties / checkout_terms / properties / free_cancellation_until / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / checkout_terms / properties / free_cancellation_until / format
        Added value: +"date-time"
      • addedInput schema / properties / checkout_terms / properties / observed_at / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / checkout_terms / properties / observed_at / format
        Added value: +"date-time"
      • addedInput schema / properties / currency / maxLength
        Added value: +3
      • addedInput schema / properties / currency / minLength
        Added value: +3
      • addedInput schema / properties / currency / pattern
        Added value: +"^[A-Za-z]{3}$"
      • addedInput schema / properties / expected_commitment_at / description
        Added value: +"RFC 3339 timestamp with explicit timezone."
      • addedInput schema / properties / expected_commitment_at / format
        Added value: +"date-time"
    • Changedget_exit_manifest2 fields changed
      • addedInput schema / properties / access_token / pattern
        Added value: +"^xp_[A-Za-z0-9_-]{20,}$"
      • addedInput schema / properties / manifest_id / pattern
        Added value: +"^xm_[a-f0-9]{32}$"
  5. 5 tool updates
    • First observedbuild_exit_pack
    • First observedcheck_reversibility
    • First observedcreate_exit_manifest
    • First observedget_exit_manifest
    • First observedlist_supported_policies

Publisher details

Operator
Davisville Labs LLC · Publisher source
Operator website
https://davisvillelabs.com · Publisher source
Vendor relationship
First-party · Publisher source
Documentation
https://exitproof.davisvillelabs.com/llms.txt · Publisher source
Trust center
Not available
Restrictions
Not applicable

Related MCP Connectors

Related MCP Servers

  • io.github.oleg-vdv/kepil

    oleg-vdv
    A
    license
    B
    quality
    B
    maintenance
    Enables AI agents to execute actions under an accountability layer with identity passports, mandates, a permission gate, and a tamper-evident journal, while requiring human confirmation for irreversible operations.
    7
    34 PyPI
    5
    AGPL 3.0

  • interlock-mcp

    Zigerus
    A
    license
    Not graded
    quality
    C
    maintenance
    A human-in-the-loop governance interlock for AI agents. Agents propose changes, a human countersigns the exact plan, and then it executes stage by stage with precondition checks, verification, and auditing.
    Apache 2.0
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources