delega-mcp

update_recurrence

Modify a recurring task template's schedule, content, priority, or labels, and pause or resume task spawning by setting active to false or true.

Instructions

Update a recurring task template, including pausing/resuming with active=false/true.

Input Schema

TableJSON Schema

Name	Required	Description
`active`	No	Whether the recurrence is active
`labels`	No	Labels for spawned tasks
`content`	No	Task title/content for future spawned instances
`interval`	No	Rule interval
`priority`	No	Priority 1-4
`timezone`	No	IANA timezone
`rule_type`	No	Recurrence rule type
`anchor_day`	No	Day of month for monthly/yearly rules
`project_id`	No	Optional project ID, or null to clear
`description`	No	Optional task description
`next_due_at`	No	ISO timestamp for next due occurrence
`anchor_month`	No	Month for yearly rules
`skip_if_open`	No	Skip spawning while a prior instance is open
`recurrence_id`	Yes	The recurrence ID to update
`anchor_weekday`	No	Weekday for weekly rules, Sunday=0
`assigned_to_agent_id`	No	Optional assignee, or null to clear

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.19.0Sep 11, 2026

removedInput schema / properties / assigned_to_agent_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / assigned_to_agent_id / type
```
Added value: +[
+  "string",
+  "number",
+  "null"
+]
```

removedInput schema / properties / description / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / description / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / next_due_at / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / next_due_at / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / project_id / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "type": "string"
-      },
-      {
-        "type": "number"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / project_id / type

Added value: +[
+  "string",
+  "number",
+  "null"
+]

removedInput schema / properties / recurrence_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]

addedInput schema / properties / recurrence_id / type
```
Added value: +[
+  "string",
+  "number"
+]
```

Addedv1.13.0Jun 14, 2026

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It discloses that the tool updates a recurrence and can pause/resume via the active flag, but does not mention permissions, side effects on already spawned tasks, reversibility, or any other behavioral traits. This is minimal for a mutation tool.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that conveys the core action and a key parameter behavior without any wasted words.

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?

Given a complex mutation tool with 16 parameters, no annotations, and no output schema, the description is minimal. It covers the essential action but lacks context on side effects, constraints, or what happens to existing tasks. It is adequate but incomplete.

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%, so the schema already documents all 16 parameters thoroughly. The description adds only the meaning of the active parameter as pause/resume, which is a small addition beyond the schema's 'Whether the recurrence is active'. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

The description states the verb 'update' and the resource 'recurring task template', which is clear. It does not explicitly differentiate itself from siblings like update_task or create_recurring_task, but the term 'recurrence' aligns with the tool name and distinguishes it from task-level updates.

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?

There is no guidance on when to use this tool versus alternatives such as update_task or create_recurring_task. The only contextual hint is the use of active=false/true for pause/resume, but this is usage of a parameter, not a when-to-use guide.

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

update_recurrence

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools