Skip to main content
Glama

Remove subscriber

remove_subscriber
Destructive

Remove one email from your subscriber list. Removes a subscriber from your list, as Remove in the subscriber's menu does: they get no more emails from you and no notice. A paid subscription is cancelled and Substack refunds the unused part. An email not on your list returns an error; add_subscriber takes about a minute before the address is listed. By default you confirm each call; you can switch that off for this tool. Waits for the owner's approval.

Input Schema

NameRequiredDescriptionDefault
emailYesSubscriber's email address.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses key consequences: the subscriber gets no notice, paid subscriptions are cancelled with a partial refund, unknown emails cause an error, and calls are confirmed by default unless switched off. It also notes that the tool waits for owner approval, which is important operational context.

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 core action and then adds relevant consequences. It is slightly repetitive in the opening two sentences, but every later sentence contributes useful behavioral detail.

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?

For a destructive, single-parameter mutation with no output schema, the description covers the essential side effects, error condition, confirmation behavior, and approval requirement. An agent has enough context to invoke it correctly and understand the consequences.

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 coverage is 100%, so the single email parameter is already fully documented by the schema. The description reinforces that the email must already be on the list and that a missing email errors, but it does not add syntax or format meaning beyond the schema.

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 precise verb and resource: 'Remove one email from your subscriber list.' It also distinguishes the action from sibling add_subscriber by clarifying the effect and timing of adding versus removing.

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 context for use: removing a subscriber removes them from the list, sends no notice, cancels paid subscriptions, and returns an error if the email is not present. It does not explicitly name alternatives such as list_subscribers for verification, but the relevant sibling add_subscriber is referenced.

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.