io.github.partymola/ticktick-mcp
MCP server for TickTick task management: field-preserving updates and completion tracking.
Open source Open in the app JSON README (API)
About
MCP server for TickTick task management: field-preserving updates and completion tracking.
Details
- Kind
- MCP servers
- Topic
- Productivity
- Publisher
- partymola
- Origin
- official
- Category
- ferramentas
- Transport
- local
- Version
- 0.3.4
- Stars
- 1
- Last push
- 2026-08-31T18:57:51Z
- Repository state
- ativo
- Language
- Python
- License
- GPL-3.0
- Added
- 2026-08-29 04:00:59
- Updated
- 2026-09-09 16:03:25
- Origin id
io.github.partymola/ticktick-mcp
README
# ticktick-mcp [](https://github.com/partymola/ticktick-mcp/actions/workflows/ci.yml) [](https://www.gnu.org/licenses/gpl-3.0) [](https://www.python.org/downloads/) [](https://glama.ai/mcp/servers/partymola/ticktick-mcp) MCP server for TickTick task management. Create, update, complete, move, and filter tasks via the TickTick v2 API, with field-preserving updates, day-of-week date validation, read-after-write verification, and idempotent completion tracking. Designed for [Claude Code](https://docs.anthropic.com/en/docs/claude-code) and other [MCP](https://modelcontextprotocol.io/) clients. Unofficial. Not affiliated with TickTick Ltd. Built on [`ticktick-py`](https://github.com/partymola/ticktick-py) (MIT). ## Features - **Full task lifecycle** - create, update, complete, move, subtask, and delete - **Field-preserving updates** - `ticktick_update_task` re-fetches the task and overlays only the fields you set, so the API never wipes the ones you omit - **Day-of-week validation** - any call that sets a date must confirm the weekday, catching off-by-one date mistakes before they reach the server - **Read-after-write verification** - create/update re-read the task and surface `_verification_warnings` when the server echo doesn't match - **Compact listing** - list tools return a trimmed view by default so large projects stay under the MCP result-size cap (see below) - **Fresh reads** - read tools re-sync server state on demand, so edits made from the TickTick app on other devices show up without a restart - **Completion tracking** - mark completed tasks as processed so an agent reviews each one exactly once ## Requirements - Python 3.13+ (tested on 3.13 and 3.14, on Linux, macOS and Windows, in CI) - [uv](https://docs.astral.sh/uv/) (recommended - see the install note below) - A TickTick account - A registered TickTick app for OAuth credentials (free - [developer.ticktick.com](https://developer.ticktick.com/manage)) ## Install ```bash git clone https://github.com/partymola/ticktick-mcp cd ticktick-mcp uv sync ``` This creates a `.venv` and installs from `uv.lock`, giving you the console script at `.venv/bin/ticktick-mcp`, or `.venv\Scripts\ticktick-mcp` on Windows. Every command below names it the POSIX way. `pip install .` works too. The fork of `ticktick-py` this server needs is pinned as a direct git reference inside `dependencies`, which pip and uv both honour; `uv sync` is recommended because it installs the exact versions in `uv.lock` rather than re-resolving them. ## Credentials TickTick sign-in needs two things: an OAuth app (client ID + secret) and your own account login. 1. Register an app at [developer.ticktick.com](https://developer.ticktick.com/manage). Set the **Redirect URI** to `http://localhost:8080/redirect`. Note the **Client ID** and **Client Secret**. 2. Copy the template into the directory the server reads, and fill it in: ```bash mkdir -p ~/.config/ticktick-mcp && cp .env.example ~/.config/ticktick-mcp/.env ``` ``` TICKTICK_CLIENT_ID=your_client_id TICKTICK_CLIENT_SECRET=your_client_secret TICKTICK_REDIRECT_URI=http://localhost:8080/redirect TICKTICK_USERNAME=your_ticktick_email TICKTICK_PASSWORD=your_ticktick_password ``` 3. This file holds your account password in plain text, and the server does not create it, so tighten it yourself. On POSIX: ```bash chmod 700 ~/.config/ticktick-mcp chmod 600 ~/.config/ticktick-mcp/.env ``` Those are POSIX mode bits, and on Windows they do nothing: access there follows the ACLs the file inherits from its parent directory. No Windows equivalent of the two commands is documented here. The two token files beside it are created owner-only, and a config directory the server creates is too - but one it finds already there is left as it is. Those are POSIX modes as well, set on Windows too, where they do not narrow who may read what. **Authorise once, at a terminal, before registering the server:** ```bash .venv/bin/ticktick-mcp auth ``` It opens a browser and asks you to paste back the URL you land on, then exits. The token is cached next to your `.env` as `.token-oauth`, and every later start reuses it. TickTick issues no refresh token, so this recurs when the token expires - run the same command again. Do not let that step happen inside the MCP server. The prompt reads from standard input, which for a stdio server is the JSON-RPC channel, so an unauthorised first tool call opens a browser on the host and blocks. In a container it cannot be completed at all - run `auth` on the host and mount the config directory in. The username/password half needs no separate step: the server logs in lazily on the first tool call and caches that session token as `.token-v2`, so it does not re-submit your credentials on every start. The server looks for `.env` in this order: the `--dotenv-dir <path>` argument, then the `TICKTICK_MCP_DOTENV_DIR` environment variable, then `~/.config/ticktick-mcp/`. If no `.env` is found it falls back to the `TICKTICK_*` environment variables directly, which is convenient for container/CI use. ## Privacy and the unofficial API Your TickTick credentials live only in your local `.env` (or the environment) and are sent only to TickTick's own servers - never to the developer or any third party. The server reads and writes only your own account. This server uses TickTick's unofficial v2 API (via `ticktick-py`) rather than the official Open API. That is a deliberate choice: the official API has no list-completed-tasks endpoint, no tags, and no cross-project task listing - all of which this server relies on. See [docs/why-not-the-official-api.md](https://github.com/partymola/ticktick-mcp/blob/main/docs/why-not-the-official-api.md) for the full rationale, the risk trade-off, and the triggers that would make us reconsider. ## Register with Claude Code ```bash claude mcp add -s user ticktick -- /path/to/ticktick-mcp/.venv/bin/ticktick-mcp --dotenv-dir /path/to/config ``` `--dotenv-dir` is optional if your `.env` lives in `~/.config/ticktick-mcp/` or you supply the `TICKTICK_*` variables through the environment. Then ask Claude things like: - "What's on my TickTick list for this week?" - "Add a task to call the dentist on Friday at 9am." - "Mark the grocery task as done." - "Move the budget task to the Finance project." ## Docker Images are published to `ghcr.io/partymola/ticktick-mcp`. Tags carry a `v` prefix (`:vX.Y.Z`), and `:latest` follows the most recent release. **Authorise on a machine with a browser first, then mount that directory in.** This is the only route, and it holds even with `docker run -it`: the underlying library opens the browser itself and **never prints the URL**, so there is nothing to copy out of a container that has no browser. It then waits for that URL on standard input, which for a stdio server is the JSON-RPC channel - so a container started against a directory with no cached token does not fail cleanly either, it consumes your client's requests waiting for input that never arrives. Authorising needs a source install ([Install](#install)) and the credentials from [Credentials](#credentials) - there is no published package to run it from. **Do not `pip install ticktick-mcp`:** that name on PyPI belongs to an unrelated project with a near-identical description. ```bash .venv/bin/ticktick-mcp auth # once, on the host, in a terminal claude mcp add -s user ticktick -- \ docker run --rm -i --user $(id -u):$(id -g) \ -v ~/.config/ticktick-mcp:/data \ ghcr.io/partymola/ticktick-mcp:latest ``` `-i` is required - the server speaks JSON-RPC over stdin and stdout. `--user` is there because the container runs as root by default, and anything it writes into the mounted directory becomes root-owned - after which the host-side `ticktick-mcp` can no longer update its session-token cache and falls back to a throttled signon on every start. You will run it on the host again: the OAuth token has no refresh, so `auth` recurs at expiry. **Mount a directory that is already authorised, never an empty volume.** `/data` holds the `.env`, the cached OAuth token, the v2 session token and the completion-tracking database. A fresh volume has none of them, and the password-signon fallback is throttled into a 15-30 minute lockout. If you would rather not keep a `.env` on disk at all, pass the credentials as environment variables instead. The mount is still needed - it holds the token cache, not just the `.env`: ```bash docker run --rm -i --user $(id -u):$(id -g) \ -v ~/.config/ticktick-mcp:/data \ -e TICKTICK_CLIENT_ID -e TICKTICK_CLIENT_SECRET \ -e TICKTICK_USERNAME -e TICKTICK_PASSWORD \ ghcr.io/partymola/ticktick-mcp:latest ``` Naming each variable without a value passes it through from your shell, so no secret appears in the command or in shell history. These **override** a mounted `.env`: the file is loaded without `override`, so anything already in the environment wins. Authorising still needs those variables exported on the host, since `auth` has no `.env` to read either. ## CLI ``` ticktick-mcp Start the MCP server (stdio transport) ticktick-mcp --dotenv-dir PATH Directory holding the .env file ticktick-mcp --version Print the installed package version ``` `auth` is the only other subcommand, and it exists so the browser step happens at a terminal rather than inside the server. All task operations happen through the MCP tools below. ## MCP tools | Tool | Description | |------|-------------| | `ticktick_create_task` | Create a task, preserving date/reminder/priority/timezone fields; warns if no due date is set (no reminder would fire) | | `ticktick_update_task` | Update a task by overlaying only the fields you set onto the current server object (omitted fields are never wiped) | | `ticktick_complete_task` | Mark a task complete and re-verify; distinguishes a recurring task rolling forward from a normal completion | | `ticktick_delete_tasks` | Delete one or more tasks by ID | | `ticktick_move_task` | Move a task into a different project | | `ticktick_make_subtask` | Nest one task as a subtask of another in the same project | | `ticktick_get_tasks_from_project` | List every open task in a project (compact or full) | | `ticktick_filter_tasks` | Find tasks by any mix of project, priority, tag, status, and due/completion-date window | | `ticktick_get_by_id` | Look up any task, project, or tag by its full ID | | `ticktick_get_all` | Dump all projects or all tags from local state | | `ticktick_sync` | Force an immediate refresh of local state from the server | | `ticktick_get_unprocessed_completions` | List recently completed tasks in a project not yet marked processed | | `ticktick_mark_completion_processed` | Record that a completed task has been reviewed, excluding it from future checks | | `ticktick_convert_datetime_to_ticktick_format` | Convert an ISO 8601 datetime + IANA timezone to TickTick's wire format | ## Projects: name or ID Every tool that takes a project ID also takes the project's **name** - `ticktick_create_task`, `ticktick_get_tasks_from_project`, `ticktick_update_task`, `ticktick_move_task`, `ticktick_delete_tasks`, `ticktick_filter_tasks`, and both completion-tracking tools: ``` ticktick_create_task(title="Renew insurance", project_id="Home Admin") ``` Names match case-insensitively, ignoring surrounding whitespace, and `"Inbox"` resolves to your inbox. IDs keep working unchanged and always win, so nothing that works today changes. The one new error is ambiguity: if two projects share a name, the call fails and names both IDs rather than picking one, since guessing would file the task somewhere you would not think to look. Anything else the server cannot resolve is passed to the API untouched, exactly as before. The two completion-tracking tools are the exception: they refuse a project reference they cannot confirm rather than passing it on, because that value is the key their local database is written under. An unresolvable one would write a row no later lookup by ID can find. If the project list could not be refreshed to check, they say so (`outcome: "project_list_unverifiable"`) instead of claiming the project does not exist. ## Listing tasks: compact by default The list-returning tools - `ticktick_get_tasks_from_project` and `ticktick_filter_tasks` - default to `detail="compact"`. Compact output keeps the browsing-relevant fields (`id`, `projectId`, `title`, `dueDate`, `startDate`, `priority`, `status`, `isAllDay`, `timeZone`, `tags`) plus a `contentPreview` (the first ~200 chars of `content`), and drops the heavy `content`/`desc`/checklist `items` blobs and bulky sync metadata. This keeps large projects under the MCP result-size cap so the client does not have to spill the result to disk. Keyword search still works against `title` and `contentPreview`. - Need the full objects? Pass `detail="full"`. - Need one task's full content? Use `ticktick_get_by_id`. - **Editing a task:** fetch the full object with `ticktick_get_by_id` first, then send every field back via `ticktick_update_task`. The TickTick API wipes any field omitted from an update, so compact output must never feed an update. If a compact result would still exceed the size budget, the soonest-due tasks are returned and a final `_truncation_note` element reports how many were omitted - nothing is dropped silently. Reach the rest with a narrower `ticktick_filter_tasks` query, `detail="full"`, or `ticktick_get_by_id`. ## Freshness: reads stay current The TickTick account can be edited from the app on other devices while the server runs. To keep reads from going stale, the read tools re-sync server state on demand, throttled to at most once per window (default 15s, override with `TICKTICK_MCP_SYNC_TTL_SECONDS`). A change made elsewhere becomes visible within that window; call `ticktick_sync` to force an immediate refresh and get the current task/project counts. If a sync fails, the last-known state is served rather than erroring - except in `ticktick_get_all`, which refreshes every call and reports the failure instead, since a full dump is the wrong place to serve a stale answer quietly. ## Configuration | Variable | Default | Description | |----------|---------|-------------| | `TICKTICK_MCP_DOTENV_DIR` | `~/.config/ticktick-mcp/` | Directory holding the `.env`, the cached tokens and the completion-tracking database (the `--dotenv-dir` argument takes precedence). The container image sets it to `/data` | | `TICKTICK_MCP_SYNC_TTL_SECONDS` | `15` | Minimum seconds between on-demand read re-syncs | | `TICKTICK_MCP_INIT_RETRY_SECONDS` | `60` | Cooldown before retrying client login after a failed first connection | | `TICKTICK_MCP_RATELIMIT_RETRY_SECONDS` | `300` | Cooldown before retrying login after a rate-limit (HTTP 429); longer than the init cooldown because a 429 clears slowly and each retry prolongs it | | `TICKTICK_MCP_PROTECTED_TASK_IDS` | unset | Task IDs an agent must never modify, separated by spaces or commas. Every mutating tool refuses before sending anything; reads are unaffected. Unset means no protection. | ### Protecting tasks from modification Some tasks should never be changed by an agent, whatever it is asked to do. List their IDs in `TICKTICK_MCP_PROTECTED_TASK_IDS`: ```bash TICKTICK_MCP_PROTECTED_TASK_IDS="60ca9dbc8f08516d9dd56324,60ca9dbc8f08516d9dd56325" ``` `ticktick_update_task`, `ticktick_complete_task`, `ticktick_delete_tasks`, `ticktick_move_task` and `ticktick_make_subtask` then refuse any call naming a protected task, returning `outcome: "protected_task"`. No request that reads or writes the task is sent. A batch delete containing a protected ID is refused in full rather than partially applied, since a partial delete cannot be undone. Because TickTick propagates delete and move through subtasks, `delete`, `move` and `make_subtask` also refuse when a protected task is the parent or the subtask of a task you named. That check refreshes local state first, so it adds one request per delete, move or reparent while protection is configured - and returns `outcome: "protection_unverifiable"` if that refresh fails, since it cannot rule out a protected subtask on a snapshot it could not update. With the variable unset it does no extra work at all. IDs are matched ignoring surrounding whitespace, quotes and case. Reading protected tasks always works. Credentials (`TICKTICK_CLIENT_ID`, `TICKTICK_CLIENT_SECRET`, `TICKTICK_REDIRECT_URI`, `TICKTICK_USERNAME`, `TICKTICK_PASSWORD`) are read from the `.env` file or, if absent, directly from the environment. ## Data safety A pre-commit hook (`scripts/check-no-data.sh`) blocks accidentally committing databases, credentials, and large files - `*.db` and backup variants, everything under `config/` except `.gitkeep` and `*.example*`, and files over 100KB (except `uv.lock`). Install it after cloning: ```bash ln -sf ../../scripts/check-no-data.sh .git/hooks/pre-commit ``` ## Contributing See [CONTRIBUTING.md](CONTRIBUTING.md) for development setup, the test workflow, and the pre-commit hook. Changes are tracked in [CHANGELOG.md](CHANGELOG.md). ## License [GPL-3.0-or-later](LICENSE)