@vooster/mcp

Updates the project's display name.

Lists tasks assigned to the current user or unassigned tasks for the connected project

Reads detailed information of a specific task

Reads the PRD (Product Requirements Document) for the connected project.

Reads the Design Guide document for the connected project.

[DEPRECATED] Use add_task instead. ## Description This tool is deprecated. Please use 'add_task' tool multiple times instead. ## Reason for Deprecation - TaskId auto-generation conflicts with bulk operations - Better taskId format validation with single task creation - Improved error handling for individual tasks ## Migration Instead of calling this tool with multiple tasks, call 'add_task' multiple times: - Each task gets proper validation - TaskId is auto-generated in correct format - Better error isolation per task

Reads the User Journey document for the connected project.

Reads the Code Guideline document for the connected project.

Updates Code Guideline document for the project. Use after generating guideline from TRD and repository conventions.

Updates Information Architecture (IA) document for the project.

Updates ERD document for the project (Mermaid).

Check which documents are missing for the given project. If something is missing, respond with a system prompt instructing to call the corresponding update tool, then to call this tool again.

Updates Design Guide document for the project.

Lists all tasks for the connected project. Supports optional pagination with offset and limit parameters (both must be provided together). Without pagination, all tasks are returned with pagination guidance if total count exceeds 100.

Reads the TRD (Technical Requirements Document) for the connected project.

Reads the Information Architecture (IA) document for the connected project.

Create an empty project and connect it to current codebase. STRICT HINT: Only call this tool when the user explicitly mentions 'createProject' by name.

Updates User Journey document for the project.

Lists all projects for the user

Gets the next priority task for the connected project based on importance, urgency, and creation date. ## Important Instructions When this tool returns a task: 1. **Check the task status** - IF status = "BACKLOG", THEN Call update_task_status to update the status to "IN_PROGRESS" - IF status = "IN_PROGRESS", THEN evaluate if the task is actually completed - IF sub-tasks are not all "DONE", THEN implement remaining sub-tasks first. when you finish each sub-task, call update_subtask_status to update the status to "DONE" 2. **For IN_PROGRESS tasks** - Analyze the task's acceptance criteria - Verify if all requirements are met - IF the task is completed: a. Call update_task_status to update status to "DONE" b. Call get_next_task again to fetch the next priority task - IF the task is NOT completed: - Continue working on the current task 3. **Expected workflow** - get_next_task → check status → if IN_PROGRESS and completed → update_task_status(DONE) → get_next_task (repeat)

Updates the status of a task (BACKLOG | IN_PROGRESS | DONE | ARCHIVED) ## CRITICAL REQUIREMENTS ### Pre-Validation Checklist - [ ] Verify task acceptance criteria are fully met before marking as DONE - [ ] If uncertain about completion quality, ASK USER FOR CONFIRMATION before proceeding ### Status-Specific Requirements #### DONE Status - MANDATORY Fields When updating status to DONE, you MUST provide ALL three additional fields: **1. completionDetails** (Markdown format): Structure your response exactly as follows: ``` [One-line summary of completed work] ## Description [Detailed description of implementation, approach, and key decisions] ## Modified Files - [filename]: [brief description of changes] - [filename]: [brief description of changes] - [filename]: [brief description of changes] - [filename]: [brief description of changes] - [filename]: [brief description of changes] ``` **2. confidenceLevel** (1-10 integer): Rate the implementation quality considering: - Bug probability (10 = zero bugs expected, 1 = major bugs likely) - Requirement coverage (10 = 100% fulfilled, 1 = major gaps) - Code quality (10 = production-ready, 1 = requires major rework) - Scope adherence (lower score if significant deviation from original aiPrompt) **3. confidenceDetails** (Detailed explanation): Provide specific justification covering: - Implementation strengths and technical decisions - Potential risks, concerns, or areas needing attention - Alignment with original task requirements vs actual delivery - Testing performed or validation steps taken - Recommendations for follow-up work if applicable ### Quality Assurance - Be brutally honest in assessments - this data is used for project quality tracking - Lower confidence scores for scope creep beyond original requirements - Include specific technical details that justify your confidence rating - Consider both immediate functionality and long-term maintainability ### Error Prevention - Missing any DONE-required field will result in API error - Incomplete or vague descriptions reduce project tracking effectiveness - Overly optimistic confidence ratings can mask technical debt

Automatically updates completed tasks to DONE status through codebase analysis. ## Core Usage Conditions - **Use only when explicitly requested by user**: Use only when requested with phrases like 'update task list based on codebase', 'sync codebase', 'auto-update completed tasks', etc. - **Korean Request Detection**: Recognize and call when the following Korean expressions are used: - "코드베이스를 기준으로 태스크 목록 업데이트해줘" - "코드베이스와 태스크 동기화해줘" - "완료된 태스크들 자동으로 업데이트해줘" - "구현된 기능들 태스크 상태 반영해줘" - "코드 기준으로 태스크 상태 맞춰줘" ## Functionality Analyzes the codebase to find tasks corresponding to already implemented features and updates them to DONE status. ## Required Parameters - **taskIds**: Array of completed task IDs (e.g., ["T-001", "T-002", "T-003"]) ## Auto-Set Values - **completionDetails**: "Completed through codebase synchronization" - **confidenceLevel**: 9 (high confidence) - **confidenceDetails**: "Implementation confirmed in codebase" ## Use Cases 1. Synchronize existing implemented features with task status after connecting new project 2. Resolve inconsistencies between actual implementation status and task status during development 3. Batch process completed tasks that team members didn't manually update ## Important Notes - This tool does not run automatically and requires explicit user request - Only pass tasks that have confirmed implementation in the codebase - Can process multiple tasks at once

Downloads all tasks in the connected project as local files. ## Purpose Creates a complete local backup of all project tasks with individual files and metadata. ## Output Files - **Individual Task Files**: `.vooster/tasks/[taskId].txt` - Complete task information including description, status, dependencies - Formatted for easy reading and reference - **Metadata File**: `.vooster/tasks.json` - Task count and download timestamp - Summary of all tasks with key information - JSON format for programmatic access ## Use Cases - **Project Backup**: Create local backup of all task information - **Documentation**: Export tasks for project documentation - **Offline Reference**: Access task details without internet connection - **Analysis**: Analyze project scope and task distribution - **Migration**: Prepare task data for migration to other systems ## Prerequisites - Valid API key configured - Run from project root directory

## Description Adds a single new task to the currently connected project with auto-generated taskId. ## Features - TaskId is automatically generated in T-001 format - Validates taskId format and uniqueness - Prevents creation of tasks with invalid taskId formats ## Must - Do not add tasks that are already in the project. - Be sure that the user requested to add new tasks. - If tasks are not requested but would be beneficial to add, ask the user for confirmation before adding them. - If you think debugging is needed, ask the user for confirmation before adding them. - If user requested to add debugging tasks, set dependencyIds field as taskIds of related implementation tasks.

Updates completion details for a task already in DONE status after additional work ## PURPOSE & USE CASES This tool is specifically for updating task completion information when: - Additional debugging or bug fixes were performed - Code was refactored or optimized after initial completion - Documentation was added or improved - Test coverage was expanded - Performance improvements were made - Technical debt was addressed ## CRITICAL REQUIREMENTS ### Pre-Validation - [ ] Task MUST already be in DONE status - [ ] Additional work MUST have been performed since original completion - [ ] Updates should reflect the cumulative state (original + new work) ### Required Fields (ALL are mandatory) **1. completionDetails** (Updated markdown summary): Include BOTH original and additional work: ``` [One-line summary reflecting all work done] ## Description [Original implementation description] Additional work: [What was done in this update] ## Modified Files - [file]: [original changes + new changes] - [file]: [original changes + new changes] [Include all files touched, both originally and in update] ``` **2. confidenceLevel** (Updated 1-10 rating): Re-evaluate considering the impact of additional work: - Did debugging fix critical issues? (increase score) - Did refactoring simplify complexity? (increase score) - Were new edge cases discovered? (may decrease score) - Was technical debt reduced? (increase score) **3. confidenceDetails** (Updated justification): Explain how additional work changed the quality: - What specific improvements were made - How the changes impact reliability/maintainability - Any new risks or trade-offs introduced - Overall before/after comparison ## USAGE GUIDELINES ### When to Use - After fixing bugs in completed tasks - After refactoring completed code - After improving performance of done features - After adding tests to completed work - After addressing code review feedback ### When NOT to Use - For tasks not yet in DONE status (use update_task_status instead) - For changing task requirements or scope - For completely rewriting functionality - When no actual code changes were made ## EXAMPLES ### Example 1: Post-debugging Update ``` completionDetails: "Implemented and debugged user authentication system ## Description Originally created JWT-based login/logout functionality. Additional work: Fixed token refresh race condition, added proper error handling for network failures. ## Modified Files - auth.ts: JWT logic + fixed race condition in refresh flow - api-client.ts: Added retry logic with exponential backoff - auth.test.ts: Added test cases for edge cases" confidenceLevel: 9 (increased from 7) confidenceDetails: "Initial implementation was functional but had a critical race condition in token refresh that could cause authentication failures. This has been completely resolved. Added comprehensive error handling and retry logic makes the system much more robust. Test coverage increased from 70% to 95%." ``` ### Example 2: Post-refactoring Update ``` completionDetails: "Built and refactored shopping cart functionality ## Description Originally implemented cart CRUD operations with local state management. Additional work: Extracted cart logic to custom hooks, added optimistic updates, improved type safety. ## Modified Files - Cart.tsx: Simplified component using new useCart hook - hooks/useCart.ts: New centralized cart management - cartTypes.ts: Consolidated type definitions - CartItem.tsx: Refactored to use new patterns" confidenceLevel: 8 (increased from 6) confidenceDetails: "Refactoring significantly improved code organization and reusability. Cart logic is now properly encapsulated and easier to test. Optimistic updates provide better UX. Some complexity added with the hook pattern but overall maintainability greatly improved." ```

Modifies existing task information (summary, aiPrompt, importance, urgency, complexity) [DEPRECATED] Use update_task instead.

Updates the PRD content for the connected project. ## Description Updates the project's PRD with new content provided by the user. ## INPUT Parameter - **aiPrompt** (required): The new PRD content to set for the project ## Usage Instructions Use this tool when the user wants to update the project's PRD content. Provide the new PRD content as the aiPrompt parameter. ## Prerequisites - Valid API key configured ## Important Notes - This will replace the entire PRD content - Make sure the user has provided the complete PRD content they want to set

## Description Manually adds new sub-tasks to a specific task in the currently connected project. ## Must - Make sure the target task exists before adding sub-tasks. - Be sure that the user requested to add new sub-tasks. - If sub-tasks are not requested but would be beneficial to add, ask the user for confirmation before adding them. - Each sub-task should have a clear title and acceptance criteria. - Use dependencySubTaskIds to set dependencies between sub-tasks when needed.

Updates sub-task information including status, title, aiPrompt, acceptanceCriteria, and dependencies ## Description This tool allows you to modify various aspects of a sub-task: - **status**: Change the status (BACKLOG | IN_PROGRESS | DONE) - **title**: Update the sub-task title - **aiPrompt**: Modify the detailed AI prompt/description - **acceptanceCriteria**: Update acceptance criteria - **dependencySubTaskIds**: Change dependency relationships ## Usage You can update one or multiple fields in a single call. At least one field must be provided. ## Must - Make sure the sub-task UID is correct and belongs to the specified task. - If sub-task status update from "BACKLOG", check the task status first. If the task status is "BACKLOG", call update_task_status to update the task status to "IN_PROGRESS" - If you want to move status to DONE, **be sure** that the sub-task's acceptance criteria is met perfectly. If you can't be sure, ask the user to confirm. - When updating dependencies, provide the complete list of dependency sub-task UIDs.

Updates the TRD (Technical Requirements Document) content for the connected project.

Updates the status of a sub-task (BACKLOG | IN_PROGRESS | DONE) ## Must - Make sure the sub-task UID is correct and belongs to the specified task. - If status is BACKLOG, check task status first. If task status is BACKLOG, call update_task_status to update the status to "IN_PROGRESS" - If you want to move to DONE, **be sure** that the sub-task's acceptance criteria is met perfectly. If you can't be sure, ask the user to confirm.

Modifies existing task information (summary, aiPrompt, importance, urgency, complexity) ## Description Updates one or more fields of an existing task. All fields except taskId are optional. ## Parameters - **taskId** (required): ID of the task to modify (e.g., T-001) - **summary** (optional): New task summary/title - **aiPrompt** (optional): New detailed description/prompt for the task - **importance** (optional): New importance level (MUST, SHOULD, COULD, WONT) - **urgency** (optional): New urgency level (1-10) - **complexity** (optional): New complexity level (1-10) ## Use Cases - Update task description after requirements change - Adjust priority (importance/urgency) based on new information - Refine task details for better clarity - Correct mistakes in task information ## Important Notes - Cannot modify task status (use update_task_status instead) - Cannot modify dependencies (requires separate tool) - Only modifies provided fields, others remain unchanged