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

With no annotations, the description carries the full burden and does well: it discloses the side effect (the question surfaces on the board under 'Needs you'), that the reply comes back as a note, and the required follow-up read. It doesn't cover error cases (unknown task_id), whether blocking is reversible in-place, or whether the call returns anything, which keeps it from 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?

Actionable content is front-loaded and every sentence contributes (purpose, reason format, board behavior, follow-up tool, retry strategy). It is longer than typical but not padded; a small trim of the example or the 'meanwhile' clause would tighten it further.

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 no annotations, no output schema and no nested objects, it covers the workflow end to end: what it does, how the human responds, and how the agent should read the reply. The one gap is that with no output schema, the description never says what the call itself returns or what identifier to use as the cursor.

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 baseline is 3, but the description adds real guidance on the 'reason' parameter's content and phrasing ('one question the person can answer from the board in a line', with a worked example) that the schema's shorter hint only partially conveys. task_id is left 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?

States a specific verb and resource ('Mark a task (or step) blocked') plus the exact triggering condition ('when you can't continue without the human'). The parenthetical '(or step)' and the handoff to taskhold_updates clearly separate it from siblings like taskhold_unblock and taskhold_progress.

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?

Explicitly names when to use it (decision, missing info, access), the correct follow-up tool (taskhold_updates with your cursor), what to do while waiting (keep working on independent items), and the retry path (block again with a narrower question, don't guess). This is close to a complete routing rule.

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