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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is pre-cleared; the description still adds real behavior: native products are excluded, the payload includes current revision and source observation, saved-plan bindings are returned conditionally, and legacy null/empty evidence never counts as approval. Those edge-case rules are valuable and not derivable from structured fields.

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?

Purpose is front-loaded in the first clause and no sentence is pure filler, but the prose is dense and telegraphic ('No costs or mutation.', 'Legacy null/empty evidence never establishes approval.'), with the approval and plan-binding caveats stacked in a way that is hard to parse on first read. The final workflow sentence arguably belongs to a different tool.

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 an output schema present, return-value detail is rightly omitted, and the description compensates by covering exclusions, scope of the payload, conditional plan bindings, and the approval-evidence caveat. Only the routing versus sibling read tools is left unaddressed, a minor gap for a single-object getter.

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 100%, so the baseline would be 3, but the description adds a genuinely useful clarification that proposal_id is 'the Webanto product id' — resolving the naming mismatch between a 'proposal' parameter and a product identifier. It says nothing about the optional 'representation' parameter, but that is fully documented in the schema.

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 and resource: 'Inspect one enriched connected product's proposed description and SEO changes by proposal_id'. The singular 'one ... product' and the note that 'native products are excluded' implicitly separate it from the sibling webanto_list_copy_proposals, though no sibling is named outright.

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?

Usage is implied by the object-scoped phrasing, and it does say to 'Prepare a publication plan and review it in Webanto before execution', which is downstream guidance rather than a when-to-use rule. It never explicitly contrasts itself with list_copy_proposals or any other retrieval tool, so the agent must infer selection from the singular/plural naming.

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