Decide Policy Notaries
Server Details
Fail-closed refund, cancellation, return, and trial checks for 100 US subscription vendors.
- Status
- Healthy
- Uptime
- 99.9% over 56 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- decidefyi/decide
- GitHub Stars
- 1
- Server Listing
- decide
TDQS
Scored across 4 tools
The tools target distinct policy questions, but refund_eligibility and return_eligibility are very close in meaning for subscription purchases, both evaluating whether money can be recovered or a purchase reversed. Cancellation_penalty and trial_terms are clearer, but the overlap between refund and return creates a real risk of misselection.
All tool names follow a consistent snake_case noun-phrase pattern: cancellation_penalty, refund_eligibility, return_eligibility, trial_terms. The naming is predictable and readable throughout.
Four tools is a well-scoped set for a focused policy-decision server covering cancellation, refund, return, and trial scenarios. Each tool appears to earn its place without excessive surface area.
The set covers the main subscription policy decision points: cancellation terms, refunds, returns, and trials. Minor gaps may exist for related areas like auto-renewal or vendor-specific escalation paths, but core workflows are represented.
Available Tools
4 toolscancellation_penaltyCheck cancellation penaltyARead-onlyIdempotentInspect
Check US subscription cancellation terms without executing cancellation. Known vendors include review-only and retired scopes: their presence is not automation support. Adobe requires manual contract review. Typeform requires Basic, direct/self-serve platform scope and returns CANCEL_AT_PERIOD_END, not an immediate cancellation or refund. Missing scope, retired sources or unavailable current evidence return UNKNOWN.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | Use 'basic' for Typeform; 'individual' for other supported vendors. | |
| region | Yes | Region code. Currently only 'US' is supported. | |
| vendor | Yes | Vendor identifier (lowercase, underscore-separated). | |
| product | No | Required for Typeform. Excludes payments collected from form respondents. | |
| contract_type | No | Required for Typeform. Custom and enterprise contracts are not covered. | |
| billing_cadence | No | Required when the vendor applies different cancellation terms to monthly and annual plans. | |
| purchase_channel | No | Required for Typeform. Third-party purchases are not covered. | |
| requested_action | No | Required for Typeform. Checks ending renewal at the paid term end; does not execute it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| policy | No | |
| refund | No | |
| vendor | No | |
| message | Yes | |
| penalty | No | |
| verdict | Yes | |
| notice_days | No | |
| source_hash | No | |
| evaluated_at | No | |
| rules_version | No | |
| policy_version | No | |
| automation_safe | No | |
| billing_cadence | No | |
| policy_evidence | No | |
| rulebook_result | No | |
| required_context | No | |
| policy_source_url | No | |
| execution_performed | No | |
| policy_last_checked | No | |
| policy_source_notes | No | |
| cancellation_confirmed | No | |
| cancellation_effective | No | |
| policy_last_verified_utc | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuine behavioral context: it does not execute cancellation, Typeform returns CANCEL_AT_PERIOD_END rather than an immediate cancel or refund, and missing scope yields UNKNOWN. This goes meaningfully 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, which is good. The middle sentences are dense jargon ('review-only and retired scopes: their presence is not automation support') that is cryptic and may not earn its place without further explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail is not required, and the description still communicates the key return semantics (UNKNOWN, CANCEL_AT_PERIOD_END). For an 8-parameter tool with full schema coverage, it is largely complete, though it leaves the 'review-only/retired scope' concept undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by tying parameters together in natural language ('Typeform requires Basic, direct/self-serve platform scope'), clarifying how the enum values must be combined rather than just listing them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check US subscription cancellation terms') and immediately bounds it with 'without executing cancellation'. It is clearly distinct in scope from siblings like refund_eligibility and trial_terms, though it never names those siblings to route the agent explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys usage limits well (Adobe is manual-only, Typeform needs specific scope, unavailable evidence returns UNKNOWN), which helps the agent interpret results. However, it gives no explicit when-to-use-this-vs-alternative guidance relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refund_eligibilityCheck refund eligibilityARead-onlyIdempotentInspect
Evaluate a US consumer subscription refund against versioned source-backed rules. Returns UNKNOWN when required conditions are absent or the vendor requires approval or manual policy review.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | Plan type. Currently only 'individual' plans are supported. | |
| region | Yes | Region code. Currently only 'US' is supported. | |
| vendor | Yes | Vendor identifier (lowercase, underscore-separated). | |
| days_since_purchase | Yes | Number of days since the subscription was purchased. | |
| qualifying_conditions_met | No | Required when the vendor policy has source-specific conditions such as first purchase, unused benefits, or an eligible annual plan. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| vendor | No | |
| message | Yes | |
| verdict | Yes | |
| refundable | No | |
| source_hash | No | |
| window_days | No | |
| evaluated_at | No | |
| rules_version | No | |
| policy_version | No | |
| automation_safe | No | |
| policy_evidence | No | |
| rulebook_result | No | |
| required_context | No | |
| policy_source_url | No | |
| days_since_purchase | No | |
| policy_last_checked | No | |
| policy_source_notes | No | |
| policy_last_verified_utc | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-open-world), so the bar is lower. The description adds real behavioral value by disclosing the UNKNOWN outcome path — absent conditions or vendor-approval/manual-review cases — which tells the agent results may be tri-state rather than a clean boolean.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, purpose front-loaded, with the UNKNOWN behavior as the supporting clause. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and the description covers scope (US consumer subscriptions), rule provenance, and the UNKNOWN case. The one real gap is absent routing guidance against the sibling eligibility/penalty/trial tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so vendor/plan/region/days_since_purchase are fully documented in the schema. The description adds no parameter-level detail beyond a loose allusion to "required conditions," which only faintly maps to qualifying_conditions_met; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Evaluate") and resource ("a US consumer subscription refund against versioned source-backed rules"), which is far more precise than the title. The subject matter implicitly separates it from cancellation_penalty and trial_terms, but it never names or distinguishes the close sibling return_eligibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what happens when conditions are unmet, but gives no when-to-use guidance and no routing versus return_eligibility, cancellation_penalty or trial_terms. The agent must infer selection from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
return_eligibilityCheck return eligibilityBRead-onlyIdempotentInspect
Evaluate whether a US consumer subscription purchase can be reversed under versioned source-backed rules. Returns UNKNOWN when required conditions are absent or manual review is required.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | Plan type. Currently only 'individual' plans are supported. | |
| region | Yes | Region code. Currently only 'US' is supported. | |
| vendor | Yes | Vendor identifier (lowercase, underscore-separated). | |
| days_since_purchase | Yes | Number of days since the subscription was purchased. | |
| qualifying_conditions_met | No | Required when the vendor policy has source-specific conditions such as first purchase, unused benefits, or an eligible annual plan. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| method | No | |
| vendor | No | |
| message | Yes | |
| verdict | Yes | |
| returnable | No | |
| return_type | No | |
| source_hash | No | |
| evaluated_at | No | |
| rules_version | No | |
| policy_version | No | |
| automation_safe | No | |
| policy_evidence | No | |
| rulebook_result | No | |
| required_context | No | |
| policy_source_url | No | |
| return_window_days | No | |
| days_since_purchase | No | |
| policy_last_checked | No | |
| policy_source_notes | No | |
| policy_last_verified_utc | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds one genuinely useful behavioral note, the UNKNOWN fallback when conditions are absent or manual review is required, but nothing about the versioned-rule sourcing or what triggers manual review.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and followed by the key output caveat; nothing is wasted. Slightly terse for the disambiguation burden this tool carries, but structurally clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be re-explained, and annotations cover the safety profile. However, the description does not disambiguate from the near-identical sibling refund_eligibility, which is the main thing an agent needs in this family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters including the enum constraints and the conditional nature of qualifying_conditions_met. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Evaluate') and resource ('whether a US consumer subscription purchase can be reversed'). The scope is clear, but it never distinguishes itself from the sibling refund_eligibility, which reads almost identically to an agent choosing between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of the obvious alternatives (refund_eligibility, cancellation_penalty, trial_terms). An agent must infer which sibling applies from the name alone, which is risky given how similar these four are.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trial_termsCheck trial termsARead-onlyIdempotentInspect
Evaluate a live US consumer subscription trial offer. Supply observed availability, duration, card, and auto-conversion facts; the tool returns UNKNOWN instead of inferring current offers from static data.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | Plan type. Currently only 'individual' plans are supported. | |
| region | Yes | Region code. Currently only 'US' is supported. | |
| vendor | Yes | Vendor identifier (lowercase, underscore-separated). | |
| offer_confirmed | No | For account- or promotion-specific trials, whether a live offer has been confirmed for this account. | |
| observed_trial_days | No | Trial duration shown by the confirmed live offer. Required when offer_confirmed is true for a variable offer. | |
| observed_auto_converts | No | Whether the confirmed live offer converts to a paid subscription after the trial. | |
| observed_card_required | No | Whether the confirmed live offer requires a payment card. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| vendor | No | |
| message | Yes | |
| verdict | Yes | |
| trial_days | No | |
| source_hash | No | |
| evaluated_at | No | |
| auto_converts | No | |
| card_required | No | |
| rules_version | No | |
| policy_version | No | |
| automation_safe | No | |
| policy_evidence | No | |
| rulebook_result | No | |
| trial_available | No | |
| required_context | No | |
| policy_source_url | No | |
| policy_last_checked | No | |
| policy_source_notes | No | |
| policy_last_verified_utc | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive) and closed-world scope, so the description does not need to restate them. It adds a genuinely non-obvious behavioral trait: the tool returns UNKNOWN rather than inferring current offers from static data, which tells the agent not to expect a best-guess fallback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first establishes purpose and scope, the second establishes the input contract and the UNKNOWN behavior. Purpose is front-loaded ahead of the secondary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With seven parameters, full schema coverage, an output schema, and rich annotations, the description only needs to carry purpose and the distinctive UNKNOWN fallback behavior, which it does. It could note the account- or promotion-specific nature of certain trials more explicitly, but nothing critical to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the enum constraints, required fields, and per-parameter meanings are fully documented in the schema. The description restates the observed fact categories (availability, duration, card, auto-conversion) but adds no format or dependency detail beyond that, which fits the baseline 3 when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (evaluate) and resource (live US consumer subscription trial offer), which cleanly separates it from cancellation_penalty, refund_eligibility, and return_eligibility. It also signals an input requirement (observed facts). It stops short of naming how it differs from those siblings directly, but the resource scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (you must have observed availability, duration, card, and auto-conversion facts) and the condition where the tool is appropriate versus guessing from static data. However, it never explicitly routes the agent to or away from the sibling tools, so usage is only implicitly framed.
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.
4 tool updates
- Changed
cancellation_penalty1 field changed- changed
Output schema / properties / policy_last_verified_utc / typePrevious value: -"string"New value: +[ + "string", + "null" +]
- Changed
refund_eligibility1 field changed- changed
Output schema / properties / policy_last_verified_utc / typePrevious value: -"string"New value: +[ + "string", + "null" +]
- Changed
return_eligibility1 field changed- changed
Output schema / properties / policy_last_verified_utc / typePrevious value: -"string"New value: +[ + "string", + "null" +]
- Changed
trial_terms1 field changed- changed
Output schema / properties / policy_last_verified_utc / typePrevious value: -"string"New value: +[ + "string", + "null" +]
1 tool update
- Changed
cancellation_penalty12 fields changed- added
Input schema / properties / contract_typeAdded value: +{ + "description": "Required for Typeform. Custom and enterprise contracts are not covered.", + "enum": [ + "self_serve" + ], + "type": "string" +} - changed
Input schema / properties / plan / descriptionPrevious value: -"Plan type. Currently only 'individual' plans are supported."New value: +"Use 'basic' for Typeform; 'individual' for other supported vendors." - changed
Input schema / properties / plan / enumPrevious value: -[ - "individual" -]New value: +[ + "individual", + "basic" +] - added
Input schema / properties / productAdded value: +{ + "description": "Required for Typeform. Excludes payments collected from form respondents.", + "enum": [ + "platform_subscription" + ], + "type": "string" +} - added
Input schema / properties / purchase_channelAdded value: +{ + "description": "Required for Typeform. Third-party purchases are not covered.", + "enum": [ + "direct" + ], + "type": "string" +} - added
Input schema / properties / requested_actionAdded value: +{ + "description": "Required for Typeform. Checks ending renewal at the paid term end; does not execute it.", + "enum": [ + "cancel_at_period_end" + ], + "type": "string" +} - changed
Input schema / properties / vendor / enumPrevious value: -[ - "1password", - "adobe", - "amazon_music_unlimited", - "amazon_prime", - "amc_plus", - "apple_app_store", - "apple_arcade", - "apple_music", - "apple_tv_plus", - "audible", - "bitwarden", - "britbox", - "bumble", - "calm", - "canva", - "chatgpt_plus", - "claude_pro", - "coursera_plus", - "crunchyroll", - "dashlane", - "deezer", - "discord_nitro", - "discovery_plus", - "disney_plus", - "doordash_dashpass", - "dropbox_us", - "duolingo", - "ea_play", - "espn_plus", - "evernote", - "expressvpn", - "figma", - "fitbit_premium", - "fubo_tv", - "github_pro", - "google_one", - "google_play", - "grammarly", - "headspace", - "hellofresh", - "hinge", - "hulu", - "icloud_plus", - "instacart_plus", - "keeper", - "kindle_unlimited", - "lastpass", - "linkedin_premium", - "masterclass", - "max", - "microsoft_365", - "midjourney", - "mlb_tv", - "myfitnesspal_premium", - "netflix", - "new_york_times", - "nfl_plus", - "nintendo_switch_online", - "noom", - "nordvpn", - "notion", - "paramount_plus", - "patreon", - "peacock", - "peloton", - "playstation_plus", - "proton", - "reddit_premium", - "ring_protect", - "roblox_premium", - "scribd", - "shutterstock", - "siriusxm", - "slack", - "sling_tv", - "snapchat_plus", - "soundcloud_go", - "spotify", - "squarespace", - "starz", - "strava", - "substack", - "surfshark", - "telegram_premium", - "tidal", - "tinder", - "todoist", - "twitch", - "uber_one", - "ubisoft_plus", - "wall_street_journal", - "walmart_plus", - "washington_post", - "weightwatchers", - "wix", - "x_premium", - "xbox_game_pass", - "youtube_premium", - "youtube_tv", - "zoom" -]New value: +[ + "1password", + "adobe", + "amazon_music_unlimited", + "amazon_prime", + "amc_plus", + "apple_app_store", + "apple_arcade", + "apple_music", + "apple_tv_plus", + "audible", + "bitwarden", + "britbox", + "bumble", + "calm", + "canva", + "chatgpt_plus", + "claude_pro", + "coursera_plus", + "crunchyroll", + "dashlane", + "deezer", + "discord_nitro", + "discovery_plus", + "disney_plus", + "doordash_dashpass", + "dropbox_us", + "duolingo", + "ea_play", + "espn_plus", + "evernote", + "expressvpn", + "figma", + "fitbit_premium", + "fubo_tv", + "github_pro", + "google_one", + "google_play", + "grammarly", + "headspace", + "hellofresh", + "hinge", + "hulu", + "icloud_plus", + "instacart_plus", + "keeper", + "kindle_unlimited", + "lastpass", + "linkedin_premium", + "masterclass", + "max", + "microsoft_365", + "midjourney", + "mlb_tv", + "myfitnesspal_premium", + "netflix", + "new_york_times", + "nfl_plus", + "nintendo_switch_online", + "noom", + "nordvpn", + "notion", + "paramount_plus", + "patreon", + "peacock", + "peloton", + "playstation_plus", + "proton", + "reddit_premium", + "ring_protect", + "roblox_premium", + "scribd", + "shutterstock", + "siriusxm", + "slack", + "sling_tv", + "snapchat_plus", + "soundcloud_go", + "spotify", + "squarespace", + "starz", + "strava", + "substack", + "surfshark", + "telegram_premium", + "tidal", + "tinder", + "todoist", + "twitch", + "typeform", + "uber_one", + "ubisoft_plus", + "wall_street_journal", + "walmart_plus", + "washington_post", + "weightwatchers", + "wix", + "x_premium", + "xbox_game_pass", + "youtube_premium", + "youtube_tv", + "zoom" +] - added
Output schema / properties / cancellation_confirmedAdded value: +{ + "const": false, + "type": "boolean" +} - added
Output schema / properties / cancellation_effectiveAdded value: +{ + "enum": [ + "paid_term_end" + ], + "type": "string" +} - added
Output schema / properties / execution_performedAdded value: +{ + "const": false, + "type": "boolean" +} - added
Output schema / properties / refundAdded value: +{ + "enum": [ + "not_evaluated" + ], + "type": "string" +} - changed
Output schema / properties / verdict / enumPrevious value: -[ - "FREE_CANCEL", - "PENALTY", - "LOCKED", - "UNKNOWN" -]New value: +[ + "FREE_CANCEL", + "CANCEL_AT_PERIOD_END", + "PENALTY", + "LOCKED", + "UNKNOWN" +]
4 tool updates
- Changed
cancellation_penalty3 fields changed- added
Output schema / properties / automation_safeAdded value: +{ + "type": "boolean" +} - changed
Output schema / properties / billing_cadence / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Output schema / properties / policy_evidenceAdded value: +{ + "additionalProperties": true, + "properties": { + "checked_at": { + "type": "string" + }, + "current": { + "type": "boolean" + }, + "evaluated_at": { + "type": "string" + }, + "policy": { + "enum": [ + "refund", + "cancel", + "return", + "trial" + ], + "type": "string" + }, + "policy_version": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "schema_version": { + "enum": [ + "policy_evidence_v1" + ], + "type": "string" + }, + "snapshot_generated_at": { + "type": "string" + }, + "snapshot_hash": { + "type": "string" + }, + "source_hash": { + "type": "string" + }, + "source_url": { + "type": "string" + }, + "status": { + "enum": [ + "current", + "expired", + "unavailable", + "review_required" + ], + "type": "string" + }, + "valid_until": { + "type": [ + "string", + "null" + ] + }, + "vendor": { + "type": "string" + }, + "verified_at": { + "type": "string" + } + }, + "required": [ + "schema_version", + "policy", + "vendor", + "status", + "reason", + "current", + "evaluated_at" + ], + "type": "object" +}
- Changed
refund_eligibility3 fields changed- added
Output schema / properties / automation_safeAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / policy_evidenceAdded value: +{ + "additionalProperties": true, + "properties": { + "checked_at": { + "type": "string" + }, + "current": { + "type": "boolean" + }, + "evaluated_at": { + "type": "string" + }, + "policy": { + "enum": [ + "refund", + "cancel", + "return", + "trial" + ], + "type": "string" + }, + "policy_version": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "schema_version": { + "enum": [ + "policy_evidence_v1" + ], + "type": "string" + }, + "snapshot_generated_at": { + "type": "string" + }, + "snapshot_hash": { + "type": "string" + }, + "source_hash": { + "type": "string" + }, + "source_url": { + "type": "string" + }, + "status": { + "enum": [ + "current", + "expired", + "unavailable", + "review_required" + ], + "type": "string" + }, + "valid_until": { + "type": [ + "string", + "null" + ] + }, + "vendor": { + "type": "string" + }, + "verified_at": { + "type": "string" + } + }, + "required": [ + "schema_version", + "policy", + "vendor", + "status", + "reason", + "current", + "evaluated_at" + ], + "type": "object" +} - changed
Output schema / properties / refundable / typePrevious value: -"boolean"New value: +[ + "boolean", + "null" +]
- Changed
return_eligibility3 fields changed- added
Output schema / properties / automation_safeAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / policy_evidenceAdded value: +{ + "additionalProperties": true, + "properties": { + "checked_at": { + "type": "string" + }, + "current": { + "type": "boolean" + }, + "evaluated_at": { + "type": "string" + }, + "policy": { + "enum": [ + "refund", + "cancel", + "return", + "trial" + ], + "type": "string" + }, + "policy_version": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "schema_version": { + "enum": [ + "policy_evidence_v1" + ], + "type": "string" + }, + "snapshot_generated_at": { + "type": "string" + }, + "snapshot_hash": { + "type": "string" + }, + "source_hash": { + "type": "string" + }, + "source_url": { + "type": "string" + }, + "status": { + "enum": [ + "current", + "expired", + "unavailable", + "review_required" + ], + "type": "string" + }, + "valid_until": { + "type": [ + "string", + "null" + ] + }, + "vendor": { + "type": "string" + }, + "verified_at": { + "type": "string" + } + }, + "required": [ + "schema_version", + "policy", + "vendor", + "status", + "reason", + "current", + "evaluated_at" + ], + "type": "object" +} - changed
Output schema / properties / returnable / typePrevious value: -"boolean"New value: +[ + "boolean", + "null" +]
- Changed
trial_terms2 fields changed- added
Output schema / properties / automation_safeAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / policy_evidenceAdded value: +{ + "additionalProperties": true, + "properties": { + "checked_at": { + "type": "string" + }, + "current": { + "type": "boolean" + }, + "evaluated_at": { + "type": "string" + }, + "policy": { + "enum": [ + "refund", + "cancel", + "return", + "trial" + ], + "type": "string" + }, + "policy_version": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "schema_version": { + "enum": [ + "policy_evidence_v1" + ], + "type": "string" + }, + "snapshot_generated_at": { + "type": "string" + }, + "snapshot_hash": { + "type": "string" + }, + "source_hash": { + "type": "string" + }, + "source_url": { + "type": "string" + }, + "status": { + "enum": [ + "current", + "expired", + "unavailable", + "review_required" + ], + "type": "string" + }, + "valid_until": { + "type": [ + "string", + "null" + ] + }, + "vendor": { + "type": "string" + }, + "verified_at": { + "type": "string" + } + }, + "required": [ + "schema_version", + "policy", + "vendor", + "status", + "reason", + "current", + "evaluated_at" + ], + "type": "object" +}
1 tool update
- Changed
trial_terms2 fields changed- added
Input schema / properties / observed_auto_convertsAdded value: +{ + "description": "Whether the confirmed live offer converts to a paid subscription after the trial.", + "type": "boolean" +} - added
Input schema / properties / observed_card_requiredAdded value: +{ + "description": "Whether the confirmed live offer requires a payment card.", + "type": "boolean" +}
4 tool updates
- First observed
cancellation_penalty - First observed
refund_eligibility - First observed
return_eligibility - First observed
trial_terms
Related MCP Connectors
Score a subscription cancellation flow against federal, CA, CO, VT, and OR click-to-cancel laws.
Score a subscription flow against US click-to-cancel / auto-renewal laws.
Check WooCommerce checkout-change risk using public evidence and privacy-safe store signals.
Verify companies, domains and counterparties before transacting. Sanctions, UBO, fraud scoring.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables agents to monitor transaction streams, detect recurring charges and price creeping, flag zombie subscriptions, and generate automated cancellation workflows.7MIT
- AlicenseNot gradedqualityBmaintenanceEnables autonomous detection of recurring charges, price creeping, and zombie subscriptions, then generates automated cancellation workflows through MCP-compatible tools.7MIT
- FlicenseNot gradedqualityBmaintenanceEnables AI shopping agents to verify whether a specific product can be returned by supplying a product URL and buyer country, returning a verified verdict with exact policy clauses, return window, and confidence score.-
- AlicenseNot gradedqualityBmaintenanceEnables tracking post-purchase prices across Shopify, Walmart, Best Buy, and Target, detecting drops within merchant price-match windows, verifying eligibility, and synthesizing automated refund claims.7MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.