Skip to main content
Glama
Sign In
addy-mcp

addy-mcp

by Former-Stranger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

remove_from_blocklist

Destructive

Remove blocklist entries by ID to unblock specific senders or addresses in your addy.io account.

Instructions

Unblock blocklist entries by id (see list_blocklist).

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": {
      "entry_ids": "<entry_ids>"
    },
    "name": "remove_from_blocklist"
  }
}

Input Schema

NameRequiredDescriptionDefault
entry_idsYesBlocklist entry ids (max 100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description is consistent with those hints but adds nothing beyond them — no mention of irreversibility, confirmation requirements, or partial-failure behavior on bulk ids.

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?

One short sentence, front-loaded with the action and resource, with no filler. The cross-reference is placed after the core statement so an agent gets the essential meaning first.

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 one-parameter removal tool with full schema coverage and complete destructive annotations, nothing critical is missing from the definition. A brief note on what happens to ids that do not exist would have made it complete.

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%: the single parameter documents 'Blocklist entry ids (max 100)' along with minItems/maxItems constraints. The description's 'by id' and the pointer to list_blocklist add only marginal meaning on top of that, which matches the baseline 3.

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 description names a specific verb and resource ('Unblock blocklist entries') and scopes it to 'by id', which is enough for an agent to distinguish it from add_to_blocklist and list_blocklist. It stops short of a 5 because the operation's effect (removal of the entry vs. merely deactivating it) is not spelled out.

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?

The parenthetical '(see list_blocklist)' gives actionable guidance on where to obtain the ids this tool requires, which is the main prerequisite for invoking it. There is no explicit statement of when not to use it or how it relates to add_to_blocklist, so it falls short of the 5 bar.

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

Deploy Server

Other Tools