Migrate Taxonomy

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

No annotations are provided, so the description carries the full behavioral burden. 'Migrate' implies a write/mutation operation, but the description never says whether it creates new vocabularies or overwrites existing ones, whether it is idempotent or reversible, or what permissions/credentials it needs. Only the bare verb is disclosed.

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

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

A single front-loaded sentence with zero filler; the purpose is stated first and nothing is padded. It is efficient, though its brevity is under-specification rather than genuine completeness.

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

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

An output schema exists, so return values need not be described, but that is the only load-bearing coverage. For a mutation-style migration tool with no annotations, no parameter documentation, and unclear lifecycle position among five migration siblings, the description is too thin to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for all three parameters, and the description adds nothing about them. In particular the required 'vocabularies' array of opaque objects (additionalProperties: true) has an entirely undefined shape, and include_terms and source_jsonapi are unexplained — the description must compensate here and does not.

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

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

States a specific verb ('Migrate') and resource ('taxonomy vocabularies and their terms'), which is narrower than the generic migration siblings like generate_migration_yaml or rollback_migration. However, it offers no differentiation from those tools — e.g., whether it wraps generate_migration_yaml or runs the migration itself — so an agent cannot confidently place it in the migration workflow.

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

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

There is no when-to-use guidance, no prerequisites, no mention of source system (the source_jsonapi parameter hints at a JSON:API origin but the description never says so), and no exclusions relative to run_migration_test, validate_migration, or rollback_migration. The agent is left to infer the place in the migration lifecycle entirely.

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