AI Site Manager MCP

Overview Schema Source Related Servers Discussions Admin

aism_migration_run

Destructive

Migrates a whole WordPress site between configured sites in resumable steps: users, terms, settings, media, content, comments, then finalizes ID remapping and source URL rewrites.

Instructions

Migrate a whole site in resumable steps: terms, site settings (front page, permalinks, media sizes, widgets, customizer), media (original files), all content types including menus, templates, global styles and patterns, comments, then a finalize pass that remaps IDs and rewrites source URLs to the target. User accounts come first, with their roles, profile and password hashes so people keep their passwords (needs users:read on the source key and users:write on the target key, companion 1.7.0+; otherwise authors are only matched by login/email). Target accounts with the same login or email are mapped, never changed. Returns within max_seconds; call again with the returned cursor until done is true. Re-running updates already migrated objects instead of duplicating them, so it also works as an incremental sync (with modified_after). Overwrites target settings and previously migrated objects, including passwords of accounts an earlier run created (use phases or on_existing=skip to avoid that).

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": {
      "source": "<source>",
      "target": "<target>"
    },
    "name": "aism_migration_run"
  }
}

Input Schema

Name	Required	Description	Default
`cursor`	No	cursor from the previous call; omit to start.
`phases`	No	Subset of phases (finalize always runs). Default: all.
`source`	Yes	Configured site name to migrate FROM (needs migration:read).
`status`	No	preserve keeps source publication status; draft imports publicly viewable content as drafts (patterns, menus and templates stay usable).	preserve
`target`	Yes	Configured site name to migrate INTO (needs migration:read and migration:write).
`author_map`	No	Source author login → target user login. Unmapped authors match by login, then email, then default_author.
`post_types`	No	Only these post types (include attachment for media). Default: all.
`match_slugs`	No	Adopt existing target posts with the same type and slug instead of creating duplicates. Terms and templates always match by slug.
`max_seconds`	No	Time budget for this call.
`on_existing`	No	For objects already migrated earlier: update them from the source, or leave them.	update
`exclude_users`	No	Source account logins not to copy (case-insensitive). Content they wrote is still matched by login/email or given to default_author.
`default_author`	No	Target login used when no author matches. Defaults to the target key owner.
`modified_after`	No	ISO date: only posts, media and comments changed after it (incremental sync).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.7.0Oct 31, 2026

addedInput schema / properties / exclude_users

Added value: +{
+  "description": "Source account logins not to copy (case-insensitive). Content they wrote is still matched by login/email or given to default_author.",
+  "items": {
+    "maxLength": 60,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "type": "array"
+}

changedInput schema / properties / phases / items / enum

Previous value: -[
-  "terms",
-  "media",
-  "content",
-  "comments",
-  "site",
-  "finalize"
-]New value: +[
+  "users",
+  "terms",
+  "site",
+  "media",
+  "content",
+  "comments",
+  "finalize"
+]

Addedv1.4.1Oct 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (destructive, openWorld, non-idempotent), it discloses what gets destroyed ('Overwrites target settings and previously migrated objects, including passwords'), the required key scopes (users:read on source, users:write on target), a companion 1.7.0+ dependency, and the safety rule that matching target accounts are mapped but never changed. This is exactly the kind of context annotations cannot carry.

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?

Front-loaded with the core action and phase list in the first sentence, then consequences and paging. Dense but each sentence mostly earns its place; the parenthetical permission notes make some sentences long, slightly hurting scannability.

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 13-parameter destructive migration with no output schema, it covers the essentials an agent needs: pagination/cursor termination, idempotent-like upsert behavior, overwrite risk, permission prerequisites, version dependency, and author-mapping fallback order. Little an agent would need to call this correctly is missing.

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 100%, so the baseline is 3; the description still adds value by explaining cross-parameter behavior — cursor paging, modified_after driving incremental sync, phases/on_existing as the lever to avoid password overwrite, and author matching order. It does not re-describe every parameter, but the narrative meaning is richer than the schema alone.

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 ('Migrate a whole site') and immediately enumerates the scope phases: terms, site settings, media, content, comments, finalize remap. This clearly distinguishes it from sibling tools like aism_migration_copy, aism_migration_export, and aism_migration_manifest, which do not do a full site run.

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?

Gives concrete operational guidance: 'Returns within max_seconds; call again with the returned cursor until done is true', and explains re-running acts as an incremental sync via modified_after. It also advises using phases or on_existing=skip to avoid overwriting passwords. It stops short of explicitly naming when to pick a sibling such as aism_migration_copy or aism_migration_plan instead.

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