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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's added value is the disclosure of what comes back: section names, opening texts and image counts. Since there is no output schema, that return-shape disclosure is genuinely useful; it stops short of noting whether the 'first texts' are truncated or how many sections are returned.

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?

Two compact statements — what the listing contains and which sibling to use for each follow-up action — with no wasted wording. The parenthetical enumeration is dense but earns its place by describing the payload.

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 one-parameter read tool with no output schema, the definition covers the essentials: the resource, the fields returned, and the two sibling tools that complete the workflow. Only minor gaps remain, such as the expected size/truncation of returned text and any pagination behavior.

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% and the single templateId parameter is undocumented, so the description must compensate. It implies the ID refers to a template in the library ('modèle de la bibliothèque') and points at preview_site_templates, which gives partial meaning, but it never says where templateId is obtained or its format.

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 names the specific resource (content sections of a library template) and even enumerates what each section carries (name, first texts, image count), which lets an agent distinguish it from copy_template_section or preview_site_templates. It is a noun phrase rather than an explicit verb+resource statement, so it falls just short of a 5.

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 states the downstream purpose clearly: pick a section here in order to copy it into a page with copy_template_section, and it routes to preview_site_templates to inspect the template itself. Alternatives are named, though no explicit exclusion or precondition (e.g. that the templateId must be a library template) is stated.

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