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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds real behavioral context beyond that: what accept actually triggers (a post idea starts generating, a connection card returns a sendable link) and a safety precondition requiring user confirmation for send/publish actions. It doesn't state whether accept can be undone once generation starts, so not a 5.

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 compact sentences, front-loaded with the core action and scope, then effect detail, then the conditional parameter note, then the safety rule. Every sentence carries useful information but the 'does what the card's button does' framing is slightly indirect for an agent with no card context.

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?

No output schema exists, but the description describes the observable outcome of accept (generation starts, link returned) and the confirmation precondition. With annotations covering the non-destructive, non-idempotent mutation profile and full schema coverage, only minor gaps remain (e.g., what dismiss does to the item, whether accept is reversible).

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 100%, so the schema already explains itemId (from list_todo), the action enum, and finalText. The description's mention of finalText and list_todo largely restates the schema rather than adding syntax, format, or edge-case detail. Baseline 3 applies.

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 pair (accept/dismiss) and resource (one todo item), scoped to a single item by id, and names list_todo as the source of that id. An agent can distinguish this from sibling mutation tools like publish_post or boost_post without opening another schema.

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?

Gives clear conditions: accept vs dismiss semantics, and pass finalText when the user edited the draft first. It also states a strong operating rule ('always confirm with the user before accepting anything that sends or publishes'). It stops short of naming alternative tools for related workflows, so it lands at 4 rather than 5.

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