Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@things-turbo run my morning review"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Composite MCP server for Things 3 on macOS. Two problems, one package:
Call-count bloat. Agent workflows against Things burn 10+ round trips for a morning review: projects, areas, tags, today, inbox, logbook, per-project todos. things-turbo bundles them. get_review_data is one call. get_dashboard is one call.
sqlite3.OperationalError: unable to open database file. The Things database lives in a TCC-protected group container. macOS decides per process, with caching, whether reads are allowed, and the answer can flip mid-session. When it flips, every read in every affected session dies at once. things-turbo ships a self-healing read path that falls back to a TCC-free SQLite mirror and keeps working.
Under 700 lines of Python. Reads go through things.py against the Things SQLite database; writes go through the official Things URL scheme, so Things itself does the writing.
People driving Things 3 from Claude (or any MCP client) who want fewer round trips, batch writes, and reads that survive macOS app-data protection. For one-at-a-time CRUD, upstream things-mcp may be enough; this package also ships a things-mcp-resilient entry point that runs upstream things-mcp with the self-healing read path patched in.
Related MCP server: Things Cloud MCP
Composite reads, each replacing several separate MCP calls:
Tool | What it returns |
| Projects, areas, and tags in one call |
| Today, inbox, upcoming, and overdue |
| Everything a weekly review needs: today, inbox, anytime/someday counts, projects with todo counts, logbook |
| Stalled-project detection: per-project last completion, next-action presence, and a health class (shipping / cruising / stalled / zombie / empty) |
Batch writes via the URL scheme:
Tool | What it does |
| Update many todos in one call (title, notes, when, deadline, tags, completed, canceled) |
| Complete a list of todos |
| Move a list of todos to the same date |
| Replace, append, or prepend checklist items, which the standard MCP tools can't do |
Requires macOS with Things 3, Python 3.12+, and uv.
Claude Code (.mcp.json or claude mcp add):
{
"mcpServers": {
"things-turbo": {
"command": "uvx",
"args": ["--from", "git+https://github.com/BradleyAllanDavis/things-turbo", "things-turbo"],
"env": {
"THINGS_AUTH_TOKEN": "your-token-here"
}
}
}
}The auth token is needed for writes only. Get it in Things: Settings > General > Enable Things URLs > Manage. To keep the token out of plain config, set THINGS_AUTH_TOKEN_CMD to a command that prints it:
"env": {
"THINGS_AUTH_TOKEN_CMD": "op read 'op://Private/Things Auth Token/credential'"
}things-turbo tries the live Things database first. On a TCC denial it:
remembers the denial for 5 minutes,
kickstarts the launchd mirror agent named in THINGS_MIRROR_AGENT, if set,
reads the mirror at THINGS_MIRROR_PATH (default ~/.cache/things-mirror/main.sqlite).
While reads are healthy, it also refreshes the mirror opportunistically (VACUUM INTO a temp file, atomic replace), so any process that still has access keeps the mirror warm for the ones that don't.
The mirror can be produced by anything that copies the Things database on a schedule. A launchd agent running sqlite3 <things-db> "VACUUM INTO '<mirror>'" under a shell with a one-time Full Disk Access grant works well; set THINGS_MIRROR_AGENT to its label and things-turbo will kickstart it on demand.
THINGSDB (the standard things.py override) always wins and never falls back.
Variable | Purpose | Default |
| Things URL-scheme token, used for writes | unset |
| Shell command that prints the token | unset |
| TCC-free mirror location |
|
| launchd label to kickstart for a mirror refresh | unset |
| Explicit database path (things.py standard); disables fallback | unset |
MIT
Update multiple todos at once via the Things URL scheme.
Each update is a dict with 'id' (required) and any of: title, notes, when, deadline, tags, completed (bool), canceled (bool).
Args: updates: List of update dicts. Each must have 'id' key. Example: [{"id": "ABC123", "completed": true}, {"id": "DEF456", "when": "tomorrow"}]
Returns: Summary of updates applied.
Inputs: updates (required).
Mark multiple todos as completed in one call.
Args: todo_ids: List of todo UUIDs to complete.
Inputs: todo_ids (required).
Reschedule multiple todos to the same date/time in one call.
Args: todo_ids: List of todo UUIDs to reschedule. when: New schedule — today, tomorrow, evening, anytime, someday, or YYYY-MM-DD.
Inputs: when (required), todo_ids (required).
Get all structural metadata in one call: projects, areas, tags, and headings.
This replaces 3-4 separate MCP calls that every skill needs at startup. Returns a dict with projects (name + uuid + area), areas, and tags.
Inputs: no named parameters.
Get a complete daily dashboard in one call: today, inbox count, upcoming, overdue.
This replaces 4+ separate MCP calls for morning standup / plan-day.
Args: upcoming_days: How many days ahead to include in upcoming (default 3).
Inputs: upcoming_days.
Get project health data for stalled-project detection.
For each active project, returns: title, area, todo count, last completion date, and whether it has a clear next action. One call replaces the get_projects + get_logbook + per-project todo queries pattern.
Returns a dict with 'projects' list and 'summary' counts by health status.
Inputs: no named parameters.
Get all data needed for a weekly/daily review in one call.
Bundles: today, inbox, anytime, someday, projects (with todos), areas, logbook, and tags. This replaces 10+ separate MCP calls.
Args: logbook_period: How far back to pull logbook entries (default '1w'). Format: Nd, Nw, Nm, Ny (e.g., '7d', '2w', '1m').
Inputs: logbook_period.
Update checklist items on an existing todo.
This wraps the Things URL scheme to handle checklist operations that the standard update_todo MCP tool can't do.
Args: todo_id: UUID of the todo to update. items: List of checklist item strings. mode: One of 'replace', 'append', 'prepend' (default: 'replace').
Inputs: items (required), todo_id (required), mode. Returns: result
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 8 tools
The read tools (get_context, get_dashboard, get_review_data, get_project_health) are clearly distinct in their aggregation purposes. The write tools are also named by intent, though batch_update overlaps some with bulk_complete and bulk_reschedule since it can set completed and when, creating mild ambiguity.
Reads consistently use get_ and batch operations use bulk_ or batch_/update_. The pattern is readable and predictable, though batch_update and update_checklist break the bulk_ convention for write operations.
8 tools is a well-scoped size for a Things integration that provides both high-level read aggregation and targeted update operations. No tool feels redundant enough to remove, and the count is not overwhelming.
The server covers read aggregation, checklist updates, bulk completion, and rescheduling, but there are notable gaps: no tools for creating new todos, projects, areas, or tags, and no explicit delete/cancel operation beyond a canceled flag in batch_update. For a task-management server, lack of creation is a significant missing lifecycle operation.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Official Todoist MCP server. Manage tasks and projects. Hosted, no API key needed.
The official Planning Center MCP server for interacting with your ministry's data.
Read and write Mission Control state via MCP — projects, tasks, subtasks, templates, status updates.
