Skip to main content
Glama
Sign In
Doist

Todoist AI MCP Server

Official
by Doist
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update-sections

Destructive

Update multiple existing Todoist sections in one call, changing names or descriptions as needed.

Instructions

Update multiple existing sections with new values.

Input Schema

NameRequiredDescriptionDefault
sectionsYesThe sections to update.

Output Schema

NameRequiredDescriptionDefault
failuresYesSections that could not be updated, with the reason for each.
sectionsYesThe updated sections.
totalCountYesThe total number of sections updated.
appliedOperationsYes
updatedSectionIdsYesThe IDs of the updated sections.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv13.8.0
    • addedOutput schema / properties / appliedOperations
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "failureCount": {
+      "type": "number"
+    },
+    "updateCount": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "updateCount",
+    "failureCount"
+  ],
+  "type": "object"
+}
    • addedOutput schema / properties / failures
      Added value: +{
+  "description": "Sections that could not be updated, with the reason for each.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "code": {
+        "type": "string"
+      },
+      "error": {
+        "type": "string"
+      },
+      "item": {
+        "description": "Usually the ID of the item that failed.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "item",
+      "error"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "sections",
-  "totalCount",
-  "updatedSectionIds"
-]New value: +[
+  "sections",
+  "totalCount",
+  "updatedSectionIds",
+  "failures",
+  "appliedOperations"
+]
  2. Changed2 schema fields changedv13.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed4 schema fields changedv12.5.3
    • changedOutput schema / properties / sections / items / properties / description / description
      Previous value: -"The description of the section. Supports Markdown."New value: +"Supports Markdown."
    • removedOutput schema / properties / sections / items / properties / id / description
      Removed value: -"The unique ID of the section."
    • removedOutput schema / properties / sections / items / properties / name / description
      Removed value: -"The name of the section."
    • changedOutput schema / properties / sections / items / properties / sectionOrder / description
      Previous value: -"The ordering index of the section within its project."New value: +"Ordering index within the project."
  4. Changed2 schema fields changedv12.1.2
    • addedOutput schema / properties / sections / items / properties / sectionOrder
      Added value: +{
+  "description": "The ordering index of the section within its project.",
+  "type": "number"
+}
    • changedOutput schema / properties / sections / items / required
      Previous value: -[
-  "id",
-  "name"
-]New value: +[
+  "id",
+  "name",
+  "sectionOrder"
+]
  5. First observedv10.4.2

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false and openWorldHint=false, so the safety profile is largely covered. The description adds only the batch scope; it does not explain why the call is flagged destructive (e.g., whether omitting a section in the payload affects it) or that a failed batch may partially apply.

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?

A single front-loaded sentence with zero filler. It is lean rather than bloated; the only issue is that its brevity leaves gaps the agent must fill from annotations and schema.

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?

With one parameter, a full schema, an output schema and four annotations hints, most of what an agent needs is present. However, the description omits the prerequisite of resolving section IDs (find-sections) and gives no hint about the destructive/idempotency semantics that the annotations flag but do not explain.

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

Parameters3/5

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

Schema description coverage is 100% and each field (id, name, description with null-to-clear) is documented inline, so the baseline of 3 applies. 'With new values' in the description adds nothing the schema does not already state more precisely.

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?

Specific verb+resource ('Update ... sections') plus the batch qualifier 'multiple existing', which tells the agent this operates on already-existing records rather than creating them. It does not explicitly differentiate from siblings like add-sections or find-sections, but the verb and 'existing' constraint make the intent unambiguous.

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 statement of when to use this versus add-sections/find-sections, and no guidance on obtaining section IDs before calling. The word 'existing' weakly implies a lookup prerequisite, but that is inference rather than guidance.

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

Deploy Server

Other Tools