Skip to main content
Glama

Stackcut

by io.stackcut
OverviewDiscussionsAdmin

How to cancel a subscription

get_exit_plan
Read-onlyIdempotent

Use when the user wants to cancel, unsubscribe from, pause or pay less for something they subscribe to: streaming, music, news, dating, cloud storage, AI tools, apps or business software ('cancel YouTube TV', 'how do I get out of Adobe', 'stop my Audible'). Returns Stackcut's exit plan: every way to cancel by who bills them (the company, Apple, Google Play, a partner or a contract), the steps with the words to expect on screen, when access ends, notice periods, fees and refunds, what to export first, cheaper ways to keep it, and notes for an agent, each fact sourced to the vendor's own page with a check date. Pass billed_by when known (the name on their card statement or receipt) and renewal_date to get the last safe day to cancel. Never cancel for the user without their go-ahead: they sign in, see any offer, and confirm the final step. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Input Schema

NameRequiredDescriptionDefault
goalNo
marketNoThe user's country, e.g. DE: when Stackcut has a guide checked for that market (JP, DE, BR, MX, NL), local_guide points to it
serviceYesThe subscription, e.g. 'YouTube TV', 'Adobe Creative Cloud', 'disneyplus.com'
billed_byNoWho charges them (card statement or receipt): the company (direct_web; direct_app in its app), Apple, Google Play, Amazon, Roku, PayPal, a phone or TV provider, a partner or a contract. Omit or 'unknown' for every route and the question to ask. Short words are aliases
months_leftNoMonthly payments left (else from renewal_date)
renewal_dateNoNext renewal date, YYYY-MM-DD: adds the last safe day to cancel from the documented notice period
monthly_priceNoUSD a month: with renewal_date or months_left, estimates an early termination fee

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / market / description
      Added value: +"The user's country, e.g. DE: when Stackcut has a guide checked for that market (JP, DE, BR, MX, NL), local_guide points to it"
  2. Changed2 schema fields changed
    • addedInput schema / properties / goal
      Added value: +{
+  "enum": [
+    "cancel",
+    "pay_less",
+    "renegotiate"
+  ],
+  "maxLength": 2000,
+  "type": "string"
+}
    • addedInput schema / properties / market
      Added value: +{
+  "maxLength": 2000,
+  "pattern": "^[A-Z]{2}$",
+  "type": "string"
+}
  3. Changed4 schema fields changed
    • changedInput schema / properties / billed_by / description
      Previous value: -"Who charges them (their card statement or receipt says): the company itself (direct_web), Apple, Google Play, Amazon, a phone/TV provider, a partner, or a business contract. Leave out or 'unknown' to get every route and the question to ask"New value: +"Who charges them (card statement or receipt): the company (direct_web; direct_app in its app), Apple, Google Play, Amazon, Roku, PayPal, a phone or TV provider, a partner or a contract. Omit or 'unknown' for every route and the question to ask. Short words are aliases"
    • changedInput schema / properties / billed_by / enum
      Previous value: -[
-  "direct_web",
-  "direct_app",
-  "apple_app_store",
-  "google_play",
-  "amazon",
-  "roku",
-  "paypal",
-  "carrier_or_isp",
-  "reseller_or_partner",
-  "sales_contract",
-  "unknown"
-]New value: +[
+  "direct_web",
+  "direct_app",
+  "apple_app_store",
+  "google_play",
+  "amazon",
+  "roku",
+  "paypal",
+  "carrier_or_isp",
+  "reseller_or_partner",
+  "sales_contract",
+  "unknown",
+  "apple",
+  "app_store",
+  "ios",
+  "itunes",
+  "google",
+  "android",
+  "play",
+  "carrier",
+  "isp",
+  "phone",
+  "cable",
+  "tv_provider",
+  "partner",
+  "bundle",
+  "reseller",
+  "marketplace",
+  "web",
+  "website",
+  "direct",
+  "online",
+  "company",
+  "app",
+  "in_app",
+  "contract",
+  "sales",
+  "enterprise",
+  "invoice"
+]
    • addedInput schema / properties / monthly_price
      Added value: +{
+  "description": "USD a month: with renewal_date or months_left, estimates an early termination fee",
+  "maximum": 100000,
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / months_left
      Added value: +{
+  "description": "Monthly payments left (else from renewal_date)",
+  "maximum": 120,
+  "minimum": 0,
+  "type": "integer"
+}
  4. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds rich context beyond them: it explains that the tool only returns a plan, that the agent must 'Never cancel for the user without their go-ahead', and details data storage practices (arguments stored, account keys hashed, no IPs). This goes well beyond the safety profile 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 front-loaded with the primary use case and then systematically covers return format, parameter advice, behavioral caveats, and privacy notes. It is dense but well-structured; however, it is quite long and the privacy section, while useful, could be trimmed without losing essential guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and moderate complexity, the description does a thorough job explaining what is returned (every cancellation route, steps, fees, etc.) and key behavioral constraints. It is nearly complete but omits any reference to sibling tools (e.g., search_exits) that an agent might need to choose correctly.

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 86%, so the schema already documents the parameters in detail. The description adds minor usage guidance for billed_by and renewal_date, but does not explain the other five parameters (goal, market, months_left, monthly_price) beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it 'Returns Stackcut's exit plan' with a clear enumeration of contents (cancellation routes by biller, steps, fees, etc.). It does not mention any sibling tool like search_exits, so it lacks explicit sibling differentiation, capping it at 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening sentence gives a clear when-to-use trigger: 'Use when the user wants to cancel, unsubscribe from, pause or pay less...'. It also advises passing billed_by and renewal_date. However, it never states when *not* to use this tool or names an alternative (e.g., search_exits), so no exclusions are provided.

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

All Stackcut toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources