Todoist AI MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

find-activity

Read-onlyIdempotent

Retrieve Todoist activity logs to audit task, project, and comment changes. Filter by user, date, event type, or object to track completions and answer what someone finished in a period.

Instructions

Retrieve activity logs to monitor and audit changes in Todoist. Shows events from all users by default (use initiatorId to filter by specific user). To answer what someone completed in a period, including recurring task occurrences, use objectType "task", eventType "completed", and dateFrom/dateTo. For a first-person question ("what did I get done"), also set initiatorId to the current user from user-info, or the answer includes collaborators' completions. Track task completions, updates, deletions, project changes, and more with flexible filtering. Activity history availability and retention depend on the user plan.

Input Schema

Name	Required	Description
`limit`	No	Maximum number of activity events to return.
`cursor`	No	Pagination cursor for retrieving the next page of results.
`dateTo`	No	Exclusive end of the activity range, as an ISO 8601 date or date-time. For all events on 2026-08-02, use "2026-08-03T00:00:00-04:00". Natural-language dates such as "tomorrow" are not supported.
`taskId`	No	Filter events by parent task ID (for subtask events).
`dateFrom`	No	Inclusive start of the activity range, as an ISO 8601 date or date-time. For all events on one local calendar day, use that day's start, for example "2026-08-02T00:00:00-04:00". Natural-language dates such as "tomorrow" are not supported.
`objectId`	No	Filter by specific object ID (task, project, or comment). Requires objectType.
`eventType`	No	Type of event to filter by.
`projectId`	No	Filter events by parent project ID.
`objectType`	No	Type of object to filter by.
`initiatorId`	No	Filter by the user ID who initiated the event. A first-person question ("what did I complete") needs this: without it the results cover every collaborator. Get the ID from user-info when you do not already have it.

Output Schema

Name	Required	Description
`events`	Yes	The activity events.
`hasMore`	Yes
`nextCursor`	No
`totalCount`	Yes	The total number of events in this page.
`appliedFilters`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv13.8.0Oct 29, 2026

changedInput schema / properties / objectId / description

Previous value: -"Filter by specific object ID (task, project, or comment)."New value: +"Filter by specific object ID (task, project, or comment). Requires objectType."

Changed2 schema fields changedv13.6.1Oct 21, 2026

changedInput schema / properties / eventType / enum

Previous value: -[
-  "added",
-  "updated",
-  "deleted",
-  "completed",
-  "uncompleted",
-  "archived",
-  "unarchived",
-  "shared",
-  "left"
-]New value: +[
+  "added",
+  "updated",
+  "deleted",
+  "completed",
+  "uncompleted",
+  "archived",
+  "unarchived",
+  "shared",
+  "left",
+  "moved"
+]

changedInput schema / properties / objectType / enum

Previous value: -[
-  "task",
-  "project",
-  "comment"
-]New value: +[
+  "task",
+  "comment",
+  "project"
+]

Changed2 schema fields changedv13.0.0Aug 20, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedv12.5.6Aug 12, 2026

changedInput schema / properties / initiatorId / description

Previous value: -"Filter by the user ID who initiated the event."New value: +"Filter by the user ID who initiated the event. A first-person question (\"what did I complete\") needs this: without it the results cover every collaborator. Get the ID from user-info when you do not already have it."

Changed12 schema fields changedv12.5.3Aug 7, 2026
- removedOutput schema / properties / appliedFilters / description
```
Removed value: -"The filters that were applied to the search."
```
- changedOutput schema / properties / events / items / properties / eventDate / description
```
Previous value: -"When the event occurred (ISO 8601 format)."New value: +"ISO 8601."
```
- changedOutput schema / properties / events / items / properties / eventType / description
```
Previous value: -"The type of event (added, updated, deleted, completed, etc)."New value: +"added, updated, deleted, completed, etc."
```
- removedOutput schema / properties / events / items / properties / extraData / description
```
Removed value: -"Additional event data."
```
- removedOutput schema / properties / events / items / properties / id / description
```
Removed value: -"The unique ID of the activity event."
```
- changedOutput schema / properties / events / items / properties / initiatorId / description
```
Previous value: -"The ID of the user who initiated this event."New value: +"User who initiated the event."
```
- removedOutput schema / properties / events / items / properties / objectId / description
```
Removed value: -"The ID of the object this event relates to."
```
- changedOutput schema / properties / events / items / properties / objectType / description
```
Previous value: -"The type of object this event relates to (task, project, etc)."New value: +"task, project, etc."
```
- removedOutput schema / properties / events / items / properties / parentItemId / description
```
Removed value: -"The ID of the parent item."
```
- removedOutput schema / properties / events / items / properties / parentProjectId / description
```
Removed value: -"The ID of the parent project."
```
- removedOutput schema / properties / hasMore / description
```
Removed value: -"Whether there are more results available."
```
- removedOutput schema / properties / nextCursor / description
```
Removed value: -"Cursor for the next page of results."
```

Changed2 schema fields changedv12.4.0Aug 4, 2026

addedInput schema / properties / dateFrom

Added value: +{
+  "description": "Inclusive start of the activity range, as an ISO 8601 date or date-time. For all events on one local calendar day, use that day's start, for example \"2026-08-02T00:00:00-04:00\". Natural-language dates such as \"tomorrow\" are not supported.",
+  "type": "string"
+}

addedInput schema / properties / dateTo

Added value: +{
+  "description": "Exclusive end of the activity range, as an ISO 8601 date or date-time. For all events on 2026-08-02, use \"2026-08-03T00:00:00-04:00\". Natural-language dates such as \"tomorrow\" are not supported.",
+  "type": "string"
+}

First observedv10.4.2Jul 9, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds non-obvious behavior the annotations cannot: results span all users unless initiatorId is set, and history availability/retention vary by plan. Useful additions; pagination flow and result volume are left to the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then query recipes, then the caveat — a sensible ordering. The sentence "Track task completions, updates, deletions, project changes, and more with flexible filtering" is largely filler that restates earlier content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% param coverage, the description only needs to supply selection logic and gotchas, which it does (default scope, initiatorId rule, retention). Pagination behavior across the cursor and how large histories are returned is the only notable omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description adds real semantic value on top: the initiatorId/first-person rule, the objectType+eventType combination that answers completion questions, and the default all-users scope. It does not add detail on limit/cursor or the date range semantics beyond what the schema documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ("Retrieve activity logs") plus an explicit purpose (monitor and audit changes in Todoist) and a scope statement (all users by default). It distinguishes its coverage (completions, updates, deletions, project changes) but never names the closest sibling, find-completed-tasks, so an agent must reason about overlap itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Very clear situational routing: objectType "task" + eventType "completed" + dateFrom/dateTo for period-completion questions, and initiatorId for first-person questions, with the failure mode spelled out ("or the answer includes collaborators' completions"). It stops short of naming alternatives or stating when to prefer find-completed-tasks instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.