Skip to main content
Glama

nitro_manage_domains

Destructive

Manage the brand’s Nitrosend sender and custom sending domains. Receiving MX requires forward-all.

Input Schema

NameRequiredDescriptionDefault
paramsNoOperation-specific parameters.
confirmNoRequired for removal, renaming and subdomain-sharing changes.
operationYesPrepare/select a hosted sender or manage customer domains. Rename keeps old addresses receiving. Show a paired removal's effect before unpair.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / operation / enum
      Previous value: -[
      -  "prepare_brand_subdomain",
      -  "select_brand_subdomain",
      -  "rename_brand_subdomain",
      -  "add",
      -  "verify",
      -  "check_dns",
      -  "list",
      -  "remove",
      -  "list_shared_subdomains",
      -  "share_subdomain",
      -  "revoke_shared_subdomain"
      -]New value: +[
      +  "prepare_brand_subdomain",
      +  "select_brand_subdomain",
      +  "rename_brand_subdomain",
      +  "add",
      +  "verify",
      +  "list",
      +  "remove",
      +  "list_shared_subdomains",
      +  "share_subdomain",
      +  "revoke_shared_subdomain"
      +]
    • changedInput schema / properties / params / properties / domain_name / description
      Previous value: -"Customer sending domain for add, verify, check_dns, or remove."New value: +"Customer sending domain for add, verify, or remove."
  2. Changed6 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Required for remove and rename_brand_subdomain."New value: +"Required for removal, renaming and subdomain-sharing changes."
    • changedInput schema / properties / operation / enum
      Previous value: -[
      -  "prepare_brand_subdomain",
      -  "select_brand_subdomain",
      -  "rename_brand_subdomain",
      -  "add",
      -  "verify",
      -  "check_dns",
      -  "list",
      -  "remove"
      -]New value: +[
      +  "prepare_brand_subdomain",
      +  "select_brand_subdomain",
      +  "rename_brand_subdomain",
      +  "add",
      +  "verify",
      +  "check_dns",
      +  "list",
      +  "remove",
      +  "list_shared_subdomains",
      +  "share_subdomain",
      +  "revoke_shared_subdomain"
      +]
    • addedInput schema / properties / params / properties / domain_id
      Added value: +{
      +  "description": "The current brand's domain that owns the subdomain.",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / params / properties / page
      Added value: +{
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / params / properties / shared_domain_id
      Added value: +{
      +  "description": "Shared sending-domain claim to revoke.",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / params / properties / target_brand_sid
      Added value: +{
      +  "description": "Exact destination brand; must be in this account or an eligible managed client.",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / operation / description
      Previous value: -"prepare_brand_subdomain reserves params.subdomain (or company name) and prepares sending; idempotent.\nselect_brand_subdomain selects it; local_part and apex are optional.\nrename_brand_subdomain needs subdomain, expected_fqdn and confirm; old addresses keep receiving.\nadd returns DNS records. verify checks readiness. check_dns diagnoses DNS/HTTPS. list returns setup and allowances.\nremove needs domain_name and confirm; paired removal needs unpair after showing its effect."New value: +"Prepare/select a hosted sender or manage customer domains.\nRename keeps old addresses receiving. Show a paired removal's effect before unpair."
  4. Changed1 schema field changed
    • changedInput schema / properties / operation / description
      Previous value: -"prepare_brand_subdomain reserves params.subdomain (or a Brand Kit-derived name), then the sender; idempotent.\nselect_brand_subdomain selects a ready sender with optional local_part and apex.\nrename_brand_subdomain changes params.subdomain with params.expected_fqdn and confirm. Old addresses keep receiving.\nadd registers a customer domain and returns required DNS records.\nverify checks provider and DNS readiness. check_dns diagnoses DNS and tracking HTTPS only.\nlist returns domains, readiness, records, DMARC, and allowance use.\nremove requires domain_name and confirm; retry paired removal with unpair after showing its effect."New value: +"prepare_brand_subdomain reserves params.subdomain (or company name) and prepares sending; idempotent.\nselect_brand_subdomain selects it; local_part and apex are optional.\nrename_brand_subdomain needs subdomain, expected_fqdn and confirm; old addresses keep receiving.\nadd returns DNS records. verify checks readiness. check_dns diagnoses DNS/HTTPS. list returns setup and allowances.\nremove needs domain_name and confirm; paired removal needs unpair after showing its effect."
  5. Changed4 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Required for remove."New value: +"Required for remove and rename_brand_subdomain."
    • changedInput schema / properties / operation / description
      Previous value: -"prepare_brand_subdomain reserves params.subdomain (or a Brand Kit-derived name), then the sender; idempotent.\nselect_brand_subdomain selects a ready sender with optional local_part and apex.\nadd registers a customer domain and returns required DNS records.\nverify checks provider and DNS readiness. check_dns diagnoses DNS and tracking HTTPS only.\nlist returns domains, readiness, records, DMARC, and allowance use.\nremove requires domain_name and confirm; retry paired removal with unpair after showing its effect."New value: +"prepare_brand_subdomain reserves params.subdomain (or a Brand Kit-derived name), then the sender; idempotent.\nselect_brand_subdomain selects a ready sender with optional local_part and apex.\nrename_brand_subdomain changes params.subdomain with params.expected_fqdn and confirm. Old addresses keep receiving.\nadd registers a customer domain and returns required DNS records.\nverify checks provider and DNS readiness. check_dns diagnoses DNS and tracking HTTPS only.\nlist returns domains, readiness, records, DMARC, and allowance use.\nremove requires domain_name and confirm; retry paired removal with unpair after showing its effect."
    • changedInput schema / properties / operation / enum
      Previous value: -[
      -  "prepare_brand_subdomain",
      -  "select_brand_subdomain",
      -  "add",
      -  "verify",
      -  "check_dns",
      -  "list",
      -  "remove"
      -]New value: +[
      +  "prepare_brand_subdomain",
      +  "select_brand_subdomain",
      +  "rename_brand_subdomain",
      +  "add",
      +  "verify",
      +  "check_dns",
      +  "list",
      +  "remove"
      +]
    • addedInput schema / properties / params / properties / expected_fqdn
      Added value: +{
      +  "description": "Current brand_subdomain.fqdn, required for rename_brand_subdomain.",
      +  "type": "string"
      +}
  6. Changed5 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Required for remove operation (destructive)"New value: +"Required for remove."
    • changedInput schema / properties / operation / description
      Previous value: -"prepare_brand_subdomain reserves the subdomain if missing, then the sender; idempotent.\nselect_brand_subdomain selects a ready sender with optional local_part and apex.\nadd registers a customer domain and returns required DNS records.\nverify checks provider and DNS readiness. check_dns diagnoses DNS and tracking HTTPS only.\nlist returns domains, readiness, records, DMARC, and allowance use.\nremove requires domain_name and confirm; retry paired removal with unpair after showing its effect."New value: +"prepare_brand_subdomain reserves params.subdomain (or a Brand Kit-derived name), then the sender; idempotent.\nselect_brand_subdomain selects a ready sender with optional local_part and apex.\nadd registers a customer domain and returns required DNS records.\nverify checks provider and DNS readiness. check_dns diagnoses DNS and tracking HTTPS only.\nlist returns domains, readiness, records, DMARC, and allowance use.\nremove requires domain_name and confirm; retry paired removal with unpair after showing its effect."
    • changedInput schema / properties / params / properties / apex / description
      Previous value: -"Optional active Nitrosend sending apex."New value: +"Optional sending apex."
    • changedInput schema / properties / params / properties / local_part / description
      Previous value: -"Optional brand-subdomain From local part."New value: +"Optional From local part."
    • addedInput schema / properties / params / properties / subdomain
      Added value: +{
      +  "description": "Sender name; needs no Brand Kit.",
      +  "type": "string"
      +}
  7. First observed

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already disclose destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the risk profile is covered structurally. The description adds the forward-all MX prerequisite, which is real behavioral context, but says nothing about which of the ten operations are destructive, whether removal is reversible, or that confirm gates removals/renames — that appears only in the schema.

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?

Two sentences, zero filler, with the resource scope front-loaded ahead of the prerequisite note. It is efficient, though the brevity is partly under-specification rather than pure conciseness.

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 ten-operation, destructive, nested-parameter tool with no output schema, the description is too thin: it never explains the prepare→select→verify lifecycle, which operations mutate vs read, or what a caller gets back. The schema fills much of the gap, but an agent cannot infer sequencing or consequences from the description alone.

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 every parameter including the operation enum is documented at the field level. The description adds no parameter meaning beyond that, which is the expected baseline when the schema carries the full load.

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 resource (Nitrosend sender and custom sending domains) and a management verb, and no sibling tool overlaps this space. However, 'Manage' spans ten quite different operations (prepare/select/rename/add/verify/list/remove/share/revoke), so the agent only learns the broad domain of the tool, not the concrete actions, from the prose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The one operational rule given — that receiving MX requires forward-all — is genuinely useful framing for choosing this tool. But there is no explicit when-to-use/when-not guidance and no routing to alternatives or prerequisites for the mutating operations; most such guidance lives in the operation enum description inside the schema rather than the tool description.

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.

Resources