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

The description discloses behavioral traits beyond the readOnlyHint annotation: it states the page is saved as a draft and inherits the site's brand and domain. This gives meaningful context about side effects and state. It does not contradict annotations; readOnlyHint=false aligns with the write operation. The main description adds value beyond the 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 exactly three sentences, front-loaded with the core action, then usage guidance and a practical note. Every sentence serves a purpose with no redundancy. It is appropriately sized and well-structured.

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?

Given the tool's complexity (4 params, 3 required), the schema covers essentials, and an output schema exists (though not shown). The description explains the core action, when to use it, and a key behavior (draft status). It does not cover error cases or edge scenarios, but that is not necessary given the rich schema. It is sufficiently complete for an agent to use 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?

The input schema already provides detailed descriptions for all four parameters (100% coverage), so the baseline is 3. The main description does not add new parameter-specific meaning; it merely reiterates the pointer to list_sites for siteId, which the schema already mentions. No additional semantic clarification is offered beyond the schema.

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 clearly states the tool's function: 'Generate a new page inside an existing website and save it as a draft.' It names the specific resource (page within a site) and differentiates from the sibling tool create_page by noting when this one should be used instead. The verb and object are unambiguous.

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 explicitly guides when to use this tool: 'Use this rather than create_page whenever the page belongs to a site.' It also provides a practical pointer for obtaining a required parameter: 'Find site ids with list_sites.' This offers clear context on selection and prerequisite.

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