todo_block

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

Annotations already disclose the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description's job is to add what they cannot. It does exactly that by disclosing that cycles are rejected — a concrete failure mode an agent must anticipate before calling. It stops short of saying what happens on a duplicate blocker, whether cross-project blockers are permitted, or whether any permission is required.

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?

Two sentences, no filler, and the operative definition of the argument roles is front-loaded ahead of the constraint. Every clause earns its place.

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 an output schema present, return values need no explanation, and the annotations carry the mutation/idempotency profile. The description covers purpose, edge direction, and the cycle-rejection failure mode, which is enough to call it correctly; it is only slightly thin on the duplicate-edge and unblock-counterpart cases.

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 only 33%, with todo_id and blocker_id documented as bare positive integers, so the description must carry their meaning — and it does, by defining the direction of the edge (todo_id waits on blocker_id), which is the single most important semantic here and is not derivable from the schema. project_id is richly documented in the schema itself, so it needs no help from the description; the remaining gap is minor.

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 precise verb-plus-resource ('add a blocker') and defines the resulting semantic relation — todo_id cannot start until blocker_id completes — which is far more informative than the tool name alone. It does not, however, name its obvious counterpart sibling todo_unblock, so an agent must infer the reverse operation from the tool list.

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?

Usage is implied rather than stated: an agent can infer this is the tool for expressing a dependency between two todos, and the sibling todo_unblock clearly reverses it. There is no explicit 'use when / do not use when' framing, no mention of todo_unblock, and no guidance on when a dependency should be modeled as a blocker versus some other mechanism.

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