Skip to main content
Glama
Sign In
Todoist AI MCP Server

Todoist AI MCP Server

Official
by todoist
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

project-move

DestructiveIdempotent

Move a Todoist project between personal and workspace contexts, with optional target workspace, folder, and visibility settings.

Instructions

Move a project between personal and workspace contexts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "projectId": "<projectId>"
    },
    "name": "project-move"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesThe action to perform on the project.
folderIdNoOptional target folder ID within the workspace.
projectIdYesThe ID of the project to move.
visibilityNoOptional access visibility for the project in the workspace (restricted, team, or public).
workspaceIdNoThe target workspace ID. Required when action is move-to-workspace.

Output Schema

NameRequiredDescriptionDefault
projectYesThe moved project.
successYesWhether the move was successful.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv13.10.1
    • changedOutput schema / properties / project / properties / viewStyle / description
      Previous value: -"list, board or calendar."New value: +"list, board, calendar or table."
  2. Changed2 schema fields changedv13.0.0
    • 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"
  3. Changed13 schema fields changedv12.5.3
    • changedOutput schema / properties / project / properties / childOrder / description
      Previous value: -"The ordering index of the project among its siblings."New value: +"Ordering index among siblings."
    • removedOutput schema / properties / project / properties / color / description
      Removed value: -"The color key of the entity."
    • changedOutput schema / properties / project / properties / description / description
      Previous value: -"The description of the project (empty string if none)."New value: +"Empty string when none."
    • changedOutput schema / properties / project / properties / folderId / description
      Previous value: -"The ID of the folder this project belongs to (workspace projects only)."New value: +"Workspace projects only."
    • removedOutput schema / properties / project / properties / id / description
      Removed value: -"The unique ID of the project."
    • removedOutput schema / properties / project / properties / inboxProject / description
      Removed value: -"Whether this is the inbox project."
    • removedOutput schema / properties / project / properties / isArchived / description
      Removed value: -"Whether the project is archived."
    • removedOutput schema / properties / project / properties / isFavorite / description
      Removed value: -"Whether the project is marked as favorite."
    • removedOutput schema / properties / project / properties / isShared / description
      Removed value: -"Whether the project is shared."
    • removedOutput schema / properties / project / properties / name / description
      Removed value: -"The name of the project."
    • removedOutput schema / properties / project / properties / parentId / description
      Removed value: -"The ID of the parent project (for sub-projects)."
    • changedOutput schema / properties / project / properties / viewStyle / description
      Previous value: -"The view style of the project (list, board, calendar)."New value: +"list, board or calendar."
    • changedOutput schema / properties / project / properties / workspaceId / description
      Previous value: -"The ID of the workspace this project belongs to (undefined for personal projects)."New value: +"Undefined for personal projects."
  4. First observedv10.4.2

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds nothing about what destruction means here (loss of sharing, collaborator removal, section/folder effects), what permissions are needed, or whether the move can be undone — the exact context a caller of a destructive mutation needs beyond the flags.

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

Conciseness5/5

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

A single sentence with no filler, and the core action plus its scope is front-loaded. Nothing in it is redundant.

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

Completeness2/5

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

Five parameters with conditional requirements, a destructive hint, and an output schema still leave behavioral questions unanswered: what happens to the project's contents and collaborators when it crosses contexts, and what preconditions must hold. For a destructive move operation, the one-line description is thinner than the tool's complexity warrants.

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

Parameters3/5

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

Schema description coverage is 100%, including conditional semantics ('workspaceId required when action is move-to-workspace') and enum meanings, so the schema does the heavy lifting. The description adds no extra meaning, which is the expected baseline of 3 when coverage is complete.

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?

The description gives a specific verb ('Move') and resource ('project') plus the direction of the move ('between personal and workspace contexts'), which is more informative than a bare name. It doesn't reference siblings such as update-projects or project-management, so an agent can't tell from the text alone why this exists separately from those.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no naming of alternatives like update-projects for renaming/moving a project within a context. The reader must infer from the schema's 'action' enum that this tool is only for crossing the personal/workspace boundary.

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

Deploy Server

Other Tools