Skip to main content
Glama
nkd3v
by nkd3v

aism_migration_manifest

Read-onlyIdempotent

Reads a site's migration manifest, including UUID, URLs, versions, themes, plugins, content counts, capabilities and what is excluded from migration. Use it to verify migration scope before transferring a site.

Instructions

Read a site's migration manifest: site UUID, URLs, versions, themes, plugins, content counts per post type/taxonomy, capabilities and what is not migrated. Requires migration:read (companion 1.4.0+).

Input Schema

NameRequiredDescriptionDefault
siteNoConfigured site name from aism_sites. Omit for the default site.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds two things they cannot: the required scope 'migration:read' and the companion version constraint (1.4.0+). Missing only notes on failure modes (e.g., unconfigured site) or whether it hits the remote site (relevant given openWorldHint=true).

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?

One dense sentence that front-loads the action and the return payload, followed by a compact requirements clause. No filler, no restatement of the tool name.

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

Completeness4/5

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

With no output schema, the description usefully enumerates the manifest's fields so an agent knows what it gets back. Requirements (scope, companion version) are also covered. Slightly incomplete in that ordering/relationship to plan/export/run steps is left implicit.

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 coverage is 100% and the single optional 'site' parameter is fully documented in the schema, including a reference to aism_sites and the default behavior when omitted. The description adds nothing parameter-specific, which is fine at this coverage level.

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?

Specific verb + resource: 'Read a site's migration manifest', then enumerates exactly what the manifest contains (site UUID, URLs, versions, themes, plugins, content counts, capabilities, exclusions). This clearly distinguishes it from plan/status/export siblings by content. It stops short of naming a sibling explicitly, so a 4 rather than 5.

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 description implies this is the inspection/introspection step of the migration workflow, but never says when to call it versus aism_migration_status or aism_migration_plan, nor any prerequisite ordering (e.g., run manifest before plan). Usage is inferable but not stated.

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