Skip to main content
Glama

Cancel a card subscription

cancel_subscription
DestructiveIdempotent

Cancel the account's card-paid Professional plan at period end (provider "stripe", undo to keep it), or its PayPal subscription (provider "paypal"), exactly as the account page does. Prepaid terms bought with the balance never renew, so need no cancelling. Needs the "billing" scope.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "provider": "<provider>"
    },
    "name": "cancel_subscription"
  }
}

Input Schema

NameRequiredDescriptionDefault
undoNo
providerYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses several important behaviors: cancellation occurs at period end rather than immediately, the undo flag keeps the subscription, provider-specific handling differs, and the billing scope is required. This adds substantial context for a destructive billing mutation.

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 compact and front-loaded around the main action, then adds the important exceptions and permission requirement. Every clause adds useful operational meaning without 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?

There is no output schema, but the description covers the essential behavior for this billing mutation: timing, provider paths, undo semantics, prepaid exclusion, and required scope. An agent has enough information to invoke it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden. It explains the provider enum values by tying "stripe" to card-paid Professional cancellation and "paypal" to PayPal subscription cancellation, and it explains undo as keeping the subscription.

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 states a specific verb and resource: cancel the account's card-paid Professional plan or PayPal subscription. It clearly distinguishes Stripe and PayPal paths and explicitly excludes prepaid terms, so an agent can tell exactly what this tool does versus billing-related siblings.

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?

It gives clear conditions for use, including that card-paid plans cancel at period end and prepaid balance terms never renew so need no cancelling. It does not explicitly name an alternative sibling such as billing_portal_link, but the applicability conditions are otherwise clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources