Problem
A repeating to-do in Things (for example a biweekly "Fill EI report") is invisible to the reads an assistant relies on for planning. get_upcoming returns only one-off dated to-dos, so the repeating item's next occurrence never appears. search_todos does not match the repeating item at all, and it does not search the Logbook, so even the completed instance is invisible. The only way to see the item is by paging the Logbook after an instance completes. An assistant planning a user's week therefore has no reliable way to know which recurring obligations come due, which defeats weekly planning.
Reproduction
Create a repeating to-do that repeats every 2 weeks and complete one instance so it sits in the Logbook. Calling get_upcoming does not show the next occurrence. Calling search_todos with the title returns no match, even though the item exists and repeats.
Likely root cause
Things stores a repeating to-do as a single template (TMTask with a recurrence rule). Future occurrences are materialized lazily on completion and are not persisted as dated rows, so a query over dated rows misses them.
Requested behavior (any one would help)
Option 1: get_upcoming includes the next materialized occurrence of each repeating to-do within the requested horizon, mirroring the Things app's Upcoming list. Option 2: a new tool such as get_repeating / get_recurring that lists all repeating to-dos with their recurrence rule and next due date. Option 3: search_todos gains an option to include the Logbook and to match repeating templates.
Why it matters
Assistants that help users plan (weekly reviews, day plans) must anticipate recurring tasks. Without visibility into repeating to-dos, every recurring obligation such as bill filing, benefit reports, or recurring chores silently drops from any agent-built plan.
Tested against hald/things-mcp v0.8.1.
Problem
A repeating to-do in Things (for example a biweekly "Fill EI report") is invisible to the reads an assistant relies on for planning.
get_upcomingreturns only one-off dated to-dos, so the repeating item's next occurrence never appears.search_todosdoes not match the repeating item at all, and it does not search the Logbook, so even the completed instance is invisible. The only way to see the item is by paging the Logbook after an instance completes. An assistant planning a user's week therefore has no reliable way to know which recurring obligations come due, which defeats weekly planning.Reproduction
Create a repeating to-do that repeats every 2 weeks and complete one instance so it sits in the Logbook. Calling
get_upcomingdoes not show the next occurrence. Callingsearch_todoswith the title returns no match, even though the item exists and repeats.Likely root cause
Things stores a repeating to-do as a single template (
TMTaskwith a recurrence rule). Future occurrences are materialized lazily on completion and are not persisted as dated rows, so a query over dated rows misses them.Requested behavior (any one would help)
Option 1:
get_upcomingincludes the next materialized occurrence of each repeating to-do within the requested horizon, mirroring the Things app's Upcoming list. Option 2: a new tool such asget_repeating/get_recurringthat lists all repeating to-dos with their recurrence rule and next due date. Option 3:search_todosgains an option to include the Logbook and to match repeating templates.Why it matters
Assistants that help users plan (weekly reviews, day plans) must anticipate recurring tasks. Without visibility into repeating to-dos, every recurring obligation such as bill filing, benefit reports, or recurring chores silently drops from any agent-built plan.
Tested against hald/things-mcp v0.8.1.