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

Annotations mark this as a non-readonly, non-destructive, non-idempotent write, and the description supplies the context they cannot: it stores only a temporary private preview that expires after 30 minutes rather than publishing. It also discloses the refusal boundary (no personal data, logs, health readings, or secret values) and states precisely what is returned — the exact action and public text.

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?

Front-loaded with the trigger condition and the core action, and nearly every clause carries operational information (routing rule, data prohibitions, expiry, approval gate). It is a dense single block with some run-on sentences, but there is very little that could be cut without losing a constraint.

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 12-parameter write tool with no output schema, the description covers preconditions, sibling routing, field sourcing, prohibited content, return value, lifetime, and the mandatory human-approval handoff. Nothing an agent needs in order to call this correctly and safely is missing.

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 83%, so the baseline is 3, but the description earns more by explaining the enum semantics that the schema only lists: comment covers praise/bug/friction, feature_request is something the mod cannot do yet, reply targets any entry via parentId, and support upvotes a featureRequest parentId with an optional reply. It also constrains text to the owner's own words and confirmed context fields (tried, expected, actual, modelId, firmware, modVersion, platform), though it leaves deviceId's role mostly to 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?

The first sentence names a specific verb and resource — prepare a private preview of a public post on a mod's co.build page — and explicitly separates it from publishing with "This does not publish." The four-way kind taxonomy further pins down what is being prepared, which is exactly the distinction an agent needs against the publish_feedback sibling.

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 a hard precondition (owner has actually used the mod and agreed to leave feedback) and a conditional routing rule: before a feature request, read get_feedback with featureRequests: true and switch to support if a duplicate exists. It also names the required downstream step — show the action and public text and get explicit approval before publish_feedback.

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