Apply up to 50 task and dependency changes atomically, using refs to link new tasks across operations and an idempotency key to prevent duplicate project updates.
Atomic 1..50 task/dependency operations. Each has tool, arguments, optional ref on create_task. Use $ref in later task_id/depends_on_id.
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | ||
| idempotency_key | No |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses atomicity and the 1..50 bound, but says nothing about rollback/failure semantics (what happens if one operation fails), the result shape, or permission requirements. The idempotency_key parameter is present in the schema yet never explained behaviorally.
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 short, front-loaded sentences with no filler: the atomicity/count constraint leads, followed by the item shape and the ref usage rule. It is efficient, though the final $ref sentence is terse enough to be slightly cryptic.
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-batching tool with no annotations, no output schema, 0% schema coverage, and a nested array of operations, the description is too thin. It omits failure/rollback behavior, returned results per operation, and idempotency semantics — all critical for an agent deciding to commit 50 mutations at once.
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 0%, so the description must compensate. It does explain the otherwise-opaque ref mechanism (optional on create_task, referenced later via $ref in task_id/depends_on_id), which is genuinely valuable, but 'arguments' stays opaque and idempotency_key is entirely undocumented, so the compensation is only partial.
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 names the resource (task/dependency operations), the batching scope (1..50), and the atomicity guarantee, and it enumerates the operations it aggregates (create_task, update_task, add_dependency), which implicitly distinguishes it from the individual sibling tools. It lacks an explicit verb ('executes') and never names a sibling it replaces, so it falls short of the 5 bar.
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?
The word 'Atomic' implies the usage context (prefer when all-or-nothing semantics matter), and the $ref/$ref instruction tells the agent how to wire dependencies. However, it never says when to choose batch over sequential create_task/update_task calls, nor any exclusions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.