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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context the annotations cannot: execution is asynchronous and returns an import to poll via get_website_clone, requestId is idempotent so a repeat does not relaunch the import, nothing is published, and site mode is capped at 50 pages in the same folder. It also discloses the pageId+expectedVersion replacement path, which is the concrete destructive action. Minor tension: it fetches arbitrary external URLs while openWorldHint=false, which suggests a closed-world profile for an operation that clearly reaches the open web.

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 action is front-loaded and the content is dense rather than padded. The enumeration of captured elements (sliders, tabs, accordions, popups, form fields) runs long, and some sentences chain several clauses with dashes and semicolons, hurting scannability. Nothing is redundant, but tighter grouping of the mode rules would help.

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?

For a complex async mutation with no output schema and six parameters, the description covers prerequisites (empty project), follow-up (get_website_clone), idempotency, publication state, and limits. An agent has everything needed to decide, invoke, and continue 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 coverage is only 33%, so the description must carry the load and does: it defines the semantics of mode=site vs mode=page, the pageId/expectedVersion pairing for replacing a draft, and the idempotency contract of requestId beyond its regex pattern. Combined with the schema's own comments on name and pageId, essentially every non-trivial parameter has stated meaning.

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 opens with a specific verb + resource in caps ('CLONER UN SITE OU UNE PAGE DEPUIS SON URL') and immediately scopes the mechanism: server-side capture, no client browser. It explicitly separates the two behaviors (mode=site follows internal links, mode=page imports one page) and names the siblings it is not (clone_page_in_outil, manual reconstruction from screenshots). An agent can pick this over create_website_from_template or import_html_page without opening any schema.

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?

Explicit when/when-not: mode=site requires a project with no pages, so call create_project first unless the user asked to add pages to the current site (then mode=page). It names a better alternative when available (clone_page_in_outil, because it bypasses HTTP 403 anti-bot protections) and warns not to pre-create an empty page. It also closes the loop with 'prefer this over manual reconstruction from screenshots or text'.

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