Skip to main content
Glama
addy-mcp

addy-mcp

set_domain_option

Idempotent

Enable or disable custom domain options such as alias mail forwarding, catch-all address creation, and Family plan sharing to control how a domain handles incoming mail and member access.

Instructions

Turn a custom domain 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": {
      "domain_id": "<domain_id>",
      "option": "<option>",
      "enabled": "<enabled>"
    },
    "name": "set_domain_option"
  }
}

Input Schema

NameRequiredDescriptionDefault
optionYes'active': whether its aliases forward mail. 'catch_all': auto-create aliases for any address at the domain. 'shared_with_family': share with Family plan members (turning off starts a 14-day grace period).
enabledYes
domain_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 idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not say changes take effect immediately, that 'shared_with_family' off triggers a 14-day grace period (only visible in the schema), or what a failed toggle returns. For a mutation with no output schema, that is a meaningful gap.

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 front-loaded sentence with no filler or redundancy. Brevity is appropriate for a three-parameter toggle, though the sentence is thin rather than dense with information.

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?

The tool mutates live mail-forwarding behavior, yet the description conveys nothing about effects, timing, or reversibility, and there is no output schema to fall back on. The schema enum carries the real semantics, so the description under-serves a moderately consequential mutation.

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%, with the enum's three values richly documented inline (active/catch_all/shared_with_family semantics plus the grace period). The description contributes zero parameter meaning, so it does not compensate for the undocumented remainder such as domain_id format expectations.

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+resource: toggling a domain-level option on or off. The 'domain' qualifier distinguishes it from siblings like set_alias_option, set_recipient_option, and set_username_option. It stops short of naming which options exist or what effect they have, leaving that entirely to the schema enum.

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?

No when-to-use guidance, no prerequisites, and no routing to alternatives. An agent gets no hint that get_domain_options should be consulted first to see current state, or that set_domain_default_recipient handles a related but distinct concern.

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