Property Migration Checklist

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it does not meet it. It does not say whether the checklist is a report/analysis (likely read-only) or mutating, what the checklist covers, whether it requires the old site to be pre-configured, or what the output structure implies. For a tool that presumably synthesizes migration steps, this is a significant transparency gap.

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 efficient sentence that is front-loaded with the action and purpose, with zero filler words. It earns the fourth point for being genuinely concise and direct; it misses the fifth only because the brevity comes at the cost of substance - the sentence is short but does not carry enough information to be maximally useful.

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?

The presence of an output schema means return values are documented elsewhere, which relieves the description of that duty. However, with no annotations and 4 required parameters, the description should clarify the checklist's scope and how it is produced. It does not explain what the checklist is derived from or what an agent should do with it, leaving the tool's overall role underspecified for a moderate-complexity tool.

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 only 50% - old_site_url and new_site_url have descriptions, but start_date and end_date are undocumented in the schema. The description adds nothing about any parameter; it does not clarify what the date range represents (likely the migration window) or the expected date format. With half the parameters undocumented and the description silent, the gap is not compensated.

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 (generate), resource (migration checklist), and context ('when moving a site'). It is clearly distinct from siblings, which are all site-health, analytics, or sitemap tools with no migration focus. It loses the fifth point because 'migration checklist' itself is underspecified - it doesn't say what the checklist contains or what migration domain it covers (e.g., URLs, redirects, tracking).

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?

Provides a clear usage condition ('when moving a site') that tells the agent the general trigger. However, it names no alternatives and gives no exclusions - an agent might wonder whether analyze_site_health or get_site_details should be run first, or whether this checklist depends on other tools having been called. The 'when' is stated but the 'how it fits with siblings' is left to inference.

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