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

Annotations already establish non-read-only, non-destructive, non-idempotent, so the bar is lower, and the description still adds real value: the naming convention ('Copy of ...'), the '-copy' slug with numeric suffixes, and the home-page special case. The suffix numbering also implicitly communicates that repeated calls accumulate new pages, consistent with idempotentHint=false. It stops short of stating the copy's publish/draft state or required permissions.

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?

Three tight sentences, front-loaded with the action and scope, then the naming behavior, then the single special case. No sentence is filler or redundant with the schema.

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?

With only two required params, an output schema present, and annotations covering the safety profile, the description covers the genuinely non-obvious behavior (naming, slug collision, home page). The remaining modest gap is whether the duplicate is created published or as a draft, which an agent would likely need post-call.

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?

Both parameters are fully documented in the schema (100% coverage), including that event_id comes from search_events, so the description need not repeat them. It adds no additional constraint on page_id or event_id, which is acceptable given the baseline for complete schema coverage.

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?

Names a specific verb and resource ('Duplicate a page') and immediately scopes it with what gets copied ('all its sections and blocks'). An agent can distinguish this from create_site_page or update_site_page from the description alone, since duplication semantics are stated explicitly.

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?

Usage is implied by the verb rather than stated: nothing says when to duplicate versus creating a blank page with create_site_page, nor any prerequisites (e.g., does the source page need to be published?). The home-page edge case is helpful but is behavioral guidance, not selection guidance.

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