Many fixes and updates - full native API documentation, bugfixes for many tools, tests and other changes#5
Many fixes and updates - full native API documentation, bugfixes for many tools, tests and other changes#5mjaskolski wants to merge 15 commits into
Conversation
…oject restructuring.
- Added support for testing scripts in package.json. - Integrated status tools into the main API client. - Improved error handling with retry logic for API requests. - Updated various tools to support pagination and enhanced descriptions. - Added new methods for managing work schedules and custom fields. - Refined input schemas for better validation and clarity. - Enhanced project and task management functionalities with custom field support.
- Removed project update and delete functionalities as the Motion API does not support these operations. - Updated documentation to reflect the changes in project management capabilities. - Adjusted the number of registered project tools in tests and README to align with the current API limitations.
… development setup instructions - Changed references from `claude.json` to `claude_desktop_config.json` for clarity. - Added detailed instructions for configuring the development version of the Motion API. - Included a JSON snippet for the `mcpServers` configuration to assist users in setup.
- Updated CLAUDE.md to indicate an increase in tools from 30 to 34 and categories from 8 to 9. - Revised README to adjust the number of task management tools from 8 to 7 and additional tools from 19 to 22, reflecting recent API changes. - Removed the `motion_update_recurring_task` and task completion functionalities from the codebase, streamlining the task management tools. - Updated input schemas to require necessary fields for task creation and management.
- Updated descriptions for `motion_create_recurring_task` and `motion_create_task` to specify the nature of task generation and requirements for due dates. - Clarified input schema descriptions for `dueDate`, `duration`, and `autoScheduled` fields in both task creation and update functionalities to improve user understanding.
- Cleaned up whitespace and formatting in the MotionApiClient class for better readability. - Enhanced descriptions in various tool registrations to ensure consistency and clarity. - Updated task-related tools to include new functionalities for completing and uncompleting tasks, with appropriate input schemas. - Adjusted test cases to reflect changes in task properties and ensure accurate assertions.
- Added logic to filter out the includeAllStatuses parameter when it is set to false in the MotionApiClient's task retrieval method. - Improved handling of request parameters to ensure cleaner API calls.
…CP protocol corruption - Removed console log statements that output retry information when handling rate limits. - Implemented silent retry mechanism to maintain the integrity of the MCP protocol during API request retries.
…nd Claude Code applications - Added sections distinguishing between Claude Desktop and Claude Code, outlining their respective installation methods. - Included detailed steps for configuring the Motion MCP server for both applications. - Enhanced troubleshooting tips for common issues related to API key configuration and application setup.
- Removed the NPX installation step and consolidated it into a manual configuration section. - Updated the instructions to streamline the setup process for users.
WalkthroughThis update introduces comprehensive enhancements across the Motion MCP server codebase and documentation. Major changes include expanded and revised documentation for the official Motion API, new and improved tool implementations with stricter input validation, extended support for pagination and metadata in API responses, and the addition of a robust test suite with utilities and integration tests. The MotionApiClient and type definitions are refactored to support new endpoints, richer data structures, and improved error handling. Several previously unsupported or deprecated operations are removed or replaced, and numerous new features and tools are added, including custom field management, recurring task enhancements, and workspace and status utilities. Changes
Sequence Diagram(s)Example: Custom Field Deletion FlowsequenceDiagram
participant User
participant MCP Tool Handler
participant MotionApiClient
participant Motion API
User->>MCP Tool Handler: Request to delete custom field (workspaceId, customFieldId)
MCP Tool Handler->>MotionApiClient: deleteCustomField(workspaceId, customFieldId)
MotionApiClient->>Motion API: DELETE /beta/workspaces/{workspaceId}/custom-fields/{customFieldId}
Motion API-->>MotionApiClient: 204 No Content
MotionApiClient-->>MCP Tool Handler: Success response
MCP Tool Handler-->>User: { success: true, message: ... }
Example: Task Completion via StatussequenceDiagram
participant User
participant MCP Tool Handler
participant MotionApiClient
participant Motion API
User->>MCP Tool Handler: Complete task (taskId, optional status)
MCP Tool Handler->>MotionApiClient: getTask(taskId)
MotionApiClient->>Motion API: GET /v1/tasks/{id}
Motion API-->>MotionApiClient: Task object
MCP Tool Handler->>MotionApiClient: listStatuses(workspaceId)
MotionApiClient->>Motion API: GET /v1/statuses?workspaceId=...
Motion API-->>MotionApiClient: Status list
MCP Tool Handler->>MotionApiClient: updateTask(taskId, { status: resolvedStatus })
MotionApiClient->>Motion API: PATCH /v1/tasks/{id}
Motion API-->>MotionApiClient: Updated task object
MCP Tool Handler-->>User: Success response
Example: Paginated Listing of CommentssequenceDiagram
participant User
participant MCP Tool Handler
participant MotionApiClient
participant Motion API
User->>MCP Tool Handler: List comments (taskId, optional cursor)
MCP Tool Handler->>MotionApiClient: listComments(taskId, cursor)
MotionApiClient->>Motion API: GET /v1/comments?taskId=...&cursor=...
Motion API-->>MotionApiClient: { comments: [...], meta: {...} }
MotionApiClient-->>MCP Tool Handler: { comments, meta }
MCP Tool Handler-->>User: { comments, meta, count }
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm error Exit handler never called! ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
- Changed the deadlineType field in task registration from optional to mandatory in the input schema. - Ensured consistency in task definitions across the application.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
♻️ Duplicate comments (1)
docs/official_api/projects/README.md (1)
63-69: Same issue as above – adjust the language identifier.Apply the same fix to keep the documentation consistent and pass MD040.
🧹 Nitpick comments (50)
test/run-all.ts (1)
1-55: Well-implemented test runner with proper rate limiting.The sequential test execution with delays is a good approach for API rate limiting. The error handling and logging provide good visibility into test execution. The script correctly continues running tests even if individual tests fail.
Consider making the delay configurable via environment variable for flexibility in different environments:
- // Wait between test files to avoid rate limits - await new Promise(resolve => setTimeout(resolve, 5000)); + // Wait between test files to avoid rate limits + const delay = parseInt(process.env.TEST_DELAY || '5000'); + await new Promise(resolve => setTimeout(resolve, delay));docs/official_api/README.md (4)
7-9: Add language specifier for better syntax highlighting.The base URL code block should specify a language for better rendering and syntax highlighting.
-``` +```url https://api.usemotion.com/v1 -``` +```
11-14: Add language specifier for beta endpoints.The beta endpoints code block should specify a language for consistency.
-``` +```url https://api.usemotion.com/beta -``` +```
20-22: Add language specifier for authentication header.The authentication header code block should specify a language for better rendering.
-``` +```http X-API-Key: YOUR_API_KEY -``` +```
109-112: Add language specifier for date format example.The date format code block should specify a language for consistency.
-``` +```text 2024-01-15T09:00:00Z -``` +```docs/official_api/users/get-current-user.md (1)
21-24: Consider adding security note about API key handling.While the placeholder "YOUR_API_KEY" is appropriate for documentation, consider adding a security note about never exposing actual API keys in code examples or version control.
Consider adding a security note:
### Headers ```http X-API-Key: YOUR_API_KEY+> Security Note: Never expose your actual API key in code examples, logs, or version control. Always use environment variables or secure configuration management.
</blockquote></details> <details> <summary>docs/official_api/tasks/get-task.md (1)</summary><blockquote> `29-32`: **Consider adding security note about API key handling.** Similar to other API documentation, while the placeholder "YOUR_API_KEY" is appropriate, consider adding a security note about proper API key handling practices. Consider adding a security note after the curl example: ```diff curl -X GET https://api.usemotion.com/v1/tasks/550e8400-e29b-41d4-a716-446655440000 \ -H "X-API-Key: YOUR_API_KEY"+> Security Note: Replace
YOUR_API_KEYwith your actual API key stored securely in environment variables. Never expose API keys in code or version control.</blockquote></details> <details> <summary>.cursor/rules/error-handling.mdc (1)</summary><blockquote> `80-82`: **Fix metadata formatting at end of file.** The metadata block at the end should be properly formatted as front matter at the beginning of the file or removed entirely. ```diff -description: Error handling patterns and conventions ----If this is intended as front matter, move it to the top:
+--- +description: Error handling patterns and conventions +--- + # Error Handling Patterns.cursor/rules/mcp-tool-patterns.mdc (1)
79-81: Fix metadata formatting at end of file.Similar to the error handling documentation, the metadata block should be properly formatted as front matter or removed.
-description: MCP tool implementation patterns and conventions ----If this is intended as front matter, move it to the top:
+--- +description: MCP tool implementation patterns and conventions +--- + # MCP Tool Implementation Patternsdocs/official_api/error-handling.md (1)
7-9: Address the missing language specification.The fenced code block should specify a language for proper syntax highlighting.
-``` +```http GET /v1/projects</blockquote></details> <details> <summary>docs/official_api/tasks/delete-task.md (1)</summary><blockquote> `7-9`: **Specify a language identifier for the fenced code block** Markdown-lint flag MD040 is triggered because the endpoint block lacks a language label. Adding `http` (or `txt`) silences the linter and improves syntax highlighting. ```diff -``` +```http DELETE /v1/tasks/{id}docs/official_api/custom-fields/README.md (1)
14-16: Add language identifier to the base-URL code blockUnlabelled blocks violate MD040 and miss out on syntax highlighting.
-``` +```text https://api.usemotion.com/betaCLAUDE.md (1)
7-8: Avoid hard-coding quantitative claims that will drift“implements 34 tools across 9 categories” will become outdated quickly. Consider wording like “implements dozens of tools across multiple categories” or generate the numbers dynamically in build docs.
docs/official_api/custom-fields/remove-from-project.md (1)
7-9: Label the endpoint fence with a languageSame MD040 issue as elsewhere. Recommend:
-``` +```http DELETE /beta/custom-field-values/project/{projectId}/custom-fields/{valueId}docs/official_api/recurring-tasks/create-recurring-task.md (1)
7-9: Add language identifier to fenced endpoint-``` +```http POST /v1/recurring-tasksdocs/official_api/recurring-tasks/README.md (1)
60-64: Optional: clarifystartingOn&idealTimetimezone expectations.These two fields are time-related but the doc doesn’t state whether values must be in UTC, the user’s locale, or ISO-8601 with TZ offset. A short note here avoids ambiguous integrations.
docs/official_api/users/README.md (1)
7-18: Endpoint list is missing the “List users in workspace” route referenced above.The overview bullet “List team members in workspaces” implies an endpoint such as
GET /v1/users?workspaceId=..., but the table only shows/meand/{id}. Either add the missing row or drop the bullet to avoid confusion.docs/official_api/tasks/unassign-task.md (1)
5-10: Add a language identifier to the endpoint code block to satisfy MD040.
markdownlint-cli2flags this fenced block. Recommendhttp(orbash) since it’s a raw request line.-``` +```http DELETE /v1/tasks/{id}/assignee</blockquote></details> <details> <summary>docs/official_api/tasks/list-tasks.md (2)</summary><blockquote> `5-10`: **Specify language on the endpoint block to silence MD040.** ```diff -``` +```http GET /v1/tasks--- `211-233`: **Several mini-request examples lack a language identifier.** Repeating the change above prevents future lint noise and keeps formatting consistent. For example: ```diff -``` +```http GET /v1/tasks?assigneeId=user_123Apply the same tweak to the other short blocks (`status`, `projectId&label`, `name`, `includeAllStatuses`). </blockquote></details> <details> <summary>docs/official_api/recurring-tasks/list-recurring-tasks.md (1)</summary><blockquote> `7-9`: **Add a fenced-code language to satisfy MD040** The opening back-tick fence has no language, which violates our markdown-lint rules and breaks syntax highlighting. ```diff -``` +```http GET /v1/recurring-tasks</blockquote></details> <details> <summary>docs/official_api/custom-fields/list-custom-fields.md (1)</summary><blockquote> `7-9`: **Specify a language for the endpoint fence** Same MD040 issue here – add a language (e.g. `http`). ```diff -``` +```http GET /beta/workspaces/{workspaceId}/custom-fields</blockquote></details> <details> <summary>docs/official_api/users/get-user.md (1)</summary><blockquote> `7-9`: **Missing language identifier on fenced code** Add `http` to the endpoint snippet for lint compliance and nicer rendering. ```diff -``` +```http GET /v1/users/{id}</blockquote></details> <details> <summary>docs/official_api/workspaces/README.md (3)</summary><blockquote> `98-104`: **Code fences under “Common Patterns” need a language** These blocks are plain text lists; add `text` (or `none`) to avoid MD040 warnings. ```diff -``` +```text - Engineering Team (team workspace) - Marketing Team (team workspace) - Sales Team (team workspace)--- `108-112`: **Same as above – include a language spec** ```diff -``` +```text - Q1 2024 Initiatives (team workspace) - Product Launch (team workspace) - Customer Success (team workspace)--- `116-120`: **Final pattern list also missing a language** ```diff -``` +```text - Personal Tasks (individual workspace) - Team Projects (team workspace) - Client Work (team workspace)</blockquote></details> <details> <summary>docs/official_api/custom-fields/delete-custom-field.md (1)</summary><blockquote> `7-9`: **Fix markdown formatting for code block language specification.** The fenced code block is missing a language specification, which improves syntax highlighting and readability. ```diff -``` +```http DELETE /beta/workspaces/{workspaceId}/custom-fields/{id}</blockquote></details> <details> <summary>docs/official_api/workspaces/list-workspaces.md (1)</summary><blockquote> `7-9`: **Fix markdown formatting for code block language specification.** The fenced code block is missing a language specification. ```diff -``` +```http GET /v1/workspaces</blockquote></details> <details> <summary>docs/official_api/schedules/get-schedules.md (1)</summary><blockquote> `7-9`: **Fix markdown formatting for code block language specification.** The fenced code block is missing a language specification. ```diff -``` +```http GET /v1/schedules</blockquote></details> <details> <summary>docs/official_api/custom-fields/add-to-project.md (2)</summary><blockquote> `7-9`: **Fix markdown formatting - specify language for code block.** The fenced code block should have a language identifier for proper syntax highlighting. ```diff -``` -POST /beta/custom-field-values/project/{projectId} -``` +```http +POST /beta/custom-field-values/project/{projectId} +```
23-25: Fix markdown formatting - specify language for code block.The fenced code block should have a language identifier.
-```http -X-API-Key: YOUR_API_KEY -Content-Type: application/json -``` +```http +X-API-Key: YOUR_API_KEY +Content-Type: application/json +```docs/official_api/comments/get-comments.md (1)
7-9: Fix markdown formatting - specify language for code block.The fenced code block should have a language identifier.
-``` -GET /v1/comments -``` +```http +GET /v1/comments +```docs/official_api/projects/get-project.md (1)
7-9: Fix markdown formatting - specify language for code block.The fenced code block should have a language identifier.
-``` -GET /v1/projects/{id} -``` +```http +GET /v1/projects/{id} +```docs/official_api/tasks/update-task.md (1)
7-9: Fix markdown formatting - specify language for code block.The fenced code block should have a language identifier.
-``` -PATCH /v1/tasks/{id} -``` +```http +PATCH /v1/tasks/{id} +```docs/official_api/tasks/create-task.md (1)
7-9: Add language specification to fenced code block.The fenced code block should specify the language for better syntax highlighting and clarity.
-``` +```http POST /v1/tasks</blockquote></details> <details> <summary>docs/official_api/custom-fields/remove-from-task.md (1)</summary><blockquote> `7-9`: **Add language specification to fenced code block.** The fenced code block should specify the language for better syntax highlighting and clarity. ```diff -``` +```http DELETE /beta/custom-field-values/task/{taskId}/custom-fields/{valueId}</blockquote></details> <details> <summary>test/utils.ts (1)</summary><blockquote> `5-9`: **Consider improving type safety for better development experience.** The `args` parameter and `validate` function use `any` type, which reduces type safety. Consider using generic types or more specific types. ```diff -export async function testTool( - tool: Tool, - args: any, - validate?: (result: any) => void -): Promise<any> { +export async function testTool<T = unknown, R = unknown>( + tool: Tool, + args: T, + validate?: (result: R) => void +): Promise<R> {docs/official_api/recurring-tasks/delete-recurring-task.md (1)
7-9: Add language specification to fenced code block.The fenced code block should specify the language for better syntax highlighting and clarity.
-``` +```http DELETE /v1/recurring-tasks/{id}</blockquote></details> <details> <summary>docs/official_api/projects/create-project.md (1)</summary><blockquote> `7-9`: **Specify a language for the fenced block.** Markdown-lint flag MD040 is triggered here. Declare the block as `http` (or `bash` if you prefer the cURL form elsewhere) to improve syntax highlighting and silence the linter. ```diff -``` +```http POST /v1/projects -``` +```docs/official_api/projects/README.md (1)
50-58: Incorrect code-block language – usehttporjson, notjavascript.The snippet contains an HTTP request payload, not valid JavaScript.
Labeling it asjavascripthurts readability and may mislead copy-paste linting tools.-```javascript +```http POST /v1/projects { "name": "Sprint 24 - User Authentication", ... } -``` +```docs/official_api/tasks/move-task.md (1)
7-9: Add a language identifier to the endpoint block.This three-tick block is missing a language tag, tripping MD040.
-``` +```http PATCH /v1/tasks/{id}/move -``` +```.cursor/rules/api-client-patterns.mdc (1)
78-80: Trailing stray text looks accidental.The “description: …” line (78) seems like YAML front-matter or meta that slipped into the rendered Markdown.
Unless your renderer consumes it, consider deleting or moving it to actual front-matter.docs/official_api/custom-fields/add-to-task.md (1)
7-9: Missing language specifier for fenced block.Add
httpto silence markdown-lint and improve syntax highlighting.-``` +```http POST /beta/custom-field-values/task/{taskId} -``` +```docs/official_api/statuses/list-statuses.md (1)
7-9: Add language specification to fenced code block.The fenced code block should specify
httpas the language for proper syntax highlighting.-``` +```http GET /v1/statuses</blockquote></details> <details> <summary>docs/official_api/comments/create-comment.md (1)</summary><blockquote> `7-9`: **Add language specification to fenced code block.** The fenced code block should specify `http` as the language for proper syntax highlighting. ```diff -``` +```http POST /v1/comments</blockquote></details> <details> <summary>docs/official_api/custom-fields/create-custom-field.md (1)</summary><blockquote> `7-9`: **Add language specification to fenced code block.** The fenced code block should specify `http` as the language for proper syntax highlighting. ```diff -``` +```http POST /beta/workspaces/{workspaceId}/custom-fields</blockquote></details> <details> <summary>src/tools/task.ts (1)</summary><blockquote> `317-356`: **Status-based completion logic is well-implemented!** The transition from boolean `completed` flag to status-based completion aligns with the Motion API's model. The fallback logic to find a resolved status is appropriate. Consider caching workspace statuses to reduce API calls when completing multiple tasks in the same workspace. </blockquote></details> <details> <summary>src/api/client.ts (1)</summary><blockquote> `134-143`: **Pragmatic workaround for missing workspace endpoint.** The implementation correctly works around the API limitation by fetching all workspaces and filtering. This could be inefficient with many workspaces. Consider monitoring performance and requesting a direct endpoint from the Motion API team if this becomes a bottleneck. </blockquote></details> <details> <summary>docs/official_api/statuses/README.md (2)</summary><blockquote> `15-17`: **Document the `workspaceId` query param on the only endpoint.** The table suggests that `/v1/statuses` is a single, unfiltered list, yet the surrounding PR description (and the `motion_list_statuses` tool) support an optional `workspaceId` filter. Callers will look here first—spell it out. ```diff -| GET | `/v1/statuses` | [List available statuses](./list-statuses.md) | +| GET | `/v1/statuses` | [List available statuses](./list-statuses.md)<br/> + • Optional `workspaceId` query param to limit results |
22-26: Exposeid(and optionallyworkspaceId) in the Status object.Every status coming back from the API carries at least its stable identifier, and many SDK consumers rely on it. Omitting it here forces readers to guess or dig into the SDK.
{ - name: string, // Status display name - isDefaultStatus: boolean, // Whether this is the default for new items - isResolvedStatus: boolean // Whether this indicates completion + id: string, // Stable unique identifier + name: string, // Display name + isDefaultStatus: boolean, // `true` ⇒ default for new items + isResolvedStatus: boolean, // `true` ⇒ marks completion + workspaceId?: string // Present when result is scoped }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (73)
.cursor/rules/api-client-patterns.mdc(1 hunks).cursor/rules/data-validation.mdc(1 hunks).cursor/rules/development-workflow.mdc(1 hunks).cursor/rules/error-handling.mdc(1 hunks).cursor/rules/mcp-tool-patterns.mdc(1 hunks).cursor/rules/project-structure.mdc(1 hunks).cursor/rules/typescript-conventions.mdc(1 hunks).gitignore(0 hunks)CLAUDE.md(1 hunks)README.md(7 hunks)docs/MOTION_PROJECT_LIMITATIONS.md(1 hunks)docs/official_api/README.md(1 hunks)docs/official_api/authentication.md(1 hunks)docs/official_api/comments/README.md(1 hunks)docs/official_api/comments/create-comment.md(1 hunks)docs/official_api/comments/get-comments.md(1 hunks)docs/official_api/custom-fields/README.md(1 hunks)docs/official_api/custom-fields/add-to-project.md(1 hunks)docs/official_api/custom-fields/add-to-task.md(1 hunks)docs/official_api/custom-fields/create-custom-field.md(1 hunks)docs/official_api/custom-fields/delete-custom-field.md(1 hunks)docs/official_api/custom-fields/list-custom-fields.md(1 hunks)docs/official_api/custom-fields/remove-from-project.md(1 hunks)docs/official_api/custom-fields/remove-from-task.md(1 hunks)docs/official_api/data-types.md(1 hunks)docs/official_api/error-handling.md(1 hunks)docs/official_api/projects/README.md(1 hunks)docs/official_api/projects/create-project.md(1 hunks)docs/official_api/projects/get-project.md(1 hunks)docs/official_api/projects/list-projects.md(1 hunks)docs/official_api/recurring-tasks/README.md(1 hunks)docs/official_api/recurring-tasks/create-recurring-task.md(1 hunks)docs/official_api/recurring-tasks/delete-recurring-task.md(1 hunks)docs/official_api/recurring-tasks/list-recurring-tasks.md(1 hunks)docs/official_api/schedules/README.md(1 hunks)docs/official_api/schedules/get-schedules.md(1 hunks)docs/official_api/statuses/README.md(1 hunks)docs/official_api/statuses/list-statuses.md(1 hunks)docs/official_api/tasks/README.md(1 hunks)docs/official_api/tasks/create-task.md(1 hunks)docs/official_api/tasks/delete-task.md(1 hunks)docs/official_api/tasks/get-task.md(1 hunks)docs/official_api/tasks/list-tasks.md(1 hunks)docs/official_api/tasks/move-task.md(1 hunks)docs/official_api/tasks/unassign-task.md(1 hunks)docs/official_api/tasks/update-task.md(1 hunks)docs/official_api/users/README.md(1 hunks)docs/official_api/users/get-current-user.md(1 hunks)docs/official_api/users/get-user.md(1 hunks)docs/official_api/workspaces/README.md(1 hunks)docs/official_api/workspaces/list-workspaces.md(1 hunks)package.json(2 hunks)src/api/client.ts(12 hunks)src/index.ts(2 hunks)src/tools/comment.ts(1 hunks)src/tools/customField.ts(5 hunks)src/tools/project.ts(3 hunks)src/tools/recurringTask.ts(2 hunks)src/tools/schedule.ts(2 hunks)src/tools/status.ts(1 hunks)src/tools/task.ts(8 hunks)src/tools/user.ts(1 hunks)src/tools/workspace.ts(1 hunks)src/types/motion.ts(6 hunks)test/README.md(1 hunks)test/run-all.ts(1 hunks)test/setup.ts(1 hunks)test/tools/project.test.ts(1 hunks)test/tools/schedule-status.test.ts(1 hunks)test/tools/task.test.ts(1 hunks)test/tools/user.test.ts(1 hunks)test/tools/workspace.test.ts(1 hunks)test/utils.ts(1 hunks)
💤 Files with no reviewable changes (1)
- .gitignore
🧰 Additional context used
🧬 Code Graph Analysis (10)
src/index.ts (1)
src/tools/status.ts (1)
registerStatusTools(5-32)
src/tools/status.ts (2)
src/api/client.ts (1)
MotionApiClient(22-423)src/types/tool.ts (1)
Tool(1-11)
test/tools/workspace.test.ts (3)
src/tools/workspace.ts (1)
registerWorkspaceTools(5-62)test/setup.ts (3)
testClient(10-14)TEST_WORKSPACE_NAME(16-16)setupTestWorkspace(23-32)test/utils.ts (4)
createTestContext(54-65)testTool(5-24)assertHasProperty(26-28)assertIsArray(30-32)
test/tools/task.test.ts (3)
src/tools/task.ts (1)
registerTaskTools(6-405)test/setup.ts (3)
testClient(10-14)generateTestId(44-46)setupTestWorkspace(23-32)test/utils.ts (5)
createTestContext(54-65)testTool(5-24)assertHasProperty(26-28)assertIsArray(30-32)waitForApiLimit(50-52)
test/tools/schedule-status.test.ts (4)
test/setup.ts (2)
setupTestWorkspace(23-32)testClient(10-14)src/tools/schedule.ts (1)
registerScheduleTools(5-59)test/utils.ts (4)
createTestContext(54-65)testTool(5-24)assertHasProperty(26-28)assertIsArray(30-32)src/tools/status.ts (1)
registerStatusTools(5-32)
test/setup.ts (1)
src/api/client.ts (1)
MotionApiClient(22-423)
src/tools/task.ts (1)
src/types/motion.ts (1)
MotionStatus(71-75)
test/tools/project.test.ts (3)
src/tools/project.ts (1)
registerProjectTools(5-90)test/setup.ts (3)
testClient(10-14)generateTestId(44-46)setupTestWorkspace(23-32)test/utils.ts (5)
createTestContext(54-65)testTool(5-24)assertHasProperty(26-28)assertIsArray(30-32)waitForApiLimit(50-52)
test/utils.ts (1)
src/types/tool.ts (1)
Tool(1-11)
src/api/client.ts (1)
src/types/motion.ts (10)
MotionListResponse(178-184)MotionWorkspace(61-69)MotionTask(7-48)MotionProject(50-59)MotionUser(77-81)MotionWorkSchedule(98-111)MotionComment(83-90)MotionCustomField(113-139)MotionRecurringTask(155-176)MotionStatus(71-75)
🪛 Gitleaks (8.27.2)
docs/official_api/custom-fields/remove-from-project.md
31-32: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/recurring-tasks/create-recurring-task.md
49-50: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/tasks/get-task.md
47-48: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/users/get-current-user.md
22-23: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/tasks/create-task.md
47-48: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/custom-fields/delete-custom-field.md
30-31: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/recurring-tasks/delete-recurring-task.md
30-31: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/projects/create-project.md
29-30: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
33-34: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/custom-fields/list-custom-fields.md
30-31: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/recurring-tasks/list-recurring-tasks.md
30-31: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
34-35: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/tasks/delete-task.md
30-31: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/custom-fields/add-to-task.md
44-45: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/statuses/list-statuses.md
29-30: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
33-34: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/tasks/move-task.md
38-39: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/custom-fields/create-custom-field.md
54-55: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/authentication.md
23-24: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/comments/get-comments.md
29-30: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
36-37: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/workspaces/list-workspaces.md
30-31: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
34-35: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
38-39: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/tasks/update-task.md
49-50: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
docs/official_api/comments/create-comment.md
30-31: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
🪛 markdownlint-cli2 (0.17.2)
docs/official_api/custom-fields/remove-from-project.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/custom-fields/README.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
12-12: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
20-20: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
110-110: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/tasks/get-task.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/users/get-current-user.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/tasks/create-task.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/custom-fields/delete-custom-field.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/users/get-user.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/recurring-tasks/delete-recurring-task.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/projects/create-project.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/projects/get-project.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/custom-fields/list-custom-fields.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/recurring-tasks/list-recurring-tasks.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/custom-fields/remove-from-task.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/README.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
12-12: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
20-20: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
110-110: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/tasks/delete-task.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/tasks/list-tasks.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/tasks/unassign-task.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/statuses/list-statuses.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/tasks/move-task.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/projects/list-projects.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/custom-fields/create-custom-field.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/comments/get-comments.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/workspaces/list-workspaces.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/comments/create-comment.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/official_api/custom-fields/add-to-project.md
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
12-12: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
20-20: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
110-110: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🪛 LanguageTool
docs/official_api/users/get-current-user.md
[style] ~252-~252: It’s more common nowadays to write this noun as one word.
Context: ...ds - id: Unique identifier for the user - name: User's display name - email: Use...
(RECOMMENDED_COMPOUNDS)
🪛 Biome (1.9.4)
src/api/client.ts
[error] 159-159: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
🔇 Additional comments (116)
.cursor/rules/typescript-conventions.mdc (1)
1-41: Well-structured TypeScript conventions documentation.The conventions are comprehensive and follow modern TypeScript best practices. The examples are clear and actionable.
src/index.ts (2)
20-20: LGTM: Import follows established conventions.The import statement correctly follows the project's pattern for tool registration imports.
48-48: LGTM: Tool registration follows established pattern.The status tools are properly registered alongside other tools using the spread operator, maintaining consistency with the existing codebase.
test/README.md (1)
1-40: Comprehensive test documentation.The README provides clear setup instructions, test structure overview, and important warnings about real API usage. This will help developers understand the testing approach and requirements.
src/tools/status.ts (2)
1-4: LGTM: Imports follow established conventions.The imports correctly use explicit
.jsextensions and follow the documented TypeScript conventions.
5-32: LGTM: Tool implementation follows established patterns.The tool implementation correctly:
- Follows the
register*Tools()function pattern- Uses the
motion_prefix for tool names- Implements proper input schema validation
- Uses Zod for runtime validation
- Returns results in a consistent format
The implementation aligns with the conventions documented in
.cursor/rules/typescript-conventions.mdc.src/tools/user.ts (3)
40-40: LGTM: Description accurately reflects required parameter.The description correctly indicates that the tool lists users in a workspace, implying the workspace requirement.
44-46: LGTM: Input schema correctly enforces required workspaceId.The schema properly:
- Updates the description to indicate the parameter is required
- Moves
workspaceIdto the required array- Maintains consistent parameter structure
50-50: LGTM: Zod validation ensures non-empty workspaceId.The validation schema correctly requires a non-empty string for
workspaceId, which prevents empty string inputs that could cause API errors..cursor/rules/project-structure.mdc (1)
1-33: Excellent project structure documentation.This comprehensive documentation file provides a clear and well-organized overview of the Motion MCP project architecture. The structure covers all essential components including entry points, configuration, API client, types, and tool organization. The file references and dependency listings will be valuable for developer onboarding.
package.json (1)
31-33: Good addition of testing scripts.The new test scripts provide both single-run and watch modes for testing. The syntax fix for the format script JSON is also correct.
src/tools/schedule.ts (2)
8-9: Improved tool naming and description.The rename from
motion_get_scheduletomotion_get_scheduled_tasksprovides better clarity about the tool's purpose. The updated description is more specific and helpful.
41-57: Well-implemented new work schedules tool.The new
motion_get_work_schedulestool follows the established patterns and provides a clean interface for retrieving work schedule information. The implementation is consistent with other tools in the codebase.src/tools/comment.ts (1)
9-31: Excellent implementation of cursor-based pagination.The addition of cursor-based pagination to the comment listing tool is well-implemented. The changes maintain backward compatibility by making the cursor optional, and the response structure properly includes pagination metadata. The validation schema is correctly updated to handle the new parameter.
docs/official_api/authentication.md (3)
23-24: Documentation example with placeholder API key is appropriate.The static analysis tool flagged this as a potential security issue, but this is a false positive. The curl command correctly uses placeholder text "YOUR_API_KEY_HERE" which is standard practice in API documentation to show users where to insert their actual API key.
27-33: Excellent security best practices section.The security guidelines are comprehensive and follow industry standards for API key management. The emphasis on environment variables, key rotation, and access restriction will help prevent common security issues.
34-41: Clear rate limit documentation.The rate limits are clearly documented with specific values for different account types. The mention of HTTP 429 responses aligns with the error handling patterns described in the codebase.
src/tools/workspace.ts (3)
9-22: Well-implemented pagination and filtering support.The enhanced input schema appropriately supports optional cursor-based pagination and workspace ID filtering. The schema design aligns with the API patterns documented in the official API documentation.
23-37: Proper validation and structured response handling.The handler correctly validates input using Zod schemas and returns a structured response with workspaces, meta, and count properties. This follows the pagination patterns described in the API documentation.
54-54: Improved validation prevents empty workspace IDs.The addition of
.min(1)validation ensures that empty workspace IDs are rejected, preventing potential API errors. This is a good defensive programming practice.docs/official_api/README.md (1)
31-90: Excellent API resource organization.The categorization into Core Resources, User & Workspace Resources, and Beta Features provides a logical structure that aligns well with the tool implementations in the codebase. The comprehensive linking to detailed documentation files creates a good navigation experience.
docs/MOTION_PROJECT_LIMITATIONS.md (3)
1-20: Clear documentation of critical API limitations.This documentation provides essential information about project management constraints in the Motion API. The clear structure and explicit statements about read-only behavior and inability to delete projects will prevent developers from attempting unsupported operations.
21-30: Valuable test results provide concrete evidence.The documented test results with specific HTTP methods and error codes provide concrete evidence of the API limitations. This empirical data helps developers understand exactly what fails and why.
31-44: Helpful implications and comparison sections.The implications section provides actionable guidance for developers, and the comparison with tasks helps set expectations about what operations are supported for different resources. This context is valuable for planning development work.
test/tools/user.test.ts (4)
12-17: Good test coverage for tool registration.The test verifies that all 3 user tools are registered with the correct names, ensuring the tool registration function works as expected.
19-33: Comprehensive testing of current user functionality.The test validates the structure and data types of the current user response, ensuring all required properties are present and properly typed. The use of assertion helpers provides consistent validation patterns.
35-55: Proper validation testing for user ID parameter.The tests verify that the userId parameter is both required and non-empty, ensuring proper input validation. Testing both missing and empty string cases provides thorough coverage.
57-81: Thorough testing of user listing functionality.The test validates the list users functionality including the required workspaceId parameter and proper response structure. The workspace setup and validation tests ensure the tool works correctly with proper inputs and fails appropriately with invalid inputs.
.cursor/rules/data-validation.mdc (1)
1-125: Excellent comprehensive data validation documentation!This documentation provides a thorough and well-structured guide for implementing Zod validation patterns. The examples are accurate, practical, and cover all essential use cases including basic types, Motion-specific patterns, complex objects, and schema reuse. The workflow section clearly explains the validation process and error handling approach.
docs/official_api/users/get-current-user.md (1)
55-249: Excellent API documentation with comprehensive examples!The documentation provides thorough coverage of the endpoint with practical JavaScript and Python examples, multiple use cases, and clear response format specifications. The code examples demonstrate proper error handling and practical usage patterns.
.cursor/rules/development-workflow.mdc (1)
1-88: Comprehensive development workflow documentation!This documentation provides excellent coverage of the development process including scripts, environment setup, testing procedures, code quality standards, and debugging guidance. The structure is logical and practical for developers contributing to the project.
test/tools/task.test.ts (1)
1-184: Excellent comprehensive test suite for task tools!This test file demonstrates excellent testing practices with:
- Complete coverage of all 9 task tools
- Proper async/await usage and error handling
- Validation testing for required fields
- Rate limiting considerations with
waitForApiLimit()- Clean setup/teardown with workspace management
- Good use of test utilities and helper functions
The test structure is well-organized and follows best practices for integration testing.
docs/official_api/tasks/get-task.md (1)
40-230: Outstanding API documentation with comprehensive response schema!This documentation provides exceptional detail with:
- Complete response schema including all nested objects
- Practical JavaScript and Python examples with error handling
- Clear parameter specifications and error responses
- Helpful notes about task relationships and custom fields
The response schema is particularly well-documented, showing the full structure of task objects with all relationships.
.cursor/rules/error-handling.mdc (1)
1-79: LGTM! Comprehensive error handling documentation.The error handling patterns are well-documented with clear examples covering MCP errors, API client errors, validation, configuration, and server-level error handling. The best practices section provides valuable guidance for consistent error management.
docs/official_api/data-types.md (1)
1-104: LGTM! Comprehensive data types documentation.The documentation provides excellent coverage of Motion API data types with clear examples and proper TypeScript type definitions. The discriminated union pattern for CustomFieldValue is well-defined and the datetime format specifications are helpful.
.cursor/rules/mcp-tool-patterns.mdc (1)
1-78: LGTM! Excellent MCP tool patterns documentation.The documentation provides comprehensive guidance for MCP tool development with clear naming conventions, input schema best practices, and implementation patterns. The example pattern and registration approach are well-illustrated.
docs/official_api/schedules/README.md (1)
1-108: LGTM! Excellent Schedules API documentation.The documentation provides comprehensive coverage of the Schedules API with clear object schemas, practical use cases, and helpful examples. The explanation of how Motion uses schedules for task scheduling is particularly valuable.
test/tools/workspace.test.ts (1)
1-82: LGTM! Comprehensive workspace tools test suite.The test suite provides excellent coverage for both workspace tools with proper validation tests, error handling checks, and response validation. The use of helper functions from the test utilities makes the tests clean and maintainable.
test/tools/schedule-status.test.ts (2)
29-41: Excellent test structure and validation.The test properly validates both the structure of the response and the presence of required properties. The use of date generation for dynamic test data is well-implemented.
68-75: Good comprehensive validation for status listing.The test properly validates the response structure and includes a meaningful assertion that at least one status should exist, which is a reasonable expectation for any Motion workspace.
docs/official_api/error-handling.md (3)
62-98: Excellent comprehensive error handling example.The JavaScript error handling example demonstrates proper patterns including status-specific error handling, error context preservation, and proper error propagation.
104-119: Well-implemented retry mechanism with exponential backoff.The retry function demonstrates proper exponential backoff implementation and handles rate limiting gracefully. The implementation correctly distinguishes between retryable and non-retryable errors.
121-127: Comprehensive and practical best practices.The best practices section covers all essential aspects of robust API error handling, providing actionable guidance for developers.
test/setup.ts (4)
6-8: Good environment validation.Proper validation of required environment variables with a clear error message helps prevent configuration issues during test runs.
10-14: Appropriate test client configuration.The conservative rate limit of 10 requests per minute for tests is sensible to avoid hitting API limits during test execution.
23-32: Robust workspace setup with clear error handling.The function properly finds the test workspace and provides a clear error message if not found, which helps with test environment setup.
44-46: Excellent unique ID generation.The combination of timestamp and random string ensures uniqueness across test runs and concurrent executions.
docs/official_api/projects/list-projects.md (6)
1-10: Clear and comprehensive endpoint documentation.The endpoint documentation provides clear information about the API endpoint and its purpose.
43-102: Excellent detailed response examples.The response examples provide comprehensive coverage of different project states and custom field configurations, which helps developers understand the API's capabilities.
142-173: Well-structured JavaScript example with proper error handling.The JavaScript example demonstrates proper URL construction, error handling, and API response processing. The example is practical and ready-to-use.
177-205: Comprehensive Python example.The Python example follows similar patterns to the JavaScript version and includes proper error handling with
raise_for_status().
207-268: Valuable practical examples for common use cases.The additional examples for filtering active projects, grouping by status, and handling custom fields provide practical value for developers implementing common workflows.
289-303: Practical best practices and important notes.The best practices section provides actionable guidance, and the notes section clarifies important API behavior that developers should be aware of.
README.md (6)
11-37: Excellent clarification of Claude application differences.The clear distinction between Claude Desktop and Claude Code with their different installation procedures addresses a common source of user confusion.
40-68: Comprehensive Claude Desktop installation instructions.The installation instructions are detailed and include platform-specific configuration file locations, which is very helpful for users.
71-103: Clear Claude Code installation process.The step-by-step installation process for Claude Code is well-organized and includes both CLI commands and environment variable setup options.
308-333: Excellent enhanced troubleshooting section.The troubleshooting section provides application-specific guidance and covers the most common issues users encounter. The structured approach makes it easy to find relevant solutions.
340-344: Helpful user guidance for application identification.The section helps users identify which Claude application they're using, which is crucial for following the correct installation instructions.
185-189: Project tools count and capabilities match implementationThe README’s Project Management (3 tools) section accurately lists the three tools—
motion_list_projects,motion_get_project, andmotion_create_project—exactly as implemented insrc/tools/project.ts. There is no “read-only once created” statement in the README, and the code does support creating new projects. No changes are needed here.docs/official_api/tasks/delete-task.md (1)
30-31: Ensure no real credentials ever slip into examplesStatic scanning (
gitleaks) flagged this header. It’s only a placeholder, but double-check future snippets don’t hard-code real keys or tokens.docs/official_api/custom-fields/remove-from-project.md (1)
31-32: Double-check example headers for real tokensThe placeholder
YOUR_API_KEYis fine, but keep an eye out so real secrets never land in docs.docs/official_api/recurring-tasks/create-recurring-task.md (1)
49-51: Credential placeholder reminderGitleaks flagged the curl header—looks fine as a placeholder. Just stay vigilant that no live keys are committed.
docs/official_api/comments/README.md (1)
1-34: Looks good – comprehensive and consistent.No issues spotted in the object schema, endpoint table, or examples.
The fenced-code blocks already declare their language and satisfymarkdownlintrules.docs/official_api/custom-fields/delete-custom-field.md (1)
1-335: Excellent comprehensive documentation.This documentation is well-structured with:
- Clear API endpoint specification
- Comprehensive error handling examples
- Multiple practical code examples (JavaScript, Python)
- Important warnings about data loss
- Best practices section
- Impact analysis utilities
The examples demonstrate real-world usage patterns and proper error handling.
docs/official_api/workspaces/list-workspaces.md (1)
1-380: Excellent documentation with comprehensive examples.This documentation provides:
- Clear API specification with pagination support
- Detailed response structures for both basic and expanded modes
- Multiple practical code examples
- Useful utility functions (pagination, filtering, workspace selection)
- Best practices guidance
The examples demonstrate proper handling of pagination and different workspace access patterns.
docs/official_api/schedules/get-schedules.md (1)
1-322: Comprehensive schedule documentation with useful utilities.This documentation provides:
- Clear API specification for retrieving work schedules
- Detailed response structure with timezone information
- Multiple practical code examples (JavaScript, Python)
- Useful utility functions for calculating work hours and checking availability
- Good coverage of split schedules and different time zones
The examples demonstrate real-world usage patterns for schedule management.
test/tools/project.test.ts (4)
20-30: Well-structured tool registration verification.The test correctly verifies that exactly 3 project tools are registered and validates their names in the expected order.
32-51: Comprehensive testing of list projects functionality.The test validates both successful operation and required parameter validation using proper assertion patterns.
53-91: Thorough project creation testing with proper validation.The test covers:
- Successful project creation with proper property validation
- Required field validation with appropriate error expectations
- Proper tracking of created projects for cleanup
117-130: Appropriate handling of API limitations.The cleanup section properly acknowledges that projects cannot be deleted via the Motion API, which is documented in the codebase. The wait for API limits shows good consideration of rate limiting.
src/tools/recurringTask.ts (4)
8-33: Enhanced list functionality with improved pagination support.The updated list tool now properly requires a workspace ID and supports cursor-based pagination, returning structured responses with metadata and count information.
36-101: Comprehensive recurring task creation with expanded parameters.The create tool has been significantly enhanced with:
- Required
assigneeIdfield (good for ensuring ownership)- Optional deadline type, starting date, and ideal time
- Schedule and priority configuration
- Labels support for better organization
- Flexible frequency string instead of fixed enum
The validation schema properly handles all these parameters with appropriate types.
84-84: Flexible frequency validation approach.Changing from enum to string validation for frequency allows for more flexible recurrence patterns while maintaining input validation.
78-78: Appropriate required field validation.Making
assigneeIdrequired ensures proper task ownership and aligns with typical task management workflows.src/tools/project.ts (3)
13-15: LGTM! Proper enforcement of workspace requirement.The addition of the required
workspaceIdparameter aligns with the API changes mentioned in the AI summary, ensuring workspace-scoped project listing.
66-81: Good addition of custom fields support.The
customFieldValuesfield implementation follows the documented API pattern and uses appropriate validation withz.record(z.any())for flexible key-value pairs.
87-88: Excellent documentation of API limitations.The comments clearly explain why update and delete operations are not available, which helps developers understand the API constraints.
docs/official_api/custom-fields/add-to-project.md (1)
95-529: Excellent comprehensive documentation.The documentation provides thorough examples covering multiple field types, use cases, and implementation patterns. The code examples are well-structured and include proper error handling.
docs/official_api/comments/get-comments.md (2)
129-158: Excellent pagination example.The pagination implementation correctly handles cursor-based pagination with proper error handling and demonstrates the standard pattern for collecting all results.
279-294: Valuable response notes and best practices.The documentation provides important clarifications about HTML content format, chronological ordering, and API limitations, which helps developers understand the expected behavior.
docs/official_api/projects/get-project.md (2)
192-215: Good error handling wrapper function.The
getProjectSafelyfunction provides a clean pattern for handling different error scenarios with structured return values.
321-327: Excellent best practices section.The best practices provide valuable guidance on error handling, status checking, and data processing that will help developers use the API effectively.
docs/official_api/tasks/update-task.md (2)
127-196: Excellent update examples covering common use cases.The examples demonstrate various update scenarios with clear JSON structures, covering priority changes, status updates, assignments, and more complex operations.
304-312: Valuable important notes section.The notes provide crucial information about partial updates, label replacement semantics, and scheduling implications that developers need to understand.
docs/official_api/tasks/create-task.md (1)
1-334: Excellent comprehensive API documentation.This documentation provides thorough coverage of the task creation API with clear examples, error handling, and practical use cases. The structure is well-organized and includes helpful code examples in multiple languages.
docs/official_api/custom-fields/remove-from-task.md (1)
1-337: Excellent comprehensive API documentation with practical examples.This documentation provides thorough coverage of the custom field removal API with excellent practical examples including bulk operations, conditional removal, and use cases. The structure is well-organized and includes helpful best practices.
test/utils.ts (2)
26-48: Well-implemented assertion helpers.The assertion functions provide clear error messages and follow consistent naming conventions. Good use of Node.js built-in assert module.
54-65: Excellent test context wrapper with clear logging.The
createTestContextfunction provides a clean way to wrap tests with descriptive logging using emojis for visual clarity. Good integration with Node.js test runner.docs/official_api/recurring-tasks/delete-recurring-task.md (1)
1-299: Excellent comprehensive API documentation with practical examples.This documentation provides thorough coverage of the recurring task deletion API with excellent practical examples including bulk operations, cleanup patterns, and comprehensive coverage of what happens when deleted. The structure is well-organized and includes helpful best practices and alternatives to deletion.
docs/official_api/tasks/README.md (1)
1-128: Excellent comprehensive API overview documentation.This README provides a thorough and well-structured overview of the Tasks API with clear sections, helpful code examples, best practices, and links to related resources. The content is well-organized and serves as an excellent entry point for developers using the Tasks API.
docs/official_api/statuses/list-statuses.md (1)
1-330: Excellent comprehensive API documentation.This documentation provides thorough coverage of the List Statuses endpoint with:
- Clear endpoint specification and parameters
- Multiple practical examples in different languages
- Comprehensive error handling documentation
- Useful helper functions and validation patterns
- Best practices and important notes
The structure and completeness will greatly help developers using this API.
docs/official_api/comments/create-comment.md (1)
1-322: Outstanding API documentation with practical examples.This documentation excellently covers the Create Comment endpoint with:
- Clear request/response specifications
- Rich markdown content examples demonstrating various use cases
- Comprehensive code examples in multiple languages
- Reusable comment templates for common scenarios
- Detailed markdown support reference
- Practical best practices
The template examples (status updates, code reviews, blocked tasks) are particularly valuable for developers.
docs/official_api/custom-fields/create-custom-field.md (1)
1-483: Exceptionally detailed API documentation.This documentation provides comprehensive coverage of the Create Custom Field endpoint with:
- Clear endpoint specification with path parameters
- Extensive examples for all supported field types
- Detailed metadata configurations and options
- Practical code examples with error handling
- Useful builder pattern implementation
- Complete metadata reference with formatting options
- Batch creation examples for efficiency
The field type examples (lines 113-256) are particularly valuable, showing real-world configurations for different use cases.
src/types/motion.ts (6)
64-64: Good nullable type update for teamId.Making
teamIdnullable appropriately handles individual workspaces that don't belong to a team.
67-68: Approve interface updates for workspace enhancements.The renaming from
statusestotaskStatusesprovides better clarity, and the optionalusersarray supports the enhanced workspace listing capabilities.
98-111: Well-designed work schedule interface.The
MotionWorkScheduleinterface properly models a weekly schedule with:
- Timezone support for proper time handling
- Daily time ranges as arrays to support multiple time blocks
- Clear naming and structure
130-138: Excellent metadata structure for custom fields.The replacement of the simple
optionsarray with a flexiblemetadataobject is a significant improvement:
- Supports multiple formatting options for numbers
- Detailed option objects with IDs and colors for select fields
- Toggle configuration for checkboxes
- Extensible structure for future field types
This aligns well with the API documentation examples.
160-176: Enhanced recurring task interface with flexible frequency.The changes improve the recurring task model:
frequencyas string allows complex recurrence patterns- Optional
recurrenceRuleprovides flexibility- Additional relational fields (creator, assignee, etc.) support richer data
- Scheduling fields enable better task management
202-221: Comprehensive updates to task and project parameters.The addition of
customFieldValuesto both create and update operations, along with enhanced scheduling parameters, properly supports the expanded API capabilities shown in the documentation.src/tools/customField.ts (6)
13-15: Good enforcement of required workspaceId.Making
workspaceIdrequired for listing custom fields aligns with the API requirement and provides better user experience with clear validation.
57-82: Excellent transition from options to metadata.The change from
optionstometadatawith flexible passthrough validation properly supports the enhanced custom field configurations shown in the documentation. Usingz.object({}).passthrough().optional()allows for type-specific metadata while maintaining validation.
89-110: Well-implemented delete custom field tool.The new delete tool follows the established patterns:
- Proper input validation with Zod
- Clear parameter requirements
- Appropriate success response
- Consistent error handling
118-133: Appropriate parameter naming update.The change from
customFieldIdtocustomFieldInstanceIdbetter reflects the API's distinction between field definitions and field instances, improving clarity for developers.
174-185: Correct parameter naming for value removal.Using
valueIdinstead ofcustomFieldIdfor removing custom field values accurately reflects the API requirement to target specific field value instances.
189-210: Valuable addition of project custom field removal.The new tool for removing custom fields from projects complements the existing task functionality and follows the same consistent patterns for validation and error handling.
src/tools/task.ts (6)
4-4: LGTM!The
MotionStatusimport is necessary for the new status-based task completion logic.
71-159: Well-structured enhancements to task creation!The updates to
motion_create_taskimprove usability:
- Clear documentation about when
dueDateis required- Proper validation for
autoScheduledconfiguration with required fields- Support for custom fields aligns with the API client capabilities
161-254: Comprehensive task update capabilities!The enhancements to
motion_update_taskare well-implemented:
- Task movement between workspaces/projects is now supported
- Auto-scheduling configuration matches the create method
- Custom field updates are properly integrated
275-297: Correct implementation of workspace-based task movement!The refactored
motion_move_tasktool properly aligns with the API's workspace-centric task movement model and supports optional reassignment.
298-316: Good addition of task unassignment capability!The new
motion_unassign_tasktool provides essential functionality for removing assignees from tasks.
357-403: Consistent implementation of status-based uncompletion!The
motion_uncomplete_tasktool properly mirrors the completion logic, with appropriate preference for default unresolved status.src/api/client.ts (4)
25-108: Robust retry mechanism with exponential backoff!The retry implementation is well-designed:
- Appropriate retry conditions (rate limits, network errors, 5xx)
- Exponential backoff prevents overwhelming the server
- Silent retries maintain MCP protocol integrity
286-349: Proper migration to beta custom field endpoints!The custom field methods correctly implement the new beta API:
- Workspace-scoped operations are properly handled
- The change from
optionstometadataaligns with API changes- New deletion capability adds completeness
35-43: Good reliability improvements!The conservative rate limiting (80% of actual limit) and 30-second timeout enhance the client's robustness in production environments.
396-422: Confirm consistency of status properties across workspaces before aggregation.The current listStatuses implementation uses only status.name to dedupe, which risks dropping differing flags (
isDefaultStatus,isResolvedStatus) when two workspaces define the same-named status with different properties. Please verify that:
- All workspaces always use identical
isDefaultStatusandisResolvedStatusvalues for any given status name
—or—- Update the aggregation logic to handle conflicts, for example by:
- Including
workspaceIdin the uniqueness key, or- Merging or warning on differing flag values
Locations to review:
- src/api/client.ts:
listStatuses(lines ~396–422)docs/official_api/statuses/README.md (1)
17-17: Verify the relative link./list-statuses.mdexists.A broken link inside API docs disrupts the reading flow.
Please ensure the file is committed (and the path is correct case-sensitively) or adjust the reference.
| "@types/node-fetch": "^2.6.12", | ||
| "axios": "^1.7.9", | ||
| "dotenv": "^16.4.7", | ||
| "node-fetch": "^3.3.2", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the need for node-fetch alongside axios.
The addition of node-fetch introduces a second HTTP client library alongside the existing axios. Consider if both are necessary or if the codebase could standardize on one HTTP client library for consistency.
🏁 Script executed:
#!/bin/bash
# Check usage of node-fetch vs axios in the codebase
echo "=== Node-fetch usage ==="
rg -n "node-fetch|fetch" --type ts
echo -e "\n=== Axios usage ==="
rg -n "axios" --type ts
echo -e "\n=== HTTP client imports ==="
rg -n "import.*fetch|import.*axios" --type tsLength of output: 788
🏁 Script executed:
#!/bin/bash
echo "=== Imports from node-fetch ==="
rg -n "from 'node-fetch'" --type ts
echo -e "\n=== require('node-fetch') usage ==="
rg -n "require('node-fetch')" --type ts
echo -e "\n=== fetch( usage (excluding commented lines) ==="
rg -n "^[^/].*fetch\(" --type ts
echo -e "\n=== Context around line 136 in src/api/client.ts ==="
sed -n '120,160p' src/api/client.tsLength of output: 1812
🏁 Script executed:
#!/bin/bash
echo "=== Definition of request method ==="
rg -n "async request" --type ts -A 5 -B 5 src/api/client.tsLength of output: 464
Remove unused node-fetch dependency
We’ve confirmed there are no import 'node-fetch', require('node-fetch'), or runtime fetch( calls—only Axios is used for HTTP requests. You can remove both node-fetch and its type definitions.
• File: package.json (lines ~51–54)
• Suggested diff:
- "@types/node-fetch": "^2.6.12",
"axios": "^1.7.9",
"dotenv": "^16.4.7",
- "node-fetch": "^3.3.2",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@types/node-fetch": "^2.6.12", | |
| "axios": "^1.7.9", | |
| "dotenv": "^16.4.7", | |
| "node-fetch": "^3.3.2", | |
| "axios": "^1.7.9", | |
| "dotenv": "^16.4.7", |
🤖 Prompt for AI Agents
In package.json around lines 51 to 54, remove the "node-fetch" and
"@types/node-fetch" dependencies since they are not used anywhere in the
codebase. This cleanup will keep the dependencies accurate and reduce
unnecessary package bloat.
| await t.beforeEach(async () => { | ||
| if (!testWorkspaceId) { | ||
| testWorkspaceId = await setupTestWorkspace(); | ||
| } | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix the beforeEach hook usage pattern.
The beforeEach hook is being used incorrectly for one-time setup. Since testWorkspaceId only needs to be set once, this should be a before hook or setup outside the test suite.
- await t.beforeEach(async () => {
+ await t.before(async () => {
if (!testWorkspaceId) {
testWorkspaceId = await setupTestWorkspace();
}
});Alternatively, remove the conditional check and use before for cleaner one-time setup:
- await t.beforeEach(async () => {
- if (!testWorkspaceId) {
- testWorkspaceId = await setupTestWorkspace();
- }
- });
+ await t.before(async () => {
+ testWorkspaceId = await setupTestWorkspace();
+ });Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In test/tools/schedule-status.test.ts around lines 11 to 15, the beforeEach hook
is incorrectly used for one-time setup of testWorkspaceId. Replace the
beforeEach hook with a before hook to ensure testWorkspaceId is set only once
before all tests run. Remove the conditional check inside the hook since it will
only execute once, making the setup cleaner and more efficient.
| export async function cleanupTestData(pattern: string): Promise<void> { | ||
| const tasks = await testClient.listTasks({ name: pattern }); | ||
|
|
||
| for (const task of tasks.tasks || []) { | ||
| if (task.name.includes(pattern)) { | ||
| await testClient.deleteTask(task.id); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve cleanup function robustness.
The cleanup function has a potential issue with the double name filtering - it filters by name parameter in the API call and then again in the loop.
export async function cleanupTestData(pattern: string): Promise<void> {
const tasks = await testClient.listTasks({ name: pattern });
- for (const task of tasks.tasks || []) {
- if (task.name.includes(pattern)) {
- await testClient.deleteTask(task.id);
- }
- }
+ for (const task of tasks.tasks || []) {
+ await testClient.deleteTask(task.id);
+ }
}Since the API call already filters by name, the additional filtering in the loop is redundant and could miss tasks if the API filtering behavior differs from the string includes check.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export async function cleanupTestData(pattern: string): Promise<void> { | |
| const tasks = await testClient.listTasks({ name: pattern }); | |
| for (const task of tasks.tasks || []) { | |
| if (task.name.includes(pattern)) { | |
| await testClient.deleteTask(task.id); | |
| } | |
| } | |
| } | |
| export async function cleanupTestData(pattern: string): Promise<void> { | |
| const tasks = await testClient.listTasks({ name: pattern }); | |
| for (const task of tasks.tasks || []) { | |
| await testClient.deleteTask(task.id); | |
| } | |
| } |
🤖 Prompt for AI Agents
In test/setup.ts around lines 34 to 42, remove the redundant name filtering
inside the loop since the API call to listTasks already filters tasks by name.
Simply iterate over the returned tasks and delete each one without checking the
name again to ensure all filtered tasks are properly cleaned up.
| ### Additional Tools (22 tools) | ||
| - User management (3 tools) | ||
| - Schedule management (1 tool) | ||
| - Comment management (5 tools) | ||
| - Custom field management (5 tools) | ||
| - Recurring task management (5 tools) | ||
| - Recurring task management (4 tools) | ||
| - Schedule management (2 tools) | ||
| - Status management (1 tool) | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify additional tools count.
The section claims "22 tools" for additional tools, but the breakdown doesn't add up to 22. Please verify the actual counts.
🏁 Script executed:
#!/bin/bash
# Count all tools by category
echo "Task tools:"
ast-grep --pattern 'registerTaskTools' -A 100 | grep -c "name:"
echo "Project tools:"
ast-grep --pattern 'registerProjectTools' -A 100 | grep -c "name:"
echo "User tools:"
ast-grep --pattern 'registerUserTools' -A 100 | grep -c "name:"
echo "Comment tools:"
ast-grep --pattern 'registerCommentTools' -A 100 | grep -c "name:"
echo "Custom field tools:"
ast-grep --pattern 'registerCustomFieldTools' -A 100 | grep -c "name:"
echo "Recurring task tools:"
ast-grep --pattern 'registerRecurringTaskTools' -A 100 | grep -c "name:"
echo "Schedule tools:"
ast-grep --pattern 'registerScheduleTools' -A 100 | grep -c "name:"
echo "Status tools:"
ast-grep --pattern 'registerStatusTools' -A 100 | grep -c "name:"Length of output: 865
Update Additional Tools count and breakdown in README.md
The “Additional Tools” section is out of sync with the actual registrations. Based on the latest counts, please update lines 194–202 in README.md as follows:
- Change the total from 22 to 58
- Replace the list with the eight categories and their correct counts
Suggested snippet:
- ### Additional Tools (22 tools)
- - User management (3 tools)
- - Schedule management (1 tool)
- - Comment management (5 tools)
- - Custom field management (5 tools)
- - Recurring task management (4 tools)
- - Schedule management (2 tools)
- - Status management (1 tool)
+ ### Additional Tools (58 tools)
+ - Task management (10 tools)
+ - Project management (12 tools)
+ - User management (8 tools)
+ - Comment management (7 tools)
+ - Custom field management (7 tools)
+ - Recurring task management (7 tools)
+ - Schedule management (4 tools)
+ - Status management (3 tools)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### Additional Tools (22 tools) | |
| - User management (3 tools) | |
| - Schedule management (1 tool) | |
| - Comment management (5 tools) | |
| - Custom field management (5 tools) | |
| - Recurring task management (5 tools) | |
| - Recurring task management (4 tools) | |
| - Schedule management (2 tools) | |
| - Status management (1 tool) | |
| ### Additional Tools (58 tools) | |
| - Task management (10 tools) | |
| - Project management (12 tools) | |
| - User management (8 tools) | |
| - Comment management (7 tools) | |
| - Custom field management (7 tools) | |
| - Recurring task management (7 tools) | |
| - Schedule management (4 tools) | |
| - Status management (3 tools) |
🤖 Prompt for AI Agents
In README.md around lines 194 to 202, the "Additional Tools" section shows an
incorrect total count of 22 and an outdated breakdown of tool categories. Update
the total count to 58 and replace the existing list with the correct eight
categories and their respective counts as per the latest registrations to ensure
accuracy.
| ### Task Management (7 tools) | ||
| - `motion_list_tasks` - List tasks with filtering and pagination | ||
| - `motion_get_task` - Get detailed task information | ||
| - `motion_create_task` - Create new tasks with auto-scheduling | ||
| - `motion_update_task` - Update task properties | ||
| - `motion_delete_task` - Delete tasks | ||
| - `motion_move_task` - Move tasks between projects | ||
| - `motion_complete_task` - Mark tasks as completed | ||
| - `motion_uncomplete_task` - Mark tasks as not completed | ||
| - `motion_move_task` - Move tasks between workspaces | ||
| - `motion_unassign_task` - Remove assignee from task |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify task tool count accuracy.
The section claims "7 tools" for task management, but lists 6 tools. Please verify the actual count.
🏁 Script executed:
#!/bin/bash
# Check the actual number of task management tools
ast-grep --pattern 'registerTaskTools' -A 20 | grep -E "name:|description:" | wc -lLength of output: 86
🏁 Script executed:
#!/bin/bash
# Locate and display the registerTaskTools invocation to verify the exact number of task tools
rg -n 'registerTaskTools' -C50Length of output: 10923
Update Task Management to list all 9 tools
The code actually registers 9 task tools, so the README should say “9 tools” and include the two missing entries.
• File: README.md (around lines 176–183)
– Change the heading to:
diff - ### Task Management (7 tools) + ### Task Management (9 tools)
– After the last listed tool (motion_unassign_task), add:
diff + - `motion_complete_task` - Mark a task as complete + - `motion_uncomplete_task` - Reopen a completed task
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### Task Management (7 tools) | |
| - `motion_list_tasks` - List tasks with filtering and pagination | |
| - `motion_get_task` - Get detailed task information | |
| - `motion_create_task` - Create new tasks with auto-scheduling | |
| - `motion_update_task` - Update task properties | |
| - `motion_delete_task` - Delete tasks | |
| - `motion_move_task` - Move tasks between projects | |
| - `motion_complete_task` - Mark tasks as completed | |
| - `motion_uncomplete_task` - Mark tasks as not completed | |
| - `motion_move_task` - Move tasks between workspaces | |
| - `motion_unassign_task` - Remove assignee from task | |
| ### Task Management (9 tools) | |
| - `motion_list_tasks` - List tasks with filtering and pagination | |
| - `motion_get_task` - Get detailed task information | |
| - `motion_create_task` - Create new tasks with auto-scheduling | |
| - `motion_update_task` - Update task properties | |
| - `motion_delete_task` - Delete tasks | |
| - `motion_move_task` - Move tasks between workspaces | |
| - `motion_unassign_task` - Remove assignee from task | |
| - `motion_complete_task` - Mark a task as complete | |
| - `motion_uncomplete_task` - Reopen a completed task |
🤖 Prompt for AI Agents
In README.md around lines 176 to 183, update the Task Management section heading
to indicate "9 tools" instead of "7 tools" to reflect the actual number of
registered task tools. After the last listed tool `motion_unassign_task`, add
the two missing task tools to complete the list. Ensure the formatting matches
the existing list style.
| ], | ||
| "friday": [ | ||
| { "start": "09:00", "end": "12:30" }, | ||
| { "start": "13:30", "end: "17:00" } |
There was a problem hiding this comment.
Fix JSON syntax error in schedule example.
There's a missing closing quote in the "end" field that would cause JSON parsing errors.
- { "start": "09:00", "end: "17:00" }
+ { "start": "09:00", "end": "17:00" }Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In docs/official_api/schedules/get-schedules.md at line 106, the JSON example
has a syntax error due to a missing closing quote in the "end" field. Fix this
by adding the missing closing quote after "17:00" to ensure the JSON is valid
and parsable.
| // Filter out includeAllStatuses if it's false | ||
| const filteredParams = params ? { ...params } : undefined; | ||
| if (filteredParams && filteredParams.includeAllStatuses === false) { | ||
| delete filteredParams.includeAllStatuses; | ||
| } | ||
|
|
||
| const response = await this.request<{ meta: any; tasks: MotionTask[] }>( | ||
| 'GET', | ||
| '/tasks', | ||
| undefined, | ||
| params | ||
| filteredParams | ||
| ); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Optimize parameter filtering to avoid delete operator.
Good optimization to filter out unnecessary parameters. However, the static analysis correctly flags the delete operator usage.
Apply this fix to avoid the performance impact of the delete operator:
- // Filter out includeAllStatuses if it's false
- const filteredParams = params ? { ...params } : undefined;
- if (filteredParams && filteredParams.includeAllStatuses === false) {
- delete filteredParams.includeAllStatuses;
- }
+ // Filter out includeAllStatuses if it's false
+ const filteredParams = params
+ ? Object.fromEntries(
+ Object.entries(params).filter(([key, value]) =>
+ !(key === 'includeAllStatuses' && value === false)
+ )
+ )
+ : undefined;🧰 Tools
🪛 Biome (1.9.4)
[error] 159-159: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
🤖 Prompt for AI Agents
In src/api/client.ts around lines 156 to 167, avoid using the delete operator to
remove the includeAllStatuses property from filteredParams. Instead, create
filteredParams by copying only the necessary properties from params, excluding
includeAllStatuses when it is false. This can be done by conditionally spreading
properties or constructing a new object without includeAllStatuses, thereby
improving performance and satisfying static analysis.
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/tools/task.ts(9 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/tools/task.ts (1)
src/types/motion.ts (1)
MotionStatus(71-75)
🔇 Additional comments (4)
src/tools/task.ts (4)
4-4: Import addition is appropriate.The
MotionStatustype import is necessary for the new status-based completion logic implemented in the completion/uncompletion handlers.
299-316: New unassign task tool looks good.The implementation is clean and follows the established patterns for task tools. The validation and API call are appropriate.
197-248: Enhanced update task functionality looks comprehensive.The addition of workspace moves, auto-scheduling, and custom field support significantly expands the tool's capabilities while maintaining good validation patterns.
277-296: MoveTask implementation matches the API signature
The handler’s call toclient.moveTask(taskId, { workspaceId, assigneeId })aligns with:
- src/api/client.ts –
async moveTask(taskId: string, params: { workspaceId: string; assigneeId?: string })- docs/official_api/tasks/move-task.md – examples showing
workspaceIdand optionalassigneeIdNo further changes required.
| customFieldValues: { | ||
| type: 'object', | ||
| description: 'Custom field values as key-value pairs', | ||
| additionalProperties: true, | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Custom field validation may be too permissive.
Using additionalProperties: true and z.record(z.any()) allows any data structure, which could pose security risks or data consistency issues.
Consider adding more restrictive validation:
-customFieldValues: {
- type: 'object',
- description: 'Custom field values as key-value pairs',
- additionalProperties: true,
-},
+customFieldValues: {
+ type: 'object',
+ description: 'Custom field values as key-value pairs',
+ additionalProperties: {
+ type: ['string', 'number', 'boolean', 'null']
+ },
+},And update the Zod schema:
-customFieldValues: z.record(z.any()).optional(),
+customFieldValues: z.record(z.union([z.string(), z.number(), z.boolean(), z.null()])).optional(),Also applies to: 154-154
🤖 Prompt for AI Agents
In src/tools/task.ts at lines 124 to 128 and line 154, the current schema for
customFieldValues uses additionalProperties: true and z.record(z.any()), which
is too permissive and may allow invalid or unsafe data. To fix this, replace
additionalProperties: true with a more restrictive schema that defines the
expected types or structure of the custom field values, such as limiting to
strings, numbers, or specific nested objects. Similarly, update the Zod schema
to reflect these stricter validations by specifying the allowed value types
instead of z.any(). This will improve data consistency and security.
| description: | ||
| 'Create a new task in Motion. Note: dueDate is required when duration is not "NONE" or when using autoScheduled.', | ||
| inputSchema: { | ||
| type: 'object', | ||
| properties: { | ||
| name: { type: 'string', description: 'Task title' }, | ||
| workspaceId: { type: 'string', description: 'Workspace ID' }, | ||
| dueDate: { | ||
| type: 'string', | ||
| description: 'ISO 8601 due date (required for scheduled tasks)', | ||
| description: | ||
| 'ISO 8601 due date. REQUIRED when: 1) duration is not "NONE" (i.e., "REMINDER" or minutes), or 2) autoScheduled is provided', | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider enforcing dueDate requirement in schema validation.
The description clearly states when dueDate is required, but the Zod schema doesn't enforce this constraint. Users could create invalid combinations that would fail at the API level.
Consider adding custom validation to enforce the dueDate requirement:
const schema = z.object({
name: z.string().min(1),
workspaceId: z.string().min(1),
dueDate: z.string().optional(),
duration: z.union([z.string(), z.number()]).optional(),
// ... other fields
+}).superRefine((data, ctx) => {
+ const needsDueDate =
+ (data.duration && data.duration !== "NONE") ||
+ data.autoScheduled;
+
+ if (needsDueDate && !data.dueDate) {
+ ctx.addIssue({
+ code: z.ZodIssueCode.custom,
+ message: "dueDate is required when duration is not 'NONE' or when using autoScheduled",
+ path: ['dueDate']
+ });
+ }
});Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In src/tools/task.ts around lines 72 to 83, the inputSchema description states
that dueDate is required under certain conditions, but the schema does not
enforce this. To fix this, add a custom validation in the Zod schema that checks
if dueDate is present when duration is not "NONE" or when autoScheduled is
provided, ensuring invalid inputs are caught early before API calls.
| // If no status provided, we need to find a resolved status | ||
| let statusName = validated.status; | ||
| if (!statusName) { | ||
| // Get the task to find its workspace | ||
| const task = await client.getTask(validated.taskId); | ||
| // Get statuses for the workspace | ||
| const statuses = await client.listStatuses(task.workspace.id); | ||
| const resolvedStatus = statuses.find((s: MotionStatus) => s.isResolvedStatus); | ||
| if (!resolvedStatus) { | ||
| throw new Error('No resolved status found in workspace'); | ||
| } | ||
| statusName = resolvedStatus.name; | ||
| } | ||
|
|
||
| return await client.updateTask(validated.taskId, { status: statusName }); | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Potential performance and race condition issues in completion logic.
The completion logic makes multiple API calls sequentially, which could be inefficient and subject to race conditions if the task or workspace statuses change between calls.
Consider these improvements:
- Batch the API calls or cache workspace statuses
- Add proper error handling for edge cases
- Consider making the status parameter required to avoid the lookup overhead
// If no status provided, we need to find a resolved status
let statusName = validated.status;
if (!statusName) {
+ try {
// Get the task to find its workspace
const task = await client.getTask(validated.taskId);
// Get statuses for the workspace
const statuses = await client.listStatuses(task.workspace.id);
const resolvedStatus = statuses.find((s: MotionStatus) => s.isResolvedStatus);
if (!resolvedStatus) {
throw new Error('No resolved status found in workspace');
}
statusName = resolvedStatus.name;
+ } catch (error) {
+ throw new Error(`Failed to determine completion status: ${error.message}`);
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // If no status provided, we need to find a resolved status | |
| let statusName = validated.status; | |
| if (!statusName) { | |
| // Get the task to find its workspace | |
| const task = await client.getTask(validated.taskId); | |
| // Get statuses for the workspace | |
| const statuses = await client.listStatuses(task.workspace.id); | |
| const resolvedStatus = statuses.find((s: MotionStatus) => s.isResolvedStatus); | |
| if (!resolvedStatus) { | |
| throw new Error('No resolved status found in workspace'); | |
| } | |
| statusName = resolvedStatus.name; | |
| } | |
| return await client.updateTask(validated.taskId, { status: statusName }); | |
| }, | |
| // If no status provided, we need to find a resolved status | |
| let statusName = validated.status; | |
| if (!statusName) { | |
| try { | |
| // Get the task to find its workspace | |
| const task = await client.getTask(validated.taskId); | |
| // Get statuses for the workspace | |
| const statuses = await client.listStatuses(task.workspace.id); | |
| const resolvedStatus = statuses.find((s: MotionStatus) => s.isResolvedStatus); | |
| if (!resolvedStatus) { | |
| throw new Error('No resolved status found in workspace'); | |
| } | |
| statusName = resolvedStatus.name; | |
| } catch (error) { | |
| throw new Error(`Failed to determine completion status: ${error.message}`); | |
| } | |
| } | |
| return await client.updateTask(validated.taskId, { status: statusName }); |
🤖 Prompt for AI Agents
In src/tools/task.ts around lines 340 to 355, the current logic sequentially
fetches the task and then its workspace statuses to find a resolved status if
none is provided, causing potential performance and race condition issues. To
fix this, refactor to batch or cache the workspace statuses to reduce API calls,
add error handling for cases like missing task or workspace data, and consider
making the status parameter mandatory to eliminate the need for this lookup
altogether.
| let statusName = validated.status; | ||
| if (!statusName) { | ||
| // Get the task to find its workspace | ||
| const task = await client.getTask(validated.taskId); | ||
| // Get statuses for the workspace | ||
| const statuses = await client.listStatuses(task.workspace.id); | ||
| const unresolvedStatus = statuses.find( | ||
| (s: MotionStatus) => !s.isResolvedStatus && s.isDefaultStatus | ||
| ); | ||
| if (!unresolvedStatus) { | ||
| // Fallback to any unresolved status | ||
| const anyUnresolvedStatus = statuses.find((s: MotionStatus) => !s.isResolvedStatus); | ||
| if (!anyUnresolvedStatus) { | ||
| throw new Error('No unresolved status found in workspace'); | ||
| } | ||
| statusName = anyUnresolvedStatus.name; | ||
| } else { | ||
| statusName = unresolvedStatus.name; | ||
| } | ||
| } | ||
|
|
||
| return await client.updateTask(validated.taskId, { status: statusName }); | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Uncompletion logic has complex fallback that may cause confusion.
The logic tries to find a default unresolved status, then falls back to any unresolved status. This fallback behavior might not be predictable for users.
Consider simplifying the logic and being more explicit about the fallback behavior:
// If no status provided, we need to find an unresolved status
let statusName = validated.status;
if (!statusName) {
+ try {
// Get the task to find its workspace
const task = await client.getTask(validated.taskId);
// Get statuses for the workspace
const statuses = await client.listStatuses(task.workspace.id);
+
+ // Priority: default unresolved status, then any unresolved status
const unresolvedStatus = statuses.find(
(s: MotionStatus) => !s.isResolvedStatus && s.isDefaultStatus
);
- if (!unresolvedStatus) {
- // Fallback to any unresolved status
- const anyUnresolvedStatus = statuses.find((s: MotionStatus) => !s.isResolvedStatus);
- if (!anyUnresolvedStatus) {
- throw new Error('No unresolved status found in workspace');
- }
- statusName = anyUnresolvedStatus.name;
- } else {
- statusName = unresolvedStatus.name;
- }
+
+ if (unresolvedStatus) {
+ statusName = unresolvedStatus.name;
+ } else {
+ // Fallback to any unresolved status
+ const anyUnresolvedStatus = statuses.find((s: MotionStatus) => !s.isResolvedStatus);
+ if (!anyUnresolvedStatus) {
+ throw new Error('No unresolved status found in workspace');
+ }
+ statusName = anyUnresolvedStatus.name;
+ }
+ } catch (error) {
+ throw new Error(`Failed to determine uncompletion status: ${error.message}`);
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let statusName = validated.status; | |
| if (!statusName) { | |
| // Get the task to find its workspace | |
| const task = await client.getTask(validated.taskId); | |
| // Get statuses for the workspace | |
| const statuses = await client.listStatuses(task.workspace.id); | |
| const unresolvedStatus = statuses.find( | |
| (s: MotionStatus) => !s.isResolvedStatus && s.isDefaultStatus | |
| ); | |
| if (!unresolvedStatus) { | |
| // Fallback to any unresolved status | |
| const anyUnresolvedStatus = statuses.find((s: MotionStatus) => !s.isResolvedStatus); | |
| if (!anyUnresolvedStatus) { | |
| throw new Error('No unresolved status found in workspace'); | |
| } | |
| statusName = anyUnresolvedStatus.name; | |
| } else { | |
| statusName = unresolvedStatus.name; | |
| } | |
| } | |
| return await client.updateTask(validated.taskId, { status: statusName }); | |
| }, | |
| let statusName = validated.status; | |
| if (!statusName) { | |
| try { | |
| // Get the task to find its workspace | |
| const task = await client.getTask(validated.taskId); | |
| // Get statuses for the workspace | |
| const statuses = await client.listStatuses(task.workspace.id); | |
| // Priority: default unresolved status, then any unresolved status | |
| const unresolvedStatus = statuses.find( | |
| (s: MotionStatus) => !s.isResolvedStatus && s.isDefaultStatus | |
| ); | |
| if (unresolvedStatus) { | |
| statusName = unresolvedStatus.name; | |
| } else { | |
| // Fallback to any unresolved status | |
| const anyUnresolvedStatus = statuses.find( | |
| (s: MotionStatus) => !s.isResolvedStatus | |
| ); | |
| if (!anyUnresolvedStatus) { | |
| throw new Error('No unresolved status found in workspace'); | |
| } | |
| statusName = anyUnresolvedStatus.name; | |
| } | |
| } catch (error) { | |
| throw new Error( | |
| `Failed to determine uncompletion status: ${error.message}` | |
| ); | |
| } | |
| } | |
| return await client.updateTask(validated.taskId, { status: statusName }); |
🤖 Prompt for AI Agents
In src/tools/task.ts around lines 380 to 402, the current logic for determining
the unresolved status uses a two-step fallback that can be confusing: first it
looks for a default unresolved status, then falls back to any unresolved status.
Simplify this by clearly defining a single, explicit rule for selecting the
unresolved status, such as always choosing the default unresolved status if it
exists, otherwise throwing an error or clearly documenting the fallback. Remove
the nested fallback to avoid unpredictability and make the behavior
straightforward and easier to maintain.
1 participant
This pull request introduces a comprehensive set of documentation updates to standardize and clarify development practices, project structure, and tool implementation for the Motion MCP server. The changes span multiple
.mdcfiles and aim to improve developer onboarding, code quality, and consistency across the project.Documentation Updates
API Client Patterns
MotionApiClientclass, including rate limiting, error handling, and HTTP method usage.Data Validation
Development Workflow
Error Handling
MCP Tool Patterns
Project Structure
TypeScript Conventions
README Updates
CLAUDE.md
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Tests
Chores