Change the dependencies of a draft or planned task by setting, adding, or removing prerequisite IDs; use it to enforce ordering before the task and keep plans valid.
Change the dependencies of a draft/planned task: set (replace; [] clears), add and/or remove ids. Each dependency must exist and be placed before the task (use task_move first). Planners only.
| Name | Required | Description | Default |
|---|---|---|---|
| by | Yes | ||
| id | Yes | ||
| add | No | ||
| set | No | ||
| remove | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint=false: it discloses that set replaces the whole set, that [] clears dependencies, that referenced ids must exist and precede the task, and that the caller must be a planner. It doesn't say what happens when validation fails (does the whole call fail, or partial apply?) or how set/add/remove interact when combined.
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 dense sentences with the operation and the three modes front-loaded, followed by prerequisites and authorization. No filler, no restating the tool name.
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 5-parameter mutation with an empty schema and no output schema, it covers the essential preconditions (existence, ordering, role) and mutation semantics. Remaining gaps are the meaning of the required 'by' and the precedence when set and add are supplied together.
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 0%, so the description must carry all semantics; it explains set/add/remove well, including the '[] clears' edge case, but leaves 'by' (required) completely undefined and 'id' only inferred from context. Two of five parameters, including one required, remain unclear.
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?
Names a specific verb (change dependencies) on a specific resource (a draft/planned task) and enumerates the three mutation modes (set/add/remove). The scope restriction to draft/planned tasks and the pointer to task_move clearly separate it from task_update and task_move.
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 states the ordering prerequisite for every dependency ('use task_move first') and the authorization constraint ('Planners only'). It implies rather than states the negative case (non-draft tasks), and does not name an alternative for changing dependencies on already-scheduled tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.