Skip to main content
Glama

Batch Update Tasks

dida365_batch_update_tasks
Idempotent

Update multiple Dida365/TickTick tasks in one request, changing only specified fields and returning per-task etags or error details.

Instructions

Batch update multiple tasks in one request.

Each dict requires "id" and "projectId". Only provided fields are changed. Returns {"id2etag": {...}, "id2error": {...}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tasksYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false, covering the safety profile. The description adds genuine value with the partial-update semantics ("Only provided fields are changed"), but says nothing about auth requirements, atomicity across the batch, or partial-failure behavior beyond the return keys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then required-input contract, then return shape. No padding, though the return-value line is partly redundant given an output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch mutation with an opaque single-param schema, the definition covers required keys and partial-update behavior and an output schema covers the return shape. It still omits the set of updatable fields and any batch-failure semantics, which matter for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema is fully opaque (array of bare objects with additionalProperties=true), so the description carries the full burden. It usefully specifies the required keys ("id" and "projectId") per dict, though it does not enumerate which other fields can be updated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope ("Batch update multiple tasks in one request"), clearly a bulk-write tool. It does not explicitly name its sibling dida365_update_task (single) or dida365_batch_complete_tasks, so an agent must infer the batch/single distinction from naming alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is given. It never says when to prefer this over dida365_update_task for a single task or how it differs from dida365_batch_complete_tasks, leaving the agent to infer the selection rationale.

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