things-turbo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| THINGSDB | No | Explicit database path (things.py standard); disables fallback | |
| THINGS_AUTH_TOKEN | No | Things URL-scheme token, used for writes | |
| THINGS_MIRROR_PATH | No | TCC-free mirror location | ~/.cache/things-mirror/main.sqlite |
| THINGS_MIRROR_AGENT | No | launchd label to kickstart for a mirror refresh | |
| THINGS_AUTH_TOKEN_CMD | No | Shell command that prints the token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_contextA | 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. |
| get_dashboardA | 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). |
| get_review_dataA | 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'). |
| get_project_healthA | 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. |
| batch_updateB | 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. |
| update_checklistA | 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'). |
| bulk_completeA | Mark multiple todos as completed in one call. Args: todo_ids: List of todo UUIDs to complete. |
| bulk_rescheduleA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
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.