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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the constraint that it fails if the owner already has a site, and clarifies that it does not publish. It does not describe authentication needs, side effects, response behavior, or rate limits beyond what annotations provide, so the added context is useful but moderate.

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 short sentences, front-loaded with the primary action and immediately followed by critical constraints. Every sentence earns its place, and there is no wasted wording.

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 tool is complex: it takes a deeply nested document object and has no output schema. The description covers the core action, non-publishing behavior, and the owner-existence failure condition. However, it does not address what the document must contain, what success returns, or how to handle the idempotency key beyond the schema's own description. It is adequate but leaves clear gaps for such a complex mutation.

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 50%: idempotencyKey is documented in the schema, but the large nested 'document' parameter has no description. The description says 'structured draft' but does not explain the document structure, required fields, or how to populate it. It does not compensate for the uncovered core parameter.

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: 'Create one structured draft.' It also distinguishes the tool from publishing via 'Does not publish' and adds an important constraint: 'Fails if the owner already has a site.' However, it does not explicitly name a sibling like save_site as the alternative for updating, so it does not reach full sibling differentiation.

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 implies when to use the tool by stating it creates a draft and does not publish. The failure condition ('Fails if the owner already has a site') adds useful context. But it does not explicitly say when to use create_site versus save_site or publish_site, nor does it name alternatives, leaving some usage inference to the agent.

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