Skip to main content
Glama

Cancel a subscription

cancel_subscription
DestructiveIdempotent

Ends the subscription at the end of its current period. That period is still charged for if a release came out in it.

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": {
      "id": "<id>",
      "context": "<context>"
    },
    "name": "cancel_subscription"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as "the user" or "a buyer".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as \"the user\" or \"a buyer\".",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "id"
      -]New value: +[
      +  "id",
      +  "context"
      +]
  2. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds the non-obvious behavior that termination is deferred to period end rather than immediate, plus a billing consequence tied to releases. That is genuine value beyond the structured fields. It still omits reversibility (whether the pending cancellation can be undone), access duration until period end, and the response shape.

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?

Two short sentences with the key timing constraint front-loaded and no filler. The second sentence is awkwardly worded ('still charged for if a release came out in it'), which slightly blurs the billing rule it is trying to convey.

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

Completeness3/5

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

For a small two-parameter mutation with no output schema, the description covers the core effect and the deferred timing, which is the main thing an agent needs. It leaves gaps on the required identifier, reversibility, and what the caller receives back, so it is adequate rather than complete.

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

Parameters2/5

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

Schema description coverage is 50%: the 'context' parameter is fully documented in the schema while the required 'id' uuid parameter has no description anywhere. The tool description says nothing about either parameter, so it does not compensate for the undocumented identifier — an agent gets no confirmation of whether 'id' is a subscription id, plan id, or user id.

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?

States a specific verb and resource ('Ends the subscription') plus the crucial timing semantics ('at the end of its current period'), which distinguishes a scheduled end from an immediate cancellation. It does not differentiate itself from the sibling resume_subscription or mention that a counterpart action exists, so it stops short of 5.

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

Usage Guidelines2/5

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

No guidance on when to prefer this over alternatives (e.g. the resume path) and no prerequisites such as ownership or subscription-state requirements. The agent must infer that only an active subscription can be cancelled and what happens if it is already scheduled to end.

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