Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Motion MCP Server create a high priority task to review the Q3 budget due tomorrow"
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 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.
Click the image above to view full size
Related MCP server: Motion MCP Server
Prerequisites: Node.js 18+ and a Motion API key.
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 motionmcpTip:
npxalways runs the latest published version — no install needed.
For mobile and web clients — Claude mobile/web, ChatGPT mobile/web, or any HTTP MCP client.
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)
# 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:deployYour MCP URL will be:
https://motion-mcp-server.YOUR_SUBDOMAIN.workers.dev/mcp/YOUR_SECRETGo to claude.ai > Settings > Connectors
Add your MCP URL
The server syncs automatically to the Claude mobile app
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.
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-keyWhen using
npx, prefer the inline environment variable sincenpxwon't read a local.envfile.
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 motionmcpOperations: 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"]
}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"}Operations: list, get
List and inspect workspaces.
Operations: list, current
List users in a workspace or get the current authenticated user.
Operations: content
Search tasks and projects by query across a workspace.
{"operation": "content", "query": "API integration", "workspaceName": "Development"}Operations: list, create
Read and add comments on tasks and projects.
{"operation": "create", "taskId": "task_123", "content": "Updated the API endpoints as discussed"}Operations: list
Retrieve user schedules and time zones. Supports prioritized scheduling with conflict detection and workload breakdowns by status, priority, and project.
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"
}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
}Operations: list
List available statuses for a workspace.
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.
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"
}Apache-2.0 License
For more information, see the full Motion API docs or Model Context Protocol docs.
Manage comments on tasks
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It merely says 'manage' without specifying that listing retrieves comments and creating adds one, nor any side effects, ordering, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence. However, it sacrifices informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's simplicity, the description should explain return values or pagination behavior. It fails to provide that context, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains parameters. The description adds no additional meaning beyond what the schema provides, achieving baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage comments on tasks', which identifies the resource (comments) and a general verb (manage). However, 'manage' is vague; the tool actually supports list and create operations, but these are not mentioned in the description. It does distinguish from sibling tools like motion_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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) or when to choose list vs create. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains the different parameter requirements per operation, including the distinction between fieldId and valueId, and conditional requirement for options. However, it does not mention side effects or destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph efficiently lists required parameters per operation. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all operations and their required parameters, but lacks details on return values or what each operation actually does beyond parameter requirements. Given no output schema, a bit more detail on behavior would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by summarizing which parameters are required for each operation, which is not captured in the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it manages custom fields for tasks and projects, and lists the specific operations (list, create, delete, add/remove from project/task). This differentiates it from sibling tools like motion_tasks or motion_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies the required parameters for each operation, guiding the agent on when to use each variant. It does not explicitly exclude alternatives, but the context of custom field management is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Motion projects - supports create, list, and get operations
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. The word 'manage' implies mutation, but the description does not specify whether operations are destructive, idempotent, or require permissions. It lacks details beyond the supported operation verbs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose. It avoids unnecessary words, earning a high conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 3 operations, and no output schema, the description is too brief. It does not clarify which parameters apply to which operation, nor does it mention return behavior or edge cases. The tool's complexity demands more explicit documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are described in the schema (100% coverage), so the description adds no new semantic information. It does not explain conditional requirements like projectId for 'get' or name for 'create', but the schema descriptions partially cover that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages Motion projects and supports three specific operations (create, list, get). This distinguishes it from siblings like motion_tasks or motion_workspaces, though it could be more explicit about the CRUD nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. While siblings deal with different entities, the description does not offer context-dependent recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage recurring tasks. Required params per operation: list: workspaceId or workspaceName. create: workspaceId/workspaceName + name + assigneeId + frequency (with frequency.type). delete: recurringTaskId.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions 'manage' and lists required parameters, lacking details on side effects, idempotency, or return behavior (e.g., what list returns, confirmation for create/delete).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences), but the first sentence is vague ('Manage recurring tasks'). The second sentence is a dense list that could be better structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 params, nested frequency object, no output schema), the description is incomplete. It omits output details, frequency configuration specifics beyond required fields, and error handling, leaving the agent without sufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description summarizes required parameter combinations per operation, which adds some value by grouping them, but much of this info is already in the parameter descriptions (e.g., 'Required for: delete').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage recurring tasks' and enumerates the three operations (list, create, delete), giving a clear purpose. However, it does not differentiate from sibling tools like motion_tasks, which may handle non-recurring tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides required parameters for each operation, which offers operational guidance. However, it does not specify when to use this tool versus alternatives (e.g., motion_tasks for one-time tasks) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all schedules showing weekly working hours and time zones. The Motion API returns all schedules with no filtering options.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | No | Operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only implies a read operation and states no filtering, but fails to mention authorization needs, rate limits, or potential side effects (none likely but not stated).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load key information without redundancy. Every word adds value, and the description is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers the core behavior. It could mention return format or pagination, but overall it's sufficiently complete for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'operation' described as 'Operation to perform'. The description adds that there are no filtering options, but this is already evident from the enum. No additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all schedules and specifies the content (weekly working hours, time zones). The verb 'get' and resource 'schedules' are specific, and the tool is distinct from siblings like motion_tasks or motion_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the API returns all schedules with no filtering options, setting expectations for usage. It lacks explicit when-to-use vs when-not-to-use, but the context of 'no filtering' guides appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Motion tasks and projects by query
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It does not state whether the operation is read-only (likely but not confirmed), any authentication requirements, rate limits, or what happens when no results are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description is too minimal. It does not explain return format, pagination behavior, or how the query matches against fields, leaving significant gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters adequately. The description adds no additional semantic meaning beyond what is in the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Search), the resource (Motion tasks and projects), and the method (by query). It effectively distinguishes from sibling tools like motion_tasks and motion_projects that manage entities rather than search across them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like motion_tasks or motion_projects. It does not mention any prerequisites, filtering options, or scenarios where search is preferred over direct retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available task/project statuses for a workspace
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | No | Workspace ID to get statuses for (optional, returns all statuses if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a read operation ('Get'), which is sufficient for this simple retrieval. No mention of side effects or errors, but none are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the tool's purpose without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema). The description is sufficient for an AI to understand its use, though it could mention return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description adds no additional meaning beyond what the schema provides. The baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('available task/project statuses for a workspace'), which is specific and distinguishes it from sibling tools like motion_tasks or motion_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool name and description make its purpose obvious, but there is no explicit guidance on when to use it versus alternatives. However, the sibling tools are all for different entities, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Motion tasks - supports create, list, get, update, delete, move, unassign, and list_all_uncompleted operations
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., auth needs, rate limits, destructive actions). It only lists operations without any additional context, leaving the agent uninformed about side effects, permissions, or other important behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence that introduces the tool and lists its operations. It is front-loaded and efficient, though it could benefit from structuring by operation groups for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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), the description is inadequate. It does not explain return values, pagination, error handling, or how the tool interacts with siblings like motion_statuses or motion_schedules, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters. The description does not add further meaning beyond 'supports create, list, etc.' For high coverage, baseline is 3; the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage Motion tasks' and lists the supported operations (create, list, get, update, etc.), making it clear that this tool handles various task management actions. However, it does not distinguish from sibling tools like motion_recurring_tasks, which also manages tasks but for recurring ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as motion_recurring_tasks for recurring tasks or motion_search for advanced search. The description lacks any context about prerequisites or when each operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage users and get current user information
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. Describing the tool as 'manage' is misleading because the supported operations (list, current) are read-only. No mention of authentication, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but lacks necessary details about the operations and parameter relationships. It is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has multiple operations and four parameters (though only one required), the description is too minimal. It does not explain the difference between list and current, the role of workspaceId vs workspaceName, or return value expectations, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a description in the schema. The tool description adds no extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage users and get current user information' clearly indicates the tool deals with users, and the schema specifies two operations (list and current), so the purpose is well-understood. It distinguishes from sibling tools that handle other entities like tasks or projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_workspaces or motion_search. No context on 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.
Manage Motion workspaces - supports list and get operations
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform | |
| workspaceId | No | Workspace ID (required for get operation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states supported operations but fails to mention that this is a read-only tool (list/get) with no side effects, auth requirements, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. Perfectly concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is minimal. It does not explain what a workspace is, the difference between list and get returns, or any constraints. Could be more helpful to new users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages workspaces with list and get operations, distinguishing it from sibling tools focused on other entities like tasks, projects, etc. However, it could be more specific about what 'list' returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor when to avoid this tool. No alternatives or prerequisites mentioned. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource (e.g., comments, custom fields, projects, tasks, users, workspaces) with clear boundaries. The only potential overlap is between motion_tasks and motion_recurring_tasks, but they are different entities.
All tools follow the convention 'motion_<plural noun>' (e.g., motion_tasks, motion_workspaces). The only exception is motion_search which uses a verb, but it's still consistent with the prefix pattern.
With 10 tools, the server covers the major resources and operations for a project management system without being overwhelming. Each tool serves a clear purpose.
Core task CRUD is well-covered. However, there are missing update operations for projects, recurring tasks, and possibly comments. Overall, the surface is comprehensive for most workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
AI-native project management for tasks, docs, collaboration, and agents.
GDPR-compliant calendar access for AI assistants. Google, Microsoft 365, Apple & more. EU-hosted.
Scheduling infrastructure for AI agents across Google and Microsoft calendars.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markobullrush/motion-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
