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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=true), so the description's job is to add context, which it does: it discloses an ownership/permission constraint ('YOUR Forum post') and the reversibility of the mark. It does not say what happens to a previously accepted reply or what occurs if the caller doesn't own the post.

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?

A single front-loaded sentence with the core action first and the toggle semantics in a compact parenthetical; nothing is wasted and no information is buried.

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 two-parameter mutation with annotations already declaring safety and idempotency, the description supplies the essential ownership constraint and undo semantics. Gaps remain around reply_id sourcing and whether accepting one reply unseats another, but these are minor for a tool of this complexity.

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 parameter burden. It explains the `accepted` flag well (false removes the mark), but the required `reply_id` is never characterized — no format, no indication of how to obtain one, no error behavior for an invalid id.

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 (mark) and resource (a reply on your Forum post) plus the resulting state (accepted answer), and the parenthetical 'accepted=false removes the mark' pins down the inverse operation. Among the agora_* siblings (post, reply, vote, read) this is unambiguously the accept-answer action, and the 'YOUR' qualifier scopes it to posts the caller owns.

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?

The description makes clear when to invoke it (to designate the accepted answer on your own forum post) and encodes the un-mark case via accepted=false. It does not name a competing tool or state explicit exclusions/failure conditions, so it stops short of the 5 bar.

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