Skip to main content
Glama

migrate_import_mail_domain

Import a mail domain migration bundle to recreate domain, mailboxes, aliases, and forwards on the destination ISPConfig server. Maildir needs separate rsync; reset redacted passwords.

Instructions

Import a mail domain migration bundle into the destination ISPConfig instance. Creates domain, mailboxes, aliases, and forwards. NOTE: maildir data must be rsynced separately; redacted passwords must be reset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bundle_jsonYesThe migration bundle JSON (from migrate_export_mail_domain)
dest_client_idNoTarget client ID (0 for admin)
dest_server_idYesTarget server ID on the destination instance

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose side effects. It does state that the tool creates domain, mailboxes, aliases, and forwards, and calls out key caveats. However, it does not disclose conflict behavior, idempotency, or what happens if the domain already exists on the destination—important for an import operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it opens with the action and resource, then states the created entities, then provides two essential caveats. Every sentence contributes value without redundancy.

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 three parameters and good schema coverage, the description covers the core behavior and important follow-up steps. However, there is no output schema and no annotation coverage, and the description leaves out execution expectations such as whether the import can partially fail or whether it overwrites existing data.

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?

The input schema already documents all three parameters with meaningful descriptions (100% coverage), so the description need not repeat them. The description adds no parameter-level detail beyond what the schema provides, making the baseline score appropriate.

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?

States a specific verb and resource: "Import a mail domain migration bundle into the destination ISPConfig instance." It also enumerates what the import creates (domain, mailboxes, aliases, forwards), making it clearly distinguishable from sibling import/export tools.

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?

Clearly conveys the intended scenario: importing a mail domain migration bundle. It adds practical caveats (rsync maildir separately, reset redacted passwords), but does not explicitly contrast with alternatives like mail_domain_add or import_web_domain.

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