Todoist MCP Setup: Connect OAuth and Verify Your Task Scope
Connect Todoist through the official hosted MCP endpoint, authorize the correct account, and verify one known task before allowing changes. The useful milestone is an accurate project-scoped result, not a green connection indicator.
Connect Todoist through the official hosted MCP endpoint, authorize the correct account, and verify one known task before allowing changes. The useful milestone is an accurate project-scoped result, not a green connection indicator.
Table of contents
- Which Todoist server should you connect?
- How do you add the OAuth connection?
- How do you verify the right account and project?
- How should you approve the first write?
- Why do tools disconnect or return the wrong tasks?
- How do you keep the connection useful?
Which Todoist server should you connect?
Use Doist's hosted server when you want Todoist account access without maintaining a local process. Its documented Streamable HTTP address is https://ai.todoist.net/mcp; the official repository also provides a local package, @doist/todoist-mcp. These are two deployment paths, not interchangeable configuration files. Source: Doist repository.
Start by checking the publisher. A search for Todoist MCP returns several community implementations, each with its own authentication, tools, and maintenance history. Their instructions may be perfectly valid for that package while being wrong for the hosted service. The MCPtrove Doist listing helps identify the implementation before you copy anything.
| Your situation | Starting path | Check before proceeding |
|---|---|---|
| Client supports remote OAuth | Hosted endpoint | Correct Todoist account |
| Client accepts only local processes | Documented bridge | Local runtime and OAuth support |
| You need to operate your own server | Official local package | Token storage and network exposure |
Our recommendation is to keep the first connection boring: one account, one client, one project. Adding multiple servers with similar names makes later tool calls harder to attribute.
How do you add the OAuth connection?
Add the hosted URL in your client's remote connector interface, then complete Todoist authorization in the browser. For Claude Desktop, Doist documents Settings → Connectors → Add custom connector. For Claude Code, the documented command is:
claude mcp add --transport http todoist https://ai.todoist.net/mcp
Open Claude Code, use /mcp, and authenticate the Todoist entry. This path does not require putting a personal API token into the command. The official setup guide also covers clients that need a local bridge.
Before approving the browser screen, check which Todoist account is signed in. A work browser session can silently make the wrong account the convenient choice. Complete authorization, return to the client, and confirm that Todoist tools are actually available in the current conversation.
If you use a JSON-based client, check its expected root object and transport fields rather than copying a configuration from another application. The Cursor configuration guide explains that client's file locations. Run structural checks with Config Validator, but remember that valid JSON cannot prove OAuth succeeded or that the account is correct.
How do you verify the right account and project?
Verify identity, project visibility, and a known task in that order. Ask the assistant to inspect the available tool descriptions first, then perform only the reads necessary to find a project you can independently recognize. Tool names and arguments should come from the installed server's current tool list, not a remembered tutorial.
A practical first prompt is: “Identify the connected Todoist account if supported. Find my project named MCP Connection Check and show its existing tasks with their project identifiers. Do not create, update, complete, or delete anything.” Create that temporary project yourself beforehand so there is a known reference.
Compare the response with Todoist's own interface: project, task title, completion state, and due date. Doist publishes its tool implementations, which are the reference when a tool description is unclear. An empty result is not proof of an empty account; a filter may have excluded the task.
For a useful acceptance record, note the date, client, account, project identifier, and whether the known task appeared. Do not record tokens. This small record distinguishes “worked once on my personal account” from “ready for my work project.”
How should you approve the first write?
Approve one disposable task with explicit fields, then inspect the returned task in Todoist. Avoid a first instruction such as “organize my week”: it combines interpretation, scheduling, and potentially many changes before you know what the connection can do.
Instead, ask for a proposed task in your temporary project. Specify its title, project, and whether it should have a due date. Have the assistant show the proposed operation and wait for your approval. After creation, verify the task's identifier and open the task yourself. Delete or complete only that test task when finished.
The Todoist API reference distinguishes task data and operations; the important practical lesson is that reading, updating, and completing are different actions. A successful read does not test the meaning of a write.
Use a two-step pattern for real work: first generate a proposed change list, then approve selected task identifiers. For recurring tasks, make the intended outcome explicit. “Complete this occurrence” and “remove the recurring task” are different user goals. Do not let an assistant infer which one you meant from a vague cleanup request.
Why do tools disconnect or return the wrong tasks?
Diagnose the failing layer before reinstalling anything. A missing server points toward client configuration; a sign-in failure points toward authentication; an unexpected task list points toward account identity or query filters. Those problems need different fixes.
For a disconnected hosted session, use your client's reconnect or sign-in control and verify the account again. If you operate the local package, confirm the runtime launches and that its token is available to that process. The local server documentation describes a loopback HTTP option and warns against exposing it without additional network and authentication controls.
For incorrect task results, compare one task rather than the whole inbox. Check project selection, completed versus active state, date filters, and the time zone used to interpret “today.” Ask the assistant to state the date range it actually queried. Natural language can hide a boundary mistake that becomes obvious when written as dates.
Use Config Doctor for configuration mistakes after removing secrets from anything you share. Do not paste an entire token-bearing file into a support conversation merely because the server stopped connecting.
How do you keep the connection useful?
Save a narrow workflow that starts with reading and ends with a deliberate decision. A daily triage prompt might request overdue tasks from one project, group them by your existing labels, and propose three priorities without changing due dates. You can judge that output before granting any action.
Separate the information you need from the authority the connector has. A prompt that says “read only” is an instruction to the assistant; it is not a newly created permission boundary. Inspect the client tool controls where available, and reconnect or revoke access when the account or device changes.
Doist's server setup documentation explains how hosted and local operation differ. Revisit that distinction when troubleshooting: maintaining a local service introduces responsibilities that hosted OAuth avoids.
A good steady-state setup lets you answer three questions immediately: which account is connected, which project this workflow addresses, and which operations need approval. If any answer is ambiguous, narrow the workflow before increasing automation. The time saved should come from fewer context switches, not from making more unreviewed changes faster.