Skip to main content
Glama

Add addresses to my unsubscribe list

suppression_add
Idempotent

Add your own addresses to your unsubscribe list (stored as keyed hashes). keep_address true also keeps them sealed so suppression_export gives them back. At most 50,000 per list.

Input Schema

NameRequiredDescriptionDefault
emailsYesPlain addresses, up to 1000.
reasonNoWhy (default manual).
instance_idYesUtility instance id from buy or list_utilities.
keep_addressNoAlso keep the address sealed for export (default false: hash only).
passport_tokenNoYour amp_ token, only if you have no app sign-in and cannot send a header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "emails": [
      +      "reader@example.com"
      +    ],
      +    "instance_id": "sup_exampleexampleexample2",
      +    "reason": "bounce"
      +  }
      +]
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."New value: +"Your amp_ token, only if you have no app sign-in and cannot send a header."
  2. Changed4 schema fields changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."New value: +"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."
    • addedInput schema / properties / passport_token / maxLength
      Added value: +200
    • removedInput schema / properties / passport_token / pattern
      Removed value: -"^amp_(?:s_)?[A-Za-z0-9_-]{43}$"
  3. Added

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations (idempotent, non-destructive write), it discloses that entries are stored as keyed hashes, that addresses are only recoverable if keep_address is set, and that each list caps at 50,000 — meaningful storage and quota context. It still omits what the call returns (count added vs. skipped duplicates), which matters for an idempotent add.

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?

Two short sentences with the core behavior front-loaded, followed by the recoverability caveat and the quota limit. No restatement of the title and no filler.

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?

For a 5-parameter write tool with full schema coverage and annotations, the description covers storage model, export interaction, and quota. The only gap is return behavior, which has no output schema to fall back on, so an agent cannot predict what a successful add reports back.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: keep_address is tied to recoverability via suppression_export, which the schema only gestures at. The '50,000 per list' cap also clarifies scale beyond the schema's per-call maxItems of 1000.

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 ('Add your own addresses to your unsubscribe list') and scopes it to the caller's own list, which distinguishes it from suppression_check/export/remove siblings. It does not name those siblings explicitly, so the differentiation is implicit rather than stated.

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?

The description implies when to use it (adding your own addresses to an unsubscribe list) and references suppression_export as the consumer when keep_address is true, but it gives no explicit when-not guidance or routing versus suppression_remove/suppression_check.

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.