amazing-marvin-complete-mcp

update_recurring_task

Idempotent

Instructions

Change a recurring task: rule, window, place, end date, properties. Existing occurrences are not corrected when the rule changes via the API, and a later save in the app does not correct them either; they keep their old shape. When the rule is changed in the app's dialog, the app itself removes those that no longer match. When type, interval or Create occurrences change, the tool then works out which open, untouched occurrences from today on do not match the new rule or window. Mode 'list' (default): they are listed and removed only with confirm=true (without deletedDates: they do not come back if they do not match the rule, and outside the window they should come back). Changed occurrences, occurrences before today, custom rules that are not RRULEs and Only on weekdays are listed only. Deleted occurrences can remain visible in an open client until it reloads. New occurrences follow a rule and properties changed via the API, counted from the start day. Custom accepts only an RRULE string. Lowering Create occurrences via the API removes nothing, not even at the next generation; the app's dialog removes untouched upcoming occurrences when the lowering is saved there. confirm=true does what the dialog does.

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Note (replaces)
`size`	No	Size XS-XL, '' removes it
`title`	No	New title
`custom`	No	custom: an RRULE string, e.g. 'RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=FR'
`repeat`	No	New type (not to/from after_completion). The dialog's eleven types: daily, weekly (weekday), monthly (month_day), x_times_per_week (weekdays), every_x_days / every_x_weeks / every_x_months / every_x_years (interval), after_completion (after_days), on_off (on_days, off_days), custom (custom: an RRULE string, e.g. 'RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=FR')
`confirm`	No	True = remove the occurrences the cleanup listed
`ends_on`	No	End date YYYY-MM-DD, '' removes it
`on_days`	No	on_off
`weekday`	No	weekly
`interval`	No	every_x_*
`off_days`	No	on_off
`priority`	No	isStarred 3/2/1/-1, 0 removes it
`weekdays`	No	x_times_per_week
`label_ids`	No	Labels (replaces)
`month_day`	No	monthly
`parent_id`	No	Move the recurring task (the next occurrences land there)
`subtasks_add`	No	New subtasks on the recurring task
`bonus_section`	No	Essential/Bonus, '' removes it
`daily_section`	No	Day section, '' removes it
`only_weekdays`	No	Only on weekdays: a month day on a weekend is moved to Friday (verified); every_x_days counts in weekdays (inferred)
`if_you_miss_one`	No	If you miss one
`recurring_task_id`	Yes	The recurring task's ID (recurringTaskId on an occurrence)
`create_occurrences`	No	default/0/1/3/7/14/30
`hard_deadline_days`	No	Hard deadline, 0 = off

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.7.3Oct 13, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, openWorld=false, so the bar is lower, yet the description adds genuinely non-obvious behavior: occurrences keep their old shape after a rule change, removal happens only with confirm=true, deleted occurrences linger in open clients until reload, custom accepts only an RRULE, and lowering create_occurrences via the API removes nothing while the app's dialog does. The occurrence removal it discloses for confirm=true is in slight tension with destructiveHint=false, but it is an explicit, opt-in cleanup of derived occurrences rather than destruction of the target task, so it is not scored as a contradiction.

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

Conciseness2/5

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

The first sentence is a clean, front-loaded summary, but the rest is an unstructured ~230-word run-on that repeats 'via the API'/'in the app' and 'the app's dialog' many times and uses fragments like 'Mode list (default): they are listed...' to embed the confirm semantics. The density makes the critical list-vs-confirm rule hard to extract.

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?

For a 24-parameter update tool with an output schema present, the description concentrates on the surprising behaviors an agent most needs (occurrence reconciliation, confirm-gated deletion, delayed propagation, RRULE-only custom rules) while parameter-level details sit in a 100%-covered schema. It lacks only prerequisites such as permissions and what happens to untouched properties, so it is essentially complete.

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?

With 100% schema description coverage the baseline is 3, but the description adds real semantics on top of the schema: changing repeat, interval or create_occurrences triggers reconciliation of open untouched occurrences from today on, custom accepts only an RRULE string, and lowering create_occurrences via the API removes nothing even at the next generation. These are behavior-level meanings the schema alone does not convey.

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 opening line 'Change a recurring task: rule, window, place, end date, properties' gives a specific verb (change), the exact resource (recurring task) and the editable dimensions, so the purpose is unmistakable. It does not, however, differentiate itself from siblings such as update_task or create_recurring_task, so the agent must infer which tool owns 'recurring' semantics.

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 rather than stated: the 'Mode list (default)' vs 'confirm=true' discussion effectively describes a preview-then-confirm workflow, and the app-vs-API notes hint at when reconciliation happens. But there is no explicit 'use this tool when…' clause and no contrast against update_task/create_recurring_task, so an agent gets the mechanics of the confirm flag but not the selection rule.

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

Deploy Server