Repeating tasks in Things exist as templates until their date arrives, when Things generates a real to-do. Generated to-dos are fully visible to this MCP server, but the templates themselves are invisible, so an assistant can't answer "what repeats will land on my plate tomorrow/this week?" even though that's exactly the kind of awareness question MCP excels at during daily/weekly planning.
Why they're invisible: things.py hard-codes the exclusion. Every task query includes rt1_recurrenceRule IS NULL (database.py, IS_NOT_RECURRING), with no parameter to bypass it. Interestingly, the constants for the reverse (IS_RECURRING, RECURRING_HAS_NEXT_STARTDATE) exist in things.py but are commented out.
The data is all there, read-only. Templates live in TMTask with rt1_recurrenceRule IS NOT NULL; the useful fields are title, notes, project/area, rt1_instanceCreationPaused, and rt1_nextInstanceStartDate. The next-instance date is a packed int that decodes as:
year = v >> 16
month = (v >> 12) & 15
day = (v >> 7) & 31
I've verified this decoding against a live database (161 active templates); next-instance dates match the Things UI exactly.
Proposal: a read-only get-repeating-templates tool, e.g.:
days (optional, default 7): only templates whose next instance falls within N daysall (optional, default false): every active template, plus paused ones flagged- Returns title, next instance date, paused flag, containing project/area
Since things.py doesn't expose these rows, the tool would need a small direct SQLite query (opened with ?mode=ro, same file things.py already reads). Alternatively, an upstream parameter in things.py could come first; happy to file that there instead/as well if you'd prefer.
Scope note: this is view-only and complements rather than conflicts with #42's wontfix. No safe write path exists for recurrence rules (URL scheme and AppleScript can't create or modify repeats), but reading templates carries the same risk profile as the server's existing reads: none.
I have a working standalone prototype of the query + date decoding and I'm happy to turn it into a PR if you're open to the feature.
Repeating tasks in Things exist as templates until their date arrives, when Things generates a real to-do. Generated to-dos are fully visible to this MCP server, but the templates themselves are invisible, so an assistant can't answer "what repeats will land on my plate tomorrow/this week?" even though that's exactly the kind of awareness question MCP excels at during daily/weekly planning.
Why they're invisible: things.py hard-codes the exclusion. Every task query includes
rt1_recurrenceRule IS NULL(database.py,IS_NOT_RECURRING), with no parameter to bypass it. Interestingly, the constants for the reverse (IS_RECURRING,RECURRING_HAS_NEXT_STARTDATE) exist in things.py but are commented out.The data is all there, read-only. Templates live in
TMTaskwithrt1_recurrenceRule IS NOT NULL; the useful fields aretitle,notes,project/area,rt1_instanceCreationPaused, andrt1_nextInstanceStartDate. The next-instance date is a packed int that decodes as:I've verified this decoding against a live database (161 active templates); next-instance dates match the Things UI exactly.
Proposal: a read-only
get-repeating-templatestool, e.g.:days(optional, default 7): only templates whose next instance falls within N daysall(optional, default false): every active template, plus paused ones flaggedSince things.py doesn't expose these rows, the tool would need a small direct SQLite query (opened with
?mode=ro, same file things.py already reads). Alternatively, an upstream parameter in things.py could come first; happy to file that there instead/as well if you'd prefer.Scope note: this is view-only and complements rather than conflicts with #42's wontfix. No safe write path exists for recurrence rules (URL scheme and AppleScript can't create or modify repeats), but reading templates carries the same risk profile as the server's existing reads: none.
I have a working standalone prototype of the query + date decoding and I'm happy to turn it into a PR if you're open to the feature.