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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered. The description does add real behavioral context beyond them: it names the remote service the logic runs on, and describes the response shape including per-change explanations and hard-stop words where no rewrite is offered. It omits whether anything is persisted or posted on the caller's behalf, though the read-only annotation and "to copy" phrasing together imply not.

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?

Three sentences in a sensible order: trigger, parameter notes, return shape. Every sentence carries information and the trigger is front-loaded. The return sentence is long and parenthesis-heavy, and the field labels ("text:", "group:") run into prose rather than being visually separated, which costs a little readability.

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 no output schema, the description carries the burden of explaining returns and does so thoroughly: rewritten text, the change log with reasons, and the failure mode where words block the post entirely. Both parameters are accounted for, including the optional-group default. Nothing an agent needs in order to call this correctly and interpret the result appears to be 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 100% and the group enum is already fully documented with human-readable slugs, so the schema does most of the work. The description still adds meaning the schema lacks: that omitting `group` fixes the listing for every group at once, which is a non-obvious default an agent needs. `text` is merely restated as "the listing as written."

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 states a recognizable action (rewriting a listing so it passes Moda's filter) and situates it as "the Post Checker's Fix my post, run on Moda's servers." The verb is somewhat buried behind the trigger clause in the first sentence, but the return-value sentence ("the rewritten listing to copy") makes the operation concrete. Sibling differentiation is only implicit – check_listing_words is the obvious counterpart and is never named.

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?

Explicit trigger conditions are given: words the automatic filter declines, or a user asking Moda to fix their post. That is a clear activation context rather than vague implied usage. It stops short of naming an alternative (e.g. check_listing_words for diagnosing only) or stating when not to use it, so it falls short of a 5.

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