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

Annotations declare a non-read-only, non-destructive, non-idempotent write. The description adds meaning beyond that: the output is an unpublished draft change set with a separate owner-publish step, and it enumerates hard validation rules (no numbers, awards, links or markup).

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 what is produced, followed by the constraint and the workflow. Every sentence earns its place.

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 no output schema, the description still conveys what is returned (a draft change set) and how it is consumed. It could more explicitly describe the return payload, but it is adequate for a four-field drafting tool.

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 0%, so the description must carry the semantics. It names and semantically explains all four required fields (tagline, about paragraph, SEO title, SEO description), though it does not restate the length limits that the schema already enforces.

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?

States a specific verb (propose/draft) and resource (public website text pack) and enumerates the four fields. It is clearly distinguishable from siblings like draft_product_description and draft_translation.

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 makes the draft-vs-publish boundary explicit: this only proposes a change set and 'the owner publishes from the admin panel.' It does not explicitly contrast itself with the other draft_* siblings, but the context is clear enough.

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