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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false, and "One todo posts once: a retry never posts twice" largely restates idempotentHint. The genuinely additive parts are that the call posts immediately to WIP using the user's verbatim wording and that it works across offered/failed/cancelled states, but failure modes, what happens to the original text, and any permission/plan restrictions ("Pro") are left unexplained.

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?

The core purpose is front-loaded in the first sentence, which is good. However, the second and third sentences are fragmentary and grammatically loose ("Only when the user asked..."), and the dangling "Pro." is pure noise that costs a sentence with no payoff.

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 tool with full schema coverage and clear annotations, the description covers purpose, preconditions, and idempotency, which is enough to invoke it correctly. The remaining gaps (what the tool returns, what happens on a failed post, what "Pro" implies) are minor given there is no output schema to explain.

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 both id and text are already documented in the schema, giving a baseline of 3. The description adds real meaning on top: the text supplied becomes the todo "as it goes to WIP, hashtag included", and it must be the user's own words as they want them published, which constrains how to derive the value.

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?

"Change the text of an automatic WIP todo and post it now" gives a specific verb (change/edit + post) and a specific resource (an automatic WIP todo), which is distinguishable from nearby tools such as add_post or edit_step. The second sentence adds a secondary capability (posting an already offered/failed/cancelled post), but the trailing "Pro." fragment is unexplained and adds no meaning.

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 preconditions are stated: only call it when the user asked, using their words as they want them on WIP, and only post an offered/failed/cancelled item when the user says to post it. It does not name alternatives (e.g., edit_step, add_post, delete_auto_post) for an agent deciding between similar tools, which keeps it 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.