Skip to main content
Glama
Sign In
addy-mcp

addy-mcp

by Former-Stranger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

set_recipient_option

Idempotent

Toggle addy.io recipient settings such as forwarding, reply/send permissions, encryption, and PGP handling by recipient ID, option, and enabled flag.

Instructions

Turn a recipient option on or off.

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": {
      "recipient_id": "<recipient_id>",
      "option": "<option>",
      "enabled": "<enabled>"
    },
    "name": "set_recipient_option"
  }
}

Input Schema

NameRequiredDescriptionDefault
optionYes'active': whether mail is forwarded to it. 'can_reply_send': whether it may reply/send from aliases. 'encryption': encrypt forwarded mail with its GPG key. 'inline_encryption': use PGP/Inline instead of PGP/MIME. 'protected_headers': hide the subject when encrypting. 'remove_pgp_keys' / 'remove_pgp_signatures': strip these from forwarded mail.
enabledYes
recipient_idYesThe id (UUID) of the item

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare this is a non-read-only but idempotent, non-destructive mutation, so safety is covered. The description adds nothing beyond that — it doesn't say changes persist immediately, whether they affect in-flight delivery or only future mail, whether keys must be uploaded first for the encryption options, or what a failure looks like. For a mutation tool, that leaves the behavioral burden largely unmet.

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?

A single short sentence with zero padding and the key information front-loaded. It is efficient, though the brevity reflects under-specification rather than disciplined editing, which is penalized elsewhere.

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

Completeness2/5

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

For a three-parameter mutation with no output schema and nothing in the description about effects, side effects, or return values, the definition is thin. The agent gets the full parameter detail from the schema but nothing about the consequences of toggling encryption, protected_headers, or remove_pgp_keys options.

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 coverage is 67% and the enum for 'option' is thoroughly documented in the schema itself, including the meaning of all seven values. The description adds no parameter meaning whatsoever — it doesn't even mention recipient_id, option, or enabled — so it fails to compensate for the uncovered 'enabled' parameter and adds no value over the schema.

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 (set/turn on or off) and a specific resource (recipient option), which distinguishes it from siblings like set_alias_option and set_domain_option at the resource level. It does not, however, say anything about what a 'recipient option' affects or what the tool returns.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the sibling option-setting tools (set_alias_option, set_domain_option, set_username_option) that an agent might confuse this with. The agent must infer the appropriate context entirely from the tool name.

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