Skip to main content
Glama
pj2horn

Motion MCP Server

by pj2horn

motion_tasks

Manage Motion tasks through MCP: create, list, get, update, delete, move, unassign, and list all uncompleted tasks with filters for status, due date, assignee, priority, labels, and projects.

Instructions

Manage Motion tasks - supports create, list, get, update, delete, move, unassign, and list_all_uncompleted operations

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoTask name (required for create, optional for list as case-insensitive substring search, filtered client-side)
limitNoMaximum number of tasks to return (for list and list_all_uncompleted)
labelsNoArray of label names. Applied to the task on create/update; filters results on list
statusNoFilter by status (for list). Single string or array of strings (e.g., ["Todo", "Completed"]). Without status or includeAllStatuses, only active (non-resolved) tasks are returned. Use motion_statuses to list valid values per workspace.
taskIdNoTask ID (required for get/update/delete/move/unassign)
dueDateNoDue date (for create/update) or filter (for list and list_all_uncompleted). Format: YYYY-MM-DD, a full ISO 8601 timestamp with offset, or relative like 'today', 'tomorrow'. FILTER (list, list_all_uncompleted): an inclusive upper bound at day granularity in the account timezone — returns every task due ON OR BEFORE that day, which INCLUDES overdue tasks. So dueDate:'today' answers "what's due today?" (including anything overdue) in a single call. There is no exact-date or date-range filter; to show only tasks due exactly on a day, filter the returned results by their Due Date yourself. CREATE/UPDATE: a date-only value is stored as end of day (23:59:59) in the account's schedule timezone when all schedules agree on one, so it renders back as the same calendar day; it falls back to end-of-day UTC when no single zone is resolvable. Pass an explicit ISO timestamp with an offset to control the exact instant. Relative keywords resolve against the same account timezone, falling back to UTC otherwise.
assigneeNoAssignee name, email, or the 'me' shortcut. Resolved to an ID automatically for list, list_all_uncompleted, create, update, and move. A name that cannot be resolved returns an error. Must be non-empty; use the unassign operation to clear a task's assignee.
durationNoMinutes (as number) or 'NONE'/'REMINDER' (as string)
priorityNoTask priority: ASAP, HIGH, MEDIUM, LOW. Set on create/update; filters results on list and list_all_uncompleted (filtered client-side)
operationYesOperation to perform
projectIdNoFilter by project (for list)
assigneeIdNoAssignee user ID, or the 'me' shortcut for the current user. Filters on list/list_all_uncompleted; sets the assignee on create/update; reassigns on move. The 'me' shortcut is resolved to a concrete ID for all of these. Must be non-empty; use the unassign operation to clear a task's assignee.
descriptionNoTask description
projectNameNoProject name (alternative to projectId)
workspaceIdNoFilter by workspace (for list). Ignored by list_all_uncompleted, which always spans every workspace.
autoScheduledNoAuto-scheduling configuration. Can be either: - A schedule name string: "Work Hours" (simple, no start date) - An object for full control: {"schedule": "Work Hours", "startDate": "2025-03-05", "deadlineType": "SOFT"} When the user specifies a start date, you MUST use the object form. Use motion_schedules to see available schedule names.
workspaceNameNoFilter by workspace name (for list). Ignored by list_all_uncompleted, which always spans every workspace.
completedAfterNoFilter (for list): keep only tasks COMPLETED on or after this local calendar date. Format: YYYY-MM-DD or relative like 'today', 'yesterday'. Filtered client-side and auto-includes completed/resolved tasks, so 'what did I get done this week?' is completedAfter set to the week's start date. Combine with completedBefore for a window. Note: this filters on completion date, not due date; a very high-volume window can be capped by pagination (reported in the response), not silently.
completedBeforeNoFilter (for list): keep only tasks COMPLETED on or before this local calendar date. Format: YYYY-MM-DD or relative like 'today'. Filtered client-side; pair with completedAfter to bound a completion window.
targetWorkspaceIdNoTarget workspace ID (required for move operation). Move transfers a task between workspaces — project-level targeting is not supported by the Motion API.
includeAllStatusesNoWhen true, returns tasks across all statuses including completed/resolved (for list). Cannot be combined with status filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.9.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the main description carries the full burden of behavioral disclosure, but it only lists operation names. It does not mention client-side filtering, that list_all_uncompleted spans every workspace, that move is workspace-only, or that delete is destructive. Those details exist in parameter descriptions, but the main description does not provide them.

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?

The description is a single front-loaded sentence with no filler, enumerating the supported operations efficiently. It could be more informative without becoming bloated, but there is no redundancy or wasted wording.

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?

For a 21-parameter, eight-operation tool with no annotations and no output schema, this one-line summary is significantly under-specified. Missing high-level context includes operation-specific behavior, return information, and when to use alternative tools; an agent would need to read every parameter description to use it safely.

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?

The main description adds no parameter-level meaning, but schema description coverage is 100%, so the baseline of 3 applies. All 21 parameters, including operation, status, dueDate, assignee, and autoScheduled, already have detailed explanations in the input schema.

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 names a concrete resource (Motion tasks) and explicitly lists eight operations, so an agent can recognize this as the task-management tool. It is less crisp than a focused verb-plus-scope phrase because 'Manage' is generic, but the operation list clearly distinguishes it from siblings like motion_comments, motion_search, or motion_recurring_tasks.

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 guidance on when to use this tool versus its siblings. The description does not mention alternatives, exclusions, or prerequisites, and it leaves the agent to infer from operation names which request should go here rather than to motion_search, motion_statuses, or motion_recurring_tasks.

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