addy-mcp

set_domain_default_recipient

Idempotent

Set or clear the default recipient for aliases on a custom domain. Route domain aliases to a chosen recipient, or reset to the account default.

Instructions

Set (or clear) the default recipient for aliases on a custom domain.

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>",
      "recipient_id": "<recipient_id>"
    },
    "name": "set_domain_default_recipient"
  }
}

Input Schema

Name	Required	Description	Default
`domain_id`	Yes	The id (UUID) of the item
`recipient_id`	Yes	Recipient id, or null to use the account default

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Nov 12, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety and idempotency profile is covered. The description adds the ability to clear the setting, but leaves important behavior unstated: whether the change affects existing aliases or only future ones, and what permissions are required for a custom domain. That is meaningful but modest added context on top of the annotations.

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 the action and scope front-loaded and no filler. It is efficient, though its brevity comes at the cost of the missing behavioral detail noted elsewhere rather than being a model of tight completeness.

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

Completeness3/5

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

With only two fully documented parameters, annotations covering the mutation/idempotency profile, and no output schema, the structured fields carry most of the load. Still, for a domain-level configuration mutation the description omits the scope of effect (existing vs. future aliases) and any prerequisites, leaving a gap an agent would want closed.

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%, so the schema already documents both domain_id (UUID) and recipient_id (including the null-to-use-account-default semantics). The description's "(or clear)" merely restates the null behavior already present in the schema, adding no new format, constraint, or edge-case meaning. Baseline 3 applies.

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 gives a specific verb ("Set (or clear)") and a specific resource ("default recipient for aliases on a custom domain"), which is enough to distinguish it from the near-sibling set_username_default_recipient by scope. It stops short of naming that sibling or otherwise explicitly differentiating, so it is clear but not maximally distinct.

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 (e.g., domain must already exist / be verified), and no mention of the obvious alternative set_username_default_recipient or set_domain_option. The only guidance is the parenthetical "(or clear)", which is about a mode of operation rather than about tool selection.

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

Deploy Server