Skip to main content
Glama

Agentalog — Agent Auto Log

Cancel plan

cancel_plan

Cancel the active plan. Nothing else is charged; a purchase under 7 days and a paid period that has not started are refunded and end now, and the rest of the paid period stays active until keeps_until. Requires accept_data_removal: true. Send { "accept_data_removal": true }. The monthly card subscription stops. A purchase made less than 7 days ago and a paid period that has not started yet, such as a renewal, go back the same way they were paid (card or Pix) and end now. The rest of the paid period stays active until keeps_until; then what the plan added ends (account.cancel.losses in GET /api/plans says what). A purchase paid with USDC or with credit from another purchase stays active until its end; ask for its refund by e-mail, as the cancellation page says.

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": {
      "accept_data_removal": "<accept_data_removal>"
    },
    "name": "cancel_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
accept_data_removalYesMust be `true`: you accept losing what the plan added.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

C2.9/5.0
Behavior1/5

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

The description says the caller must accept losing what the plan added and that plan-added capabilities end after keeps_until, which is a destructive effect. The annotations declare destructiveHint=false, so the description contradicts the structured safety signal.

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

Conciseness2/5

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

The description is front-loaded with the core action, but it is repetitive: the under-7-days refund rule is stated twice in nearly identical language. It also includes endpoint-detail prose that could be trimmed, making the overall definition longer and noisier than needed.

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?

The description covers the key behavioral context: required consent, refund timing, keeps_until retention, what happens to plan-added capabilities, and special handling for USDC or credit purchases. It is substantially complete for a one-parameter cancellation tool, though the destructive-effect framing conflicts with the annotations.

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 schema already fully documents the single accept_data_removal parameter. The description repeats the requirement and exact payload but adds no meaning beyond what the schema provides.

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 first sentence, "Cancel the active plan," states a specific verb and resource, so the core purpose is immediately clear. It does not explicitly differentiate itself from siblings like buy_plan or list_plans, but the cancel action is distinct enough for an agent to identify.

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

Usage Guidelines3/5

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

Usage is implied by the action name, and the description gives some when-not guidance by saying USDC or credit-funded purchases require an e-mail refund request. However, it never explicitly states when to choose this tool versus related billing or plan tools, so the routing guidance is only partial.

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.