Import WordPress website

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds meaningful behavioral context: automatic extraction, asynchronous availability, internal upload credential generation, and automatic username resolution. It does not specify what existing files or database content may be overwritten, which is a minor gap given the destructive annotation.

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?

The description is appropriately sized and front-loaded with the main purpose. The timing note and the warning against separate upload flows earn their place, though the phrasing 'files are being extracted' is slightly awkward and the timing information could be tightened.

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 description covers inputs, process, timing, and the key operational warning about not calling a separate upload endpoint, which is sufficient for an agent to invoke the tool correctly. It does not describe return values or status handling, and no output schema exists, but for moderate complexity with well-documented parameters the coverage is strong enough.

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 100%, and the schema already documents the domain, archive path, supported formats, database dump, and the directory-to-archive naming pattern. The description mostly restates or summarizes what the schema provides, so it does not add significant new parameter semantics beyond the baseline.

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?

The description states a specific verb and resource: 'Import a WordPress website from an archive file to a hosting server' by uploading an archive and database dump. It clearly distinguishes the end-to-end behavior from separately calling an upload-url endpoint, and explains that the username is resolved automatically from the domain.

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?

The description gives clear usage context and an explicit exclusion: 'do not call a separate upload-url endpoint or upload the files yourself, this tool does it end-to-end.' It does not name sibling alternatives such as hosting_deployStaticSiteArchiveV1 or agency-hosting_importWebsiteFromArchiveV1, so it falls short of full alternative routing, but the guidance is concrete and actionable.

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