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

Annotations already flag destructiveHint=true and non-idempotent, but the description adds real behavioral substance beyond them: the helper drops the website's caches so the change is live immediately, the effect can fan out to all CNAME children, and the operation is blocked on suspended websites. It does not cover reversibility, permissions/auth requirements, or whether an existing published template is overwritten.

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 key action and its immediate consequence are front-loaded, and the following sentences each add a distinct constraint (site type, suspension refusal, identifier choice, template source). Minor waste comes from internal code-path references such as "routes/seliee_websites.py rp_templates_create" and "helper/helper_website_state.py", which add length without helping an agent decide or invoke.

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 destructive, open-world mutation with six undocumented parameters and no output schema, the description supplies enough to call it correctly: identifiers, the CNAME/ZONE branching, the suspension precondition, and the two template-source modes. Remaining omissions are the return value/shape and confirmation of what happens to a previously published template.

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 description coverage is 0%, so the description carries the full burden and mostly does: it explains website_id vs website_uuid as alternative site identifiers, all_cname as the ZONE-child propagation switch, seliee_template_id/uuid as a copy source, and seliee_websites_templates as an explicit map. The gap is that all six parameters are optional in the schema, yet the description never states which combinations are actually required (one site identifier plus one template source).

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 pair ("Create and publish a template on a website") and immediately clarifies the distinguishing behavior — the template is applied and the live site serves it at once. It is clearly a publish-and-apply operation rather than a plain template creation, which separates it from siblings like create_template or create_website_templates, though those siblings are never named 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?

It gives concrete applicability conditions: works on a CNAME website, and on a ZONE website only with `all_cname=True` to propagate to every CNAME child, and is refused while the website is SUSPENDED. What's missing is explicit routing against alternatives (e.g., create_website_templates vs create_publish_website_rules vs create_wp_template) when an agent is deciding whether to publish or merely create.

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