Ticktick Mcp

ticktick-mcp

[CI] [License: GPL v3] [Python 3.13+] [Glama MCP Server]

MCP server for TickTick task management. Create, update, complete, move, and filter tasks through TickTick's Open and v2 APIs, with field-preserving updates, day-of-week date validation, read-after-write verification, and idempotent completion tracking.

Designed for Claude Code and other MCP clients.

Unofficial. Not affiliated with TickTick Ltd. Built on 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, sending its other editable fields back with them
• 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 compare the server's response with what was sent and surface _verification_warnings when it 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, and completions made through this server record themselves

Requirements

• Python 3.13+ (tested on 3.13, 3.14 and 3.15, on Linux, macOS and Windows, in CI)
• uv (recommended - see the install note below)
• A TickTick account
• A registered TickTick app for OAuth credentials (free - developer.ticktick.com)

Install

git clone https://github.com/partymola/ticktick-mcpcd ticktick-mcpuv 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. 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_idTICKTICK_CLIENT_SECRET=your_client_secretTICKTICK_REDIRECT_URI=http://localhost:8080/redirectTICKTICK_USERNAME=your_ticktick_emailTICKTICK_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-mcpchmod 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:

.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 relies on TickTick's unofficial v2 API (via ticktick-py) rather than only 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. Reads, completed lists, delete, move and subtask go through v2, as does removing a reminder. Create, update and complete use the Open API. See 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

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) and the credentials from 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.

.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:

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 fileticktick-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

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.

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.

Three tools confirm the reference before using it rather than passing on one they cannot place. The two completion-tracking tools do it because that value is the key their local database is written under, and an unresolvable one would write a row no later lookup by ID can find. ticktick_filter_tasks does it because it filters locally, so an unknown project would otherwise come back as an empty list, which reads as "no tasks match" rather than "no such project". All three separate the two failures: 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.

In the remaining tools an unrecognised value is passed on unchanged. ticktick_get_tasks_from_project and ticktick_move_task then fail in the client library's own local lookup, before any request is sent; ticktick_create_task, ticktick_update_task and ticktick_delete_tasks send it to TickTick if they use it at all.

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: call ticktick_update_task with the task's ID and only the fields to change. It reads the rest of the task itself. A completed task also needs its projectId.

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 on every projects or tags call and reports the failure instead, since a full dump is the wrong place to serve a stale answer quietly.

Completion tracking: what the queue is for

ticktick_get_unprocessed_completions lists tasks completed in a project that no agent has recorded handling yet, and ticktick_mark_completion_processed records one. The point of the queue is the completion you did not make: a task ticked off in the TickTick app, where the note explaining what happened is waiting to be read.

ticktick_complete_task therefore records its own completions, and reports whether that worked as completion_recorded. The task is complete either way, because the record is written after the API call and a local write that fails is logged rather than turned into an error. You do not need to call ticktick_mark_completion_processed after completing a task through this server; on a task already recorded here it is a no-op.

One case is not covered, by design. Completing a recurring task files the completed instance under a new id, which the completing call never sees, so that instance reaches the queue whoever completed it. Nothing is recorded for a recurring completion in any shape, and completion_recorded is absent from the result rather than false. Do not reach for ticktick_mark_completion_processed on the series id to compensate: that is not the id the queue is showing, so the row clears nothing.

Reopening a task through ticktick_update_task clears the record of its earlier completion, so the next one is surfaced normally: set status: 0 and the record goes. Otherwise one completion made here would keep that task out of the queue permanently, including a later one you tick off in the app with a note attached. A task you reopen in the app instead keeps its record, so a later completion there does stay out of the queue.

The record lives in completion_tracking.db alongside the .env and the token caches.

Configuration

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:

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 *.db files and backup variants, everything under config/ except .gitkeep, *.example and *.example.*, and files over 100KB (except uv.lock). It does not read file contents. Install it after cloning:

ln -sf ../../scripts/check-no-data.sh .git/hooks/pre-commit

Contributing

See CONTRIBUTING.md for development setup, the test workflow, and the pre-commit hook. Changes are tracked in CHANGELOG.md.

License

GPL-3.0-or-later