add_task_dependency

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It is a mutation operation (adds a dependency) with potential side-effects, but the description does not disclose whether the operation is reversible, what happens to existing dependencies, whether dependencies are directional, or what the response looks like. For a write tool with zero annotation coverage, this is a significant gap.

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 description is efficient at one sentence, but it is under-specified rather than concise. While there is no wasted text, the brevity does not earn its presence because it adds no information beyond what the name already conveys, so the conciseness is not a virtue here.

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 mutation tool with no output schema and no annotations, the description does not explain the directionality semantics of depends_on versus dependency_of, whether both can be set simultaneously, error conditions, or the meaning/return of the operation. The parameter semantics of a bidirectional dependency relationship are genuinely ambiguous and the description fails to clarify them. There is no output schema to compensate for this gap.

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%, and the parameter descriptions (despite being minimal) do explain each field's meaning: task_id, depends_on, and dependency_of. However, the description adds nothing beyond the schema, and the relationship between depends_on and dependency_of (mutual exclusivity? required together?) is unclear from both the schema and description. The baseline 3 applies since schema covers parameters adequately.

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 "Add a dependency between tasks" is a near-tautology of the tool name. It states the verb (add) and resource (task dependency) but provides no additional scope detail, such as how dependencies are represented (depends_on vs dependency_of) or what type of relationship is being created. It does not distinguish itself from the sibling delete_task_dependency beyond the obvious add/delete polarity.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., both tasks must exist, be in the same workspace), and no context about whether task dependencies require special permissions. The description provides no use-case context whatsoever beyond the bare operation.

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