Most task-manager integrations implement create, list and complete, which covers the demo and not the work. An agent working through a list will occasionally close the wrong thing, and without a reopen call the correction has to happen somewhere else. The same completeness shows in sections and labels having their own full sets: those are how people actually organise, and an integration that can add a task but not put it in the right section produces an inbox someone has to sort by hand afterwards. Straightforward surface, no surprises, and that is the point.
A Todoist client covering all five object types the service is built from: tasks, projects, sections, labels and comments, each with create, read, update and delete.
- Tasks have a complete lifecycle rather than just create and complete: add, update, get, list with filters, close, reopen and delete — reopen being the one most integrations leave out.
- Projects with their collaborators, so who has access is readable without opening the app.
- Sections as first-class objects, which is what makes a project's internal structure editable rather than only its contents.
- Labels and comments with their own full sets, so the metadata people actually organise by is reachable.
- list_tasks and list_comments both filter, so a query returns the slice you asked for instead of everything.
TODOIST_API_TOKEN.
One command plus a key — npx -y @ganiev/todoist-mcp-server, then supply credentials
