TickTick is the setup-difficulty outlier here. Most task apps hand you a personal token; TickTick expects a registered OAuth application with a redirect URI, which means people abandon halfway and conclude MCP does not work with TickTick. It does. The friction is one-time.
What the OAuth step actually needs
A registered app in TickTick's developer portal, a client ID and secret, and a redirect URI that matches exactly what you registered — including the trailing slash, or its absence. Nearly every failure at this stage is a redirect URI mismatch, and the error message will not say so.
What lives outside the API
TickTick's habits, Pomodoro sessions and calendar layer are not exposed. If you chose TickTick for habit tracking, MCP will not touch that part, and no server can fix it. Tasks and projects are the whole surface.
Recurring tasks deserve caution
A repeating task is a rule plus a series. Assistants tend to treat the next instance as an ordinary task, and editing it can detach or break the repeat. Keep recurrence changes in the app and let the assistant handle one-off tasks, which is where the speed gain is anyway.
Where LemTask stands today
LemTask does not ship an MCP server yet, and we are not going to pretend otherwise on a page developers will read. What LemTask has working right now is outbound and inbound webhooks, Zapier, Make and Apple Shortcuts, which covers "when a task is created, do X" and "create a task from anything that can send an HTTP request". An MCP connection is on the roadmap; when it ships and we have tested it end to end with Claude, this page will say so with the config block, and not a day earlier.