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

Annotations only say destructiveHint=true and openWorldHint=false; the description adds far more: destination replacement happens only under an explicit replaceDestination:true, otherwise it refuses, and field names, styles and anchors of the group are preserved. It also discloses that expectedVersion is mandatory and that mode 'auto' applies live if published while 'draft' keeps a draft — genuine behavioral context beyond the annotations.

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?

Every clause carries real information, but it is delivered as a single dense paragraph chained with colons and semicolons, mixing purpose, preconditions, refusals and parameter semantics. There is no front-loading or grouping, which makes the guidance hard to scan on first read.

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, no-output-schema mutation with 7 undocumented parameters, the description covers what is preserved, what is refused, what requires explicit consent, and how draft vs live behaves. It stops short of describing error/conflict behavior on expectedVersion mismatch or what the tool returns, which would fully close the loop.

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 must carry the load, and it does for most parameters: mode semantics (auto vs draft), expectedVersion as a mandatory concurrency token, replaceDestination as explicit consent, submitBlockId as an existing native button in the same section, and fieldsBlockId as the local fields group. pageId is never explained, and the refusal cases imply constraints on submitBlockId that are only loosely stated.

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 concrete verb and resource: converting a local 'fields' group into a native form that stores responses in the project, and explicitly differentiates it from CRM-contact or subscription-based form paths. The differentiation is buried mid-sentence in a run-on paragraph, so the agent must parse to extract it, which keeps it just below a top score.

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?

Gives explicit trigger conditions ('sur demande explicite de collecte' or to deliver a site/clone when check_site_completeness reports 'form-not-connected') and refusal conditions (destinations without consent, complex effects, button anchors, initial/read-only values, missing measurements). It does not name a fallback sibling to use when the tool refuses, which is the only real gap.

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