Skip to main content
Glama

update_recurring_task

Update a recurring task. Title, notes, urgency or reminder changes patch existing instances; frequency/date changes regenerate future instances.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesTemplate id from create_recurring_task.
notesNoNew notes, copied to uncompleted instances.
titleNoNew title. Uncompleted instances are updated to match; completed ones keep theirs.
endDateNoNew inclusive end date, YYYY-MM-DD. Empty string makes it open-ended.
isUrgentNoMark every task this series generates as urgent: true marks urgent, false clears it, omit to leave unchanged. A change also applies to the series' open occurrences.
startDateNoNew start date, YYYY-MM-DD. Empty string clears it.
cronExpressionNoNew interval as 'N Unit', Unit one of Day, Week, Month, Year, e.g. '2 Week'. Not cron syntax.
maxOccurrencesNoNew cap on instances generated.
preparationDaysNoLegacy single reminder, days before each occurrence's due date, 0-365 (0 means none); use reminderOffsetMinutes instead. Ignored when reminderOffsetMinutes is sent. On a series without reminderOffsetMinutes it applies to instances generated after this change. On a series with reminderOffsetMinutes the server keeps it in step: a different value replaces every reminder with that one (0 removes them) and also updates the series' open tasks.
assigneeRotationNoA member id from list_house_members.
reminderOffsetMinutesNoNew reminder lead times, in minutes before each generated task's due date. Send the full list: it replaces the current one. [] clears all reminders; omit to keep them. A change also applies to the series' open tasks. Each value is whole hours, 60-1380 (1-23 hours), or whole days, a multiple of 1440 up to 40320 (4 weeks, the most for a repeating item); a week is 10080. Up to 5 values. A due date counts from 00:00 on that day, so 300 (5 hours) is 19:00 the evening before. Day and week reminders arrive at 19:00 on the earlier day; hour reminders arrive that many hours before, or up to 15 minutes earlier.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
titleNo
messageNo
variantNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / isUrgent
      Added value: +{
      +  "description": "Mark every task this series generates as urgent: true marks urgent, false clears it, omit to leave unchanged. A change also applies to the series' open occurrences.",
      +  "examples": [
      +    true
      +  ],
      +  "type": "boolean"
      +}
    • changedInput schema / properties / preparationDays / description
      Previous value: -"Days before each due date to set that instance's preparation date. Applies to instances generated after this change."New value: +"Legacy single reminder, days before each occurrence's due date, 0-365 (0 means none); use reminderOffsetMinutes instead. Ignored when reminderOffsetMinutes is sent. On a series without reminderOffsetMinutes it applies to instances generated after this change. On a series with reminderOffsetMinutes the server keeps it in step: a different value replaces every reminder with that one (0 removes them) and also updates the series' open tasks."
    • addedInput schema / properties / reminderOffsetMinutes
      Added value: +{
      +  "description": "New reminder lead times, in minutes before each generated task's due date. Send the full list: it replaces the current one. [] clears all reminders; omit to keep them. A change also applies to the series' open tasks. Each value is whole hours, 60-1380 (1-23 hours), or whole days, a multiple of 1440 up to 40320 (4 weeks, the most for a repeating item); a week is 10080. Up to 5 values. A due date counts from 00:00 on that day, so 300 (5 hours) is 19:00 the evening before. Day and week reminders arrive at 19:00 on the earlier day; hour reminders arrive that many hours before, or up to 15 minutes earlier.",
      +  "examples": [
      +    [
      +      1440,
      +      10080
      +    ]
      +  ],
      +  "items": {
      +    "description": "One lead time in minutes: whole hours 60-1380, or a multiple of 1440 for days.",
      +    "examples": [
      +      1440
      +    ],
      +    "maximum": 40320,
      +    "minimum": 60,
      +    "multipleOf": 60,
      +    "type": "integer"
      +  },
      +  "maxItems": 5,
      +  "type": "array",
      +  "uniqueItems": true
      +}
  2. Changed12 schema fields changed
    • changedInput schema / properties / assigneeRotation / description
      Previous value: -"New ordered list of household member IDs to round-robin through, replacing the existing rotation entirely. Applies to instances generated after this change; already-created instances are unaffected. Omit to leave the rotation unchanged."New value: +"A member id from list_house_members."
    • changedInput schema / properties / assigneeRotation / items / description
      Previous value: -"A household member ID (from list_house_members) taking a turn in the rotation."New value: +"Replacement rotation of member ids, round-robined one per instance. Applies to instances generated after this change."
    • changedInput schema / properties / cronExpression / description
      Previous value: -"New recurrence frequency expression in the format 'N Unit', e.g. '2 Week' for every two weeks. Unit must be exactly Day, Week, Month, or Year (case-sensitive). Despite the parameter name, this is not cron syntax. Changing this deletes uncompleted future instances and regenerates them from the new schedule."New value: +"New interval as 'N Unit', Unit one of Day, Week, Month, Year, e.g. '2 Week'. Not cron syntax."
    • changedInput schema / properties / endDate / description
      Previous value: -"New end date for the schedule (inclusive), in YYYY-MM-DD format. Omit to leave unchanged, or send an empty string for an open-ended schedule. Changing this regenerates future uncompleted instances."New value: +"New inclusive end date, YYYY-MM-DD. Empty string makes it open-ended."
    • changedInput schema / properties / id / description
      Previous value: -"The recurring task's ID, as returned by create_recurring_task or list_recurring_tasks."New value: +"Template id from create_recurring_task."
    • changedInput schema / properties / maxOccurrences / description
      Previous value: -"New maximum total number of instances to generate. Changing this regenerates future uncompleted instances."New value: +"New cap on instances generated."
    • changedInput schema / properties / notes / description
      Previous value: -"New notes for the template, copied to existing uncompleted generated instances. Omit to leave unchanged."New value: +"New notes, copied to uncompleted instances."
    • addedInput schema / properties / notes / examples
      Added value: +[
      +  "Blue bin only"
      +]
    • changedInput schema / properties / preparationDays / description
      Previous value: -"Number of days before each occurrence's due date to set that instance's preparation date. Only affects instances generated after this change; existing uncompleted instances keep their original preparation date unless a frequency, start date, end date, or max-occurrences change also triggers regeneration."New value: +"Days before each due date to set that instance's preparation date. Applies to instances generated after this change."
    • changedInput schema / properties / startDate / description
      Previous value: -"New start date for the schedule, in YYYY-MM-DD format. Omit to leave unchanged, or send an empty string to clear it. Changing this regenerates future uncompleted instances."New value: +"New start date, YYYY-MM-DD. Empty string clears it."
    • changedInput schema / properties / title / description
      Previous value: -"New title for the template. Existing uncompleted generated instances are updated to match; completed ones keep their original title. Omit to leave unchanged."New value: +"New title. Uncompleted instances are updated to match; completed ones keep theirs."
    • addedInput schema / properties / title / examples
      Added value: +[
      +  "Take out the recycling"
      +]
  3. Changed18 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "assigneeRotation": [
      +      "7f3a9c2e1b4d8f6a0c5e3b7d9a1f4c6e"
      +    ],
      +    "cronExpression": "2 Week",
      +    "id": "5c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f",
      +    "title": "Take out the recycling"
      +  }
      +]
    • addedInput schema / properties / assigneeRotation / description
      Added value: +"New ordered list of household member IDs to round-robin through, replacing the existing rotation entirely. Applies to instances generated after this change; already-created instances are unaffected. Omit to leave the rotation unchanged."
    • addedInput schema / properties / assigneeRotation / items / description
      Added value: +"A household member ID (from list_house_members) taking a turn in the rotation."
    • addedInput schema / properties / assigneeRotation / items / examples
      Added value: +[
      +  "7f3a9c2e1b4d8f6a0c5e3b7d9a1f4c6e"
      +]
    • changedInput schema / properties / cronExpression / description
      Previous value: -"Cron expression for recurrence. Format: minute hour dayOfMonth month dayOfWeek"New value: +"New recurrence frequency expression in the format 'N Unit', e.g. '2 Week' for every two weeks. Unit must be exactly Day, Week, Month, or Year (case-sensitive). Despite the parameter name, this is not cron syntax. Changing this deletes uncompleted future instances and regenerates them from the new schedule."
    • addedInput schema / properties / cronExpression / examples
      Added value: +[
      +  "2 Week"
      +]
    • changedInput schema / properties / endDate / description
      Previous value: -"YYYY-MM-DD format"New value: +"New end date for the schedule (inclusive), in YYYY-MM-DD format. Omit to leave unchanged, or send an empty string for an open-ended schedule. Changing this regenerates future uncompleted instances."
    • addedInput schema / properties / endDate / examples
      Added value: +[
      +  "2026-12-31"
      +]
    • addedInput schema / properties / id / description
      Added value: +"The recurring task's ID, as returned by create_recurring_task or list_recurring_tasks."
    • addedInput schema / properties / id / examples
      Added value: +[
      +  "5c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f"
      +]
    • addedInput schema / properties / maxOccurrences / description
      Added value: +"New maximum total number of instances to generate. Changing this regenerates future uncompleted instances."
    • addedInput schema / properties / maxOccurrences / examples
      Added value: +[
      +  26
      +]
    • addedInput schema / properties / notes / description
      Added value: +"New notes for the template, copied to existing uncompleted generated instances. Omit to leave unchanged."
    • addedInput schema / properties / preparationDays / description
      Added value: +"Number of days before each occurrence's due date to set that instance's preparation date. Only affects instances generated after this change; existing uncompleted instances keep their original preparation date unless a frequency, start date, end date, or max-occurrences change also triggers regeneration."
    • addedInput schema / properties / preparationDays / examples
      Added value: +[
      +  1
      +]
    • changedInput schema / properties / startDate / description
      Previous value: -"YYYY-MM-DD format"New value: +"New start date for the schedule, in YYYY-MM-DD format. Omit to leave unchanged, or send an empty string to clear it. Changing this regenerates future uncompleted instances."
    • addedInput schema / properties / startDate / examples
      Added value: +[
      +  "2026-08-01"
      +]
    • addedInput schema / properties / title / description
      Added value: +"New title for the template. Existing uncompleted generated instances are updated to match; completed ones keep their original title. Omit to leave unchanged."
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining side effects. It does this well by stating that title/notes/urgency/reminder changes patch existing instances while frequency/date changes regenerate future instances. It does not cover every behavioral nuance, such as assigneeRotation applying only to future instances, but it adds real value beyond annotations.

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?

A single sentence carries the core purpose and the most important behavioral distinction, with no filler or redundant restatement. The most decision-relevant information is front-loaded.

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

Completeness4/5

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

Given an 11-parameter mutation with 100% schema coverage, annotations, and an output schema, the description only needs to provide cross-cutting semantics, which it does. The main omission is that assigneeRotation's future-only behavior is not included in the summary, but the schema states it clearly, so the tool remains fully invokable.

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 100%, so the baseline is 3. The description adds value by grouping parameters into behavioral categories (patch existing vs regenerate future), which helps the agent predict effects across multiple fields. It does not enumerate every parameter, but the schema already documents each one thoroughly.

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

Purpose5/5

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

The description opens with a specific verb and resource ('Update a recurring task') and then differentiates behavior from one-off task updates by distinguishing patches to existing instances from regeneration of future instances. This makes the tool's scope unmistakable even among many update_* siblings.

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

Usage Guidelines3/5

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

Usage is implied by the resource name and by the patch-vs-regenerate semantics, but there is no explicit guidance about when to prefer this tool over update_task, update_recurring_calendar_event, or create_recurring_task. No exclusions or alternative-routing conditions are provided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources