Skip to main content
Glama

Update domain address

updateDomainAddress
Destructive

Change an address on a domain: its label, whether it takes mail, whether it keeps the original of every message it receives, where its mail goes (destination, webhookId, tapWebhookIds), when it expires (expiresAt, onExpiry) and, for a group, who may post (groupPosting, groupKeepCopy). A disabled address keeps its settings, and enabling it again restores it. An empty label clears it.

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": "<domain>",
      "address": "<address>"
    },
    "name": "updateDomainAddress"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNo
domainYesThe domain, by its id or by its name (example.com). listDomains names every one.
addressYesThe address, by its id, by the whole address (sales@example.com) or by the part before the @. listDomainAddresses names every one.
enabledNo
onExpiryNoWhat happens when the address expires. stop switches it off and keeps its mail, and delete removes the address and the conversations delivered to it.
expiresAtNoWhen the address expires, an RFC 3339 time from 60 seconds to 10 years ahead. Null keeps it for good. Setting it on an address that expired turns the address back on.
webhookIdNoThe webhook endpoint mail goes to while destination is webhook, an id that listWebhooks gives. Pass it with destination webhook.
destinationNoWhere mail to the address goes. mailbox keeps it here, forward only forwards it and needs a forwarding destination that is on, webhook sends every message to the endpoint in webhookId and keeps none here, and group sends it to the group members of the address.
groupPostingNoWho may send to a group address: anyone, members (its group members), or workspace (any address on a domain of this workspace).
keepOriginalNoTrue keeps every message the address receives from now on byte for byte as it arrived, so getRawMessage returns that original instead of a source rebuilt from the stored message. False stops keeping new ones. Originals already kept stay with their messages.
groupKeepCopyNoWhether a group address also keeps a copy of each message in its own mailbox.
tapWebhookIdsNoUp to 5 webhook endpoints that also get every message the address receives, as ids that listWebhooks gives. An empty list or null stops them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the baseline is lower; the description adds real value by explaining that a disabled address retains its settings, that re-enabling restores it, that an empty label clears it, and that keepOriginal only affects newly received mail while already-kept originals stay put. It still doesn't say whether partial updates leave unspecified fields untouched (critical with 12 optional params) or call out that expiry-driven deletion removes conversations.

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?

The core capability is stated in the very first clause and the follow-on sentences are short and information-dense. The opening sentence is a long comma-chained list that is harder to scan than a bullet-style grouping would be, but no sentence is filler.

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

Completeness5/5

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

For a 12-parameter mutation tool with no output schema and 83% schema coverage, the description covers every meaningful field family plus the state-transition edge cases (disable/re-enable, empty label, expiry revive). Combined with destructiveHint in the annotations, an agent has enough to call it correctly.

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 83%, so the baseline is 3; the description earns an extra point by grouping parameters into a mental model (label, enabled, keepOriginal, delivery destination, expiry, group posting) and connecting destination to webhookId/tapWebhookIds. One inconsistency weakens it: the description says "Up to 5 webhook endpoints" for tapWebhookIds while the schema allows maxItems 100, which could mislead an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ("Change an address on a domain") and enumerates the exact attributes that can be modified, mapping them to the schema properties (label, enabled, keepOriginal, destination/webhookId/tapWebhookIds, expiresAt/onExpiry, groupPosting/groupKeepCopy). This clearly separates it from addDomainAddress and removeDomainAddress without naming them.

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 verb "Change" plus the field enumeration makes the modify-existing-address context clear, and the note that a disabled address keeps its settings and can be re-enabled gives useful operational context. It never explicitly names a sibling (addDomainAddress, removeDomainAddress, setAddressForwardMode) or states when not to use it, so no exclusion guidance.

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.