How do I use motion-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@motion-mcp-server show my tasks for today" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

motion-mcp-server

by jonowhyman

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

NPM Version License

Motion MCP Server

Motion is an AI-powered calendar and task management app that auto-schedules your work. This MCP server bridges Motion's API with LLMs like Claude and ChatGPT via the Model Context Protocol, so you can manage tasks, search projects, check your schedule, and more — all through natural conversation. It works on desktop, web, and mobile.

Preview

Click the image above to view full size

Related MCP server: Motion MCP Server

Getting Started

Prerequisites: Node.js 18+ and a Motion API key.

Local Setup (npx)

For desktop MCP clients — Claude Desktop, Claude Code, Cursor, and similar.

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "motion": {
      "command": "npx",
      "args": ["motionmcp"],
      "env": {
        "MOTION_API_KEY": "your_api_key"
      }
    }
  }
}

Test from the command line:

MOTION_API_KEY=your_api_key npx motionmcp

Tip: npx always runs the latest published version — no install needed.

Remote Setup (Cloudflare Workers)

For mobile and web clients — Claude mobile/web, ChatGPT mobile/web, or any HTTP MCP client.

One-click deploy

Deploy to Cloudflare Workers

After deploy, set your secrets in the Cloudflare dashboard (Workers > your worker > Settings > Variables):

MOTION_API_KEY — your Motion API key
MOTION_MCP_SECRET — a random string (generate with openssl rand -hex 16)

Manual deploy

# Set secrets
npx wrangler secret put MOTION_API_KEY
npx wrangler secret put MOTION_MCP_SECRET   # use: openssl rand -hex 16

# Deploy
npm run worker:deploy

Your MCP URL will be:

https://motion-mcp-server.YOUR_SUBDOMAIN.workers.dev/mcp/YOUR_SECRET

Connecting from Claude

Go to claude.ai > Settings > Connectors
Add your MCP URL
The server syncs automatically to the Claude mobile app

Connecting from ChatGPT

Go to ChatGPT Settings > Connectors
Add your MCP URL

Security: The secret in the URL prevents casual discovery. Treat the full URL like a password — don't share it publicly.

Tool configuration works the same as the local server. Set MOTION_MCP_TOOLS in wrangler.toml under [vars], or override via wrangler secret put MOTION_MCP_TOOLS.

For local Worker development, see DEVELOPER.md.

API Key

The server reads your Motion API key from the MOTION_API_KEY environment variable.

Inline (npx):

MOTION_API_KEY=your-key npx motionmcp

.env file (when running from source via npm):

MOTION_API_KEY=your-key

When using npx, prefer the inline environment variable since npx won't read a local .env file.

Tool Configuration

All 10 tools are enabled by default. If you run multiple MCP servers and want to reduce tool selection noise, you can limit which tools are exposed via the MOTION_MCP_TOOLS environment variable:

Level	Tools	Description
minimal	3	Tasks, projects, workspaces only
essential	7	Adds users, search, comments, schedules
complete (default)	10	Full API access including custom fields, recurring tasks, statuses
custom	varies	Pick exactly the tools you need

Custom example:

MOTION_MCP_TOOLS=custom:motion_tasks,motion_projects,motion_search npx motionmcp

Tools Reference

motion_tasks

Operations: create, list, get, update, delete, move, unassign

The primary tool for task management. Supports all Motion API parameters including name, description, priority, dueDate, duration, labels, assigneeId, and autoScheduled. You can reference workspaces and projects by name — the server resolves them automatically.

{
  "operation": "create",
  "name": "Complete API integration",
  "workspaceName": "Development",
  "projectName": "Release Cycle Q2",
  "dueDate": "2025-06-15T09:00:00Z",
  "priority": "HIGH",
  "labels": ["api", "release"]
}

motion_projects

Operations: create, list, get

Manage Motion projects. Workspace and project names are fuzzy-matched, and the server auto-selects your "Personal" workspace if none is specified.

{"operation": "create", "name": "New Project", "workspaceName": "Personal"}

motion_workspaces

Operations: list, get

List and inspect workspaces.

motion_users

Operations: list, current

List users in a workspace or get the current authenticated user.

motion_search

Operations: content

Search tasks and projects by query across a workspace.

{"operation": "content", "query": "API integration", "workspaceName": "Development"}

motion_comments

Operations: list, create

Read and add comments on tasks and projects.

{"operation": "create", "taskId": "task_123", "content": "Updated the API endpoints as discussed"}

motion_schedules

Operations: list

Retrieve user schedules and time zones. Supports prioritized scheduling with conflict detection and workload breakdowns by status, priority, and project.

motion_custom_fields

Operations: list, create, delete, add_to_project, remove_from_project, add_to_task, remove_from_task

Define and manage custom fields across workspaces, projects, and tasks.

{
  "operation": "create",
  "name": "Sprint",
  "type": "DROPDOWN",
  "options": ["Sprint 1", "Sprint 2", "Sprint 3"],
  "workspaceName": "Development"
}

motion_recurring_tasks

Operations: list, create, delete

Manage recurring task templates.

{
  "operation": "create",
  "name": "Weekly Team Standup",
  "recurrence": "WEEKLY",
  "projectName": "Team Meetings",
  "daysOfWeek": ["MONDAY", "WEDNESDAY", "FRIDAY"],
  "duration": 30
}

motion_statuses

Operations: list

List available statuses for a workspace.

Advanced Configuration

Minimal setup (3 tools only):

{
  "mcpServers": {
    "motion": {
      "command": "npx",
      "args": ["motionmcp"],
      "env": {
        "MOTION_API_KEY": "your_api_key",
        "MOTION_MCP_TOOLS": "minimal"
      }
    }
  }
}

Custom tools selection:

{
  "mcpServers": {
    "motion": {
      "command": "npx",
      "args": ["motionmcp"],
      "env": {
        "MOTION_API_KEY": "your_api_key",
        "MOTION_MCP_TOOLS": "custom:motion_tasks,motion_projects,motion_search"
      }
    }
  }
}

Using your local workspace (npm):

{
  "mcpServers": {
    "motion": {
      "command": "npm",
      "args": ["run", "mcp:dev"],
      "cwd": "/absolute/path/to/your/MotionMCP",
      "env": {
        "MOTION_API_KEY": "your_api_key"
      }
    }
  }
}

See the full developer setup in DEVELOPER.md.

Debugging

Logs output to stderr in JSON format
Check for missing keys, workspace/project names, and permissions
Use motion_workspaces (list) and motion_projects (list) to validate IDs

{
  "level": "info",
  "msg": "Task created successfully",
  "method": "createTask",
  "taskId": "task_789",
  "workspace": "Development"
}

License

Apache-2.0 License

For more information, see the full Motion API docs or Model Context Protocol docs.

Available Tools

10 tools

motion_commentsD

Manage comments on tasks

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`taskId`	Yes	Task ID to comment on or fetch comments from (required)
`content`	No	Comment content (required for create operation)
`cursor`	No	Pagination cursor for list operation (optional)

TDQS

D1.7/5.0

Behavior1/5

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

No annotations provided, and the description fails to disclose any behavioral traits such as side effects, permissions, or idempotency.

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

Conciseness2/5

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

The description is too brief and under-specified, lacking necessary details. Conciseness should not come at the expense of informativeness.

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

Completeness1/5

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

Without an output schema, the description should explain return values but does not. It also fails to mention that the tool supports two operations, leaving the agent with insufficient context.

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 input schema has 100% coverage with descriptions for all parameters. The tool description adds no extra meaning beyond the schema, so baseline score is appropriate.

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

Purpose2/5

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

Description 'Manage comments on tasks' is generic and doesn't differentiate from siblings like motion_tasks. It restates the tool name without specifying that it supports list and create operations.

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

Usage Guidelines1/5

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

No guidance on when to use this tool vs alternatives or when not to use it.

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

motion_custom_fieldsA

Manage custom fields for tasks and projects. Required params per operation: list: workspaceId or workspaceName. create: workspaceId/workspaceName + name + field (type); options[] also required for select/multiSelect. delete: workspaceId/workspaceName + fieldId. add_to_project: projectId + fieldId. remove_from_project: projectId + valueId. add_to_task: taskId + fieldId. remove_from_task: taskId + valueId.

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`fieldId`	No	Custom field definition ID. Required for: delete, add_to_project, add_to_task. For remove operations, use valueId instead.
`valueId`	No	Custom field value assignment ID (not the field definition ID). Required for: remove_from_project, remove_from_task.
`workspaceId`	No	Workspace ID. Required for: list, create, delete.
`workspaceName`	No	Workspace name (alternative to workspaceId). Required for: list, create, delete.
`name`	No	Field name. Required for: create.
`field`	No	Field type. Required for: create. Also needed for add_to_project/add_to_task when providing a non-null value.
`options`	No	Option labels. Required for: create when field is select or multiSelect.
`required`	No	Whether field is required on tasks/projects.
`projectId`	No	Project ID. Required for: add_to_project, remove_from_project.
`taskId`	No	Task ID. Required for: add_to_task, remove_from_task.
`value`	No	Field value to set. Optional for add_to_project/add_to_task. When provided and non-null, the field param (type) is also required.

TDQS

A3.8/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It details required parameters but omits consequences like deletion permanence, authentication needs, or effects on related data. The agent cannot infer side effects or safety implications.

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 dense and packs all necessary parameter requirements into a single paragraph. While it lacks visual structure (e.g., bullet points), it is front-loaded with the purpose and remains concise without superfluous words.

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

Completeness3/5

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

Given the complexity (12 parameters, 7 operations) and lack of output schema, the description covers required parameters per operation but not return values, error scenarios, or behavioral nuances like workspace name as alternative to ID. It is adequate but leaves gaps.

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%, providing baseline clarity. The description adds operational context by linking parameters to specific operations and explaining conditions (e.g., field param required when value is non-null). This goes beyond the schema's individual descriptions.

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

Purpose5/5

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

The description clearly states it manages custom fields for tasks and projects, and enumerates seven specific operations. This makes the purpose unambiguous and distinct from sibling tools that deal with other resources.

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?

The description provides per-operation required parameters, guiding the agent on what to include for each action. However, it does not explicitly state when to avoid using this tool or mention alternatives, though no direct alternatives exist among siblings.

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

motion_projectsB

Manage Motion projects - supports create, list, and get operations

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`projectId`	No	Project ID (required for get operation)
`workspaceId`	No	Workspace ID
`workspaceName`	No	Workspace name (alternative to ID)
`name`	No	Project name (required for create)
`description`	No	Project description
`allWorkspaces`	No	List projects from all workspaces (for list operation only). When true and no workspace is specified, returns projects from all workspaces.

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral details. It only states the operations without explaining any side effects, prerequisites, or constraints (e.g., workspace requirement for create, pagination for list).

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, concise sentence with no wasted words. It is front-loaded with the core purpose but lacks structure or detail.

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?

Given 7 parameters and no output schema, the description is too minimal. It fails to explain operational behavior (e.g., what 'get' requires, what 'list' returns) or conditions for each operation.

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 coverage is 100%, so baseline is 3. The description adds no extra meaning to parameters beyond the schema, which already provides adequate descriptions for each field.

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

Purpose5/5

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

The description explicitly states the resource ('Motion projects') and the supported operations ('create, list, and get'). It clearly differentiates from sibling tools like motion_tasks or motion_workspaces.

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?

No guidance is provided on when to use this tool versus alternatives, nor on when to choose each operation (create vs list vs get). The description lacks context for selection.

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

motion_recurring_tasksB

Manage recurring tasks. Required params per operation: list: workspaceId or workspaceName. create: workspaceId/workspaceName + name + assigneeId + frequency (with frequency.type). delete: recurringTaskId.

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`recurringTaskId`	No	Recurring task ID. Required for: delete.
`workspaceId`	No	Workspace ID. Required for: list, create.
`workspaceName`	No	Workspace name (alternative to workspaceId). Required for: list, create.
`name`	No	Task name. Required for: create.
`description`	No	Task description.
`projectId`	No	Project ID.
`assigneeId`	No	User ID to assign the recurring task to. Required for: create.
`frequency`	No	Frequency configuration (required for create)
`deadlineType`	No	Deadline type (default: SOFT)
`duration`	No	Task duration in minutes or REMINDER
`startingOn`	No	Start date (ISO 8601 format)
`idealTime`	No	Ideal time in HH:mm format
`schedule`	No	Schedule name (default: Work Hours)
`priority`	No	Task priority (default: MEDIUM)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations exist, so the description should disclose side effects, auth needs, or destructive behavior. It only states 'Manage recurring tasks' and param requirements, omitting details like whether create/delete are idempotent or what happens on error.

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?

The description is a single sentence with a clear bulleted list per operation. No extraneous words; every sentence provides essential information.

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

Completeness3/5

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

Given 15 parameters and high schema coverage, the description covers operation-specific requirements but lacks return value details (no output schema) and does not mention default behaviors or error handling. It is adequate but not comprehensive.

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?

The input schema has 100% parameter description coverage, but the tool description adds value by explicitly mapping required parameters to each operation, clarifying conditional requirements beyond the schema's 'required' field.

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 clearly states the tool manages recurring tasks and lists required parameters per operation (list, create, delete). It distinguishes from siblings like motion_tasks which handle regular tasks, though it doesn't explicitly contrast them.

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

Usage Guidelines3/5

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

The description provides operation-specific required parameters, which helps within the tool but does not give guidance on when to use this tool versus alternatives like motion_tasks for non-recurring tasks or motion_projects for project management.

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

motion_schedulesA

Get all schedules showing weekly working hours and time zones. The Motion API returns all schedules with no filtering options.

ParametersJSON Schema

Name	Required	Description	Default
`operation`	No	Operation to perform

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It states the operation is read-only and returns all schedules with no filtering, which is adequate for a simple list. However, it does not mention potential issues like pagination or rate limits.

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?

The description is two sentences: the first states the purpose, the second adds a key constraint (no filtering). Every word is useful, and there is no redundancy.

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

Completeness3/5

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

Given no output schema, the description partially describes return data (weekly working hours, time zones) but omits other likely fields (e.g., schedule names, IDs). This is adequate for a simple resource but could be more complete.

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 input schema covers the single 'operation' parameter with 100% description coverage, listing possible values. The description adds no extra detail about the parameter beyond stating no filtering, which is consistent. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'Get', the resource 'schedules', and the data returned ('weekly working hours and time zones'), effectively distinguishing it from sibling tools focused on other Motion resources.

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?

The description explicitly notes that no filtering options are available, implying that this tool is used when all schedules are needed. There are no alternative tools for schedules, so the guidance is clear but lacks explicit when-not-to-use advice.

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

motion_searchC

Search Motion tasks and projects by query

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`query`	No	Search query (required)
`searchScope`	No	What to search (default: both)
`workspaceId`	No	Workspace ID to limit search
`workspaceName`	No	Workspace name (alternative to workspaceId)
`limit`	No	Maximum number of results

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only says 'search' without indicating idempotency, outcome, or side effects. No mention of read-only nature or result behavior.

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 sentence, very concise and to the point. However, it could be expanded with minimal additional context without losing conciseness.

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?

Given no output schema, the description should hint at return format (e.g., list of tasks/projects). It does not address pagination, error handling, or what happens with no results. Incomplete for a search tool with 6 parameters.

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%, so baseline is 3. The description adds no extra meaning beyond the schema. Parameters like operation, query, and searchScope are already described in the 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 clearly states the tool searches tasks and projects by query, which is a specific verb and resource. It distinguishes from sibling tools like motion_tasks and motion_projects by implying a cross-resource search capability, though it does not explicitly differentiate.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., motion_tasks for task-specific queries). The description lacks context about preferred search scenarios or exclusions.

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

motion_statusesB

Get available task/project statuses for a workspace

ParametersJSON Schema

Name	Required	Description	Default
`workspaceId`	No	Workspace ID to get statuses for (optional, returns all statuses if not specified)

TDQS

B3.2/5.0

Behavior2/5

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

The description only indicates a read operation ('Get'), but with no annotations, it fails to disclose any other behavioral traits like scope, permissions, or response structure.

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?

One sentence with no wasted words, front-loaded with the verb and resource.

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?

For a simple tool with one optional parameter and no output schema, the description provides sufficient context to understand its purpose.

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 coverage is 100%, so the description adds little beyond 'available' – the baseline of 3 is appropriate.

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 clearly states it retrieves task/project statuses for a workspace. It is distinct from sibling tools which handle other entities like tasks, projects, or comments.

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?

No guidance on when to use this tool versus alternatives such as motion_tasks or motion_projects, nor any exclusions or prerequisites.

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

motion_tasksC

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

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`taskId`	No	Task ID (required for get/update/delete/move/unassign)
`workspaceId`	No	Filter by workspace (for list)
`workspaceName`	No	Filter by workspace name (for list)
`projectId`	No	Filter by project (for list)
`projectName`	No	Project name (alternative to projectId)
`status`	No	Filter 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.
`includeAllStatuses`	No	When true, returns tasks across all statuses including completed/resolved (for list). Cannot be combined with status filter.
`assigneeId`	No	Filter by assignee (for list/list_all_uncompleted), set assignee (for create/update), or reassign (for move)
`assignee`	No	Filter by assignee name, email, or 'me' shortcut (for list and list_all_uncompleted). Resolved to an ID automatically
`priority`	No	Filter by priority level (for list, filtered client-side): ASAP, HIGH, MEDIUM, LOW
`dueDate`	No	Due date (for create/update) or filter (for list, filtered client-side — returns tasks due on or before this date). Date-only values are stored as end-of-day UTC. Format: YYYY-MM-DD or relative like 'today', 'tomorrow'
`labels`	No	Filter by labels (for list). Array of label names
`name`	No	Task name (required for create, optional for list as case-insensitive substring search)
`description`	No	Task description
`duration`	No	Minutes (as number) or 'NONE'/'REMINDER' (as string)
`autoScheduled`	No	Auto-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.
`targetWorkspaceId`	No	Target workspace ID (required for move operation). Move transfers a task between workspaces — project-level targeting is not supported by the Motion API.
`limit`	No	Maximum number of tasks to return (for list and list_all_uncompleted)

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 description carries the full burden for behavioral disclosure. It only lists operations without explaining side effects (e.g., delete is destructive), permissions, rate limits, or response behavior. This is insufficient for a complex tool.

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 sentence that efficiently enumerates operations. It is concise and free of fluff, though it could benefit from a structured list for clarity.

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?

Given the tool's complexity (19 parameters, multiple operations, no output schema, no annotations), the description is too minimal. It lacks information on return values, potential errors, or usage patterns that an agent would need.

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%, so the baseline is 3. The description adds no parameter-level information beyond what is already in the schema. It does not compensate for any gaps.

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 clearly states it manages Motion tasks and lists the supported operations (create, list, get, etc.). It distinguishes from sibling tools that handle other entities like projects or comments. However, 'manage' is broad and could be more specific.

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?

The description provides no guidance on when to use this tool versus alternatives such as motion_search for searching tasks or motion_statuses for statuses. It does not mention prerequisites or when not to use it.

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

motion_usersC

Manage users and get current user information

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`workspaceId`	No	Workspace ID (optional for list operation, ignored for current)
`workspaceName`	No	Workspace name (alternative to workspaceId, ignored for current)
`teamId`	No	Team ID to filter users by (optional for list operation)

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided. Description says 'manage' which implies write operations, but schema only shows read operations (list, current). This is slightly misleading. No disclosure of auth requirements or other behaviors.

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

Conciseness3/5

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

Single sentence is too vague and does not capture the full functionality. It could be more structured to highlight the two supported operations.

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?

Without output schema and with minimal description, the agent lacks information about expected results or how workspaceId and workspaceName relate. Incomplete for a tool with 4 parameters.

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 coverage is 100%, and the schema provides clear descriptions for each parameter. The description adds no additional meaning beyond the 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?

Description states 'Manage users and get current user information', which clearly indicates user-related operations. However, 'manage' is vague as the schema only supports list and current operations, not full CRUD.

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?

No guidance on when to use this tool versus sibling tools like motion_workspaces or motion_tasks. No alternatives or context provided.

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

motion_workspacesC

Manage Motion workspaces - supports list and get operations

ParametersJSON Schema

Name	Required	Description	Default
`operation`	Yes	Operation to perform
`workspaceId`	No	Workspace ID (required for get operation)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden; it only names operations without disclosing side effects, auth needs, or whether it is read-only.

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?

Single sentence with no wasted words, but could provide slightly more context without becoming verbose.

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?

No output schema, and description does not explain return values, pagination, or constraints; basic but lacks completeness for a list/get tool.

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 coverage is 100%, so description adds no extra meaning beyond parameter names and types; baseline score is appropriate.

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 states the tool manages workspaces with list and get operations, which is specific and distinguishes it from sibling tools for other entities like comments or 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?

No guidance on when to use list vs get or when to prefer this tool over alternatives; usage context is implied but not explicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv2.8.0May 29, 2026
- First observedmotion_comments
- First observedmotion_custom_fields
- First observedmotion_projects
- First observedmotion_recurring_tasks
- First observedmotion_schedules
- First observedmotion_search
- First observedmotion_statuses
- First observedmotion_tasks
- First observedmotion_users
- First observedmotion_workspaces

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct resource (comments, custom fields, projects, recurring tasks, schedules, search, statuses, tasks, users, workspaces). No two tools have overlapping purposes; even 'motion_tasks' and 'motion_recurring_tasks' are clearly separated as general vs. recurring tasks.

Naming Consistency5/5

All tool names follow a consistent 'motion_[resource_plural]' pattern using snake_case. The prefix and plural noun style is uniform across all 10 tools, making the naming predictable and easy to navigate.

Tool Count5/5

With 10 tools covering tasks, projects, users, workspaces, comments, custom fields, recurring tasks, schedules, search, and statuses, the count is well-balanced for a project management API. Each tool serves a clear purpose without being overwhelming or sparse.

Completeness5/5

The tool surface covers all major entities and operations for task management: CRUD for tasks, projects, users, workspaces, comments, and custom fields, plus search, schedules, and status reads. There are no obvious gaps in core workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Astravue MCPOAuth
com.astravue
Manage projects, tasks, time tracking, and team collaboration through natural language.
Project Management Workplace & Productivity
312
DartOAuth
com.dartai
AI-native project management for tasks, docs, collaboration, and agents.
Project Management Workplace & Productivity
1
OrbitOAuth
io.github.Noveum
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
130
CalmLoop Task Manager
in.calmloop
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Project Management Note Taking
1

Related MCP Servers

Motion MCP Server
Project Management Calendar Management Workplace & Productivity
srzh20
A
license
A
quality
D
maintenance
Bridges Motion's API with LLMs so you can manage tasks, search projects, check schedules, and more through natural conversation.
Updated 4 months ago (2026-05-15 21:04 UTC)
10
Apache 2.0
Motion MCP Server
Project Management Calendar Management
vaibuep
A
license
A
quality
B
maintenance
Bridges Motion's API with LLMs like Claude and ChatGPT via the Model Context Protocol, enabling task management, project search, schedule viewing, and more through natural conversation.
Updated 2 months ago (2026-07-09 20:14 UTC)
10
Apache 2.0
Motion MCP Server
Project Management Calendar Management Workplace & Productivity
mattdkonig
A
license
B
quality
C
maintenance
Bridges Motion's API with LLMs via the Model Context Protocol, enabling natural language task, project, and schedule management.
Updated 2 months ago (2026-06-25 02:28 UTC)
10
Apache 2.0
Motion MCP Server
Project Management Calendar Management Workplace & Productivity
rrvdiegor-sketch
A
license
B
quality
C
maintenance
Bridges Motion's API with LLMs via the Model Context Protocol, so you can manage tasks, search projects, check your schedule, and more — all through natural conversation.
Updated 2 months ago (2026-06-30 21:40 UTC)
10
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jonowhyman/motion-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server