atlas-mcp-server
by cyanheads
Verified
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NODE_ENV | No | Optional, Node environment. | development |
| ATLAS_WAL_MODE | No | Optional, enables Write-Ahead Logging. | true |
| ATLAS_LOG_LEVEL | No | Optional, log level. | debug |
| ATLAS_POOL_SIZE | No | Optional, connection pool size. | Number of CPU cores |
| ATLAS_BATCH_SIZE | No | Optional, maximum items per batch. | 1000 |
| ATLAS_CACHE_SIZE | No | Optional, cache size in MB. | 25% of max memory |
| ATLAS_MAX_MEMORY | No | Optional, maximum memory in MB. | 25% of system memory |
| ATLAS_STORAGE_DIR | No | Optional, directory for storage. | ~/Documents/Cline/mcp-workspace/ATLAS |
| ATLAS_STORAGE_NAME | No | Optional, storage name. | atlas-tasks |
| ATLAS_TEMPLATE_DIRS | No | Optional, additional template directories. | |
| ATLAS_MAX_PATH_DEPTH | No | Optional, maximum task path depth. | 10 |
| ATLAS_VACUUM_INTERVAL | No | Optional, vacuum interval in milliseconds. | 3600000 |
| ATLAS_METRICS_INTERVAL | No | Optional, metrics interval in milliseconds. | 60000 |
| ATLAS_CHECKPOINT_INTERVAL | No | Optional, checkpoint interval in milliseconds. | 30000 |
| ATLAS_HEALTH_CHECK_INTERVAL | No | Optional, health check interval in milliseconds. | 30000 |
Schema
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Current Task List Overview | Dynamic overview of all tasks including status counts, recent updates, and metrics. Updates in real-time when accessed. |
| Available Templates | List of all available task templates with their metadata and variables |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_task | Create a new task in the hierarchical task system. Core Task Properties: - Path: Hierarchical identifier (e.g., "project/backend/auth") * Max length: 1000 chars * Max depth: 10 levels * Allowed chars: alphanumeric, hyphen, underscore, forward slash * Forward slashes indicate hierarchy levels - Name: Clear, action-oriented task title * Max length: 200 chars * Should describe concrete objective - Description: Detailed task explanation * Max length: 2000 chars * Include context, requirements, success criteria - Type: TASK or MILESTONE * TASK: Concrete work item with specific deliverable * MILESTONE: Organizational container for related tasks Validation & Dependencies: - Dependencies: Tasks that must complete first * Max dependencies: 50 tasks * Tasks blocked until dependencies met * Circular dependencies prevented - Parent-Child Rules: * Parent task must exist if parentPath specified * Child tasks inherit certain parent properties * Parent status affects child task constraints * Proper task hierarchy maintained Notes & Documentation: Each category limited to 100 notes, 1000 chars per note - Planning Notes: Initial task preparation - Progress Notes: Implementation updates - Completion Notes: Final outcomes - Troubleshooting Notes: Issue resolution Metadata Categories: 1. Core Fields: - Priority: low/medium/high - Tags: Keywords for categorization (max 100) - Reasoning: Decision rationale (max 2000 chars) 2. Technical Details: - Language & Framework - Dependencies (max 50) - Environment specifications 3. Validation & Progress: - Acceptance criteria (max 20) - Test cases (max 20) - Progress percentage (0-100) - Milestone tracking - Timestamps 4. Resource Tracking: - Tools used (max 100) - Resources accessed (max 100) - Context references (max 100) 5. Status Information: - Block tracking - Resolution details - Timestamps 6. Version Control: - Version numbers - Branch information - Commit references - Version history (max 10) |
| update_task | Update task properties and status. Status Transitions: - PENDING → IN_PROGRESS, BLOCKED, CANCELLED - IN_PROGRESS → COMPLETED, CANCELLED, BLOCKED - COMPLETED → No transitions allowed - CANCELLED → PENDING (for retry) - BLOCKED → PENDING, IN_PROGRESS Automatic Behaviors: - Auto-transition to BLOCKED if dependencies block - Parent completion requires all children complete - Cancelled parent cancels non-completed children - Blocked siblings prevent task completion - Failed siblings prevent task start Validation Rules: - Same constraints as create_task - Dependencies checked before status changes - Parent-child status rules enforced - Metadata schema validated - Notes length and count limits applied Best Practices: - Document status change reasoning - Update progress indicators - Track technical implementation details - Record blockers and resolutions - Maintain dependency accuracy Example: { "path": "project/backend/auth", "updates": { "status": "IN_PROGRESS", "progressNotes": [ "Database schema updated", "JWT library integrated", "Basic token generation implemented" ], "metadata": { "reasoning": "Moving to IN_PROGRESS as database dependencies are completed and core JWT implementation has begun. Token refresh mechanism still pending.", "technical_notes": [ "Using jsonwebtoken library for JWT operations", "Token expiry set to 1 hour with refresh window" ] } } } |
| get_tasks_by_status | Find tasks with a specific execution status. When to Use: - Identifying work in progress - Finding blocked tasks - Verifying completed work - Planning next actions Best Practices: - Check BLOCKED tasks for dependency issues - Monitor IN_PROGRESS tasks for updates - Review COMPLETED tasks for verification - Use with path patterns for focused queries Example: { "status": "BLOCKED", "pathPattern": "project/backend/*", "reasoning": "Checking for blocked backend tasks to identify and resolve dependencies. This helps maintain project momentum by addressing bottlenecks early." } |
| get_tasks_by_path | Find tasks matching a path pattern. When to Use: - Analyzing specific project areas - Reviewing component progress - Planning related tasks - Identifying gaps in coverage Best Practices: - Use specific patterns for focused results - Include wildcards for broader searches - Consider task hierarchy in patterns - Combine with status checks for detailed analysis Example: { "pathPattern": "project/*/security/*", "reasoning": "Searching for all security-related tasks across project components to ensure comprehensive security coverage and identify any missing security considerations." } |
| get_children | Get all immediate child tasks under a specific path. When to Use: - Understanding task breakdown - Tracking milestone progress - Planning next phase - Identifying missing subtasks Best Practices: - Check milestone children for coverage - Verify subtask relationships - Monitor child task status - Ensure logical task grouping Example: { "path": "project/backend", "reasoning": "Examining backend tasks to understand implementation progress, identify gaps in functionality, and ensure proper task decomposition." } |
| delete_task | Remove a task and all its children from the system. When to Use: - Removing obsolete tasks - Cleaning up completed work - Restructuring project organization - Handling cancelled features Best Practices: - Verify task is truly obsolete - Check for dependent tasks - Document deletion reasoning - Consider archiving instead - Handle child tasks appropriately Example: { "path": "project/backend/deprecated-auth", "reasoning": "Removing deprecated authentication implementation as we've switched to OAuth2. All dependent tasks have been updated to reference the new OAuth2 implementation path." } |
| bulk_task_operations | Execute multiple task operations atomically. Performance Optimization: - Operations processed in dependency order - Single-operation batches for consistency - Full transaction rollback on failure - Retry mechanism: 3 retries, 1s delay Validation: - All create/update constraints apply - Cross-operation dependency validation - Status transition rules enforced - Parent-child relationships validated - Metadata schema checked Best Practices: - Group related operations - Order operations by dependencies - Include clear operation reasoning - Handle parent-child updates together - Consider status propagation effects Operation Limits: - Path: max length 1000 chars, max depth 10 - Notes: max 100 per category - Dependencies: max 50 per task - Metadata fields: max 100 entries each Example: { "operations": [ { "type": "create", "path": "project/backend/oauth2", "data": { "title": "Implement OAuth2 Authentication", "type": "MILESTONE", "description": "Replace JWT auth with OAuth2 implementation", "planningNotes": [ "Research OAuth2 providers", "Define integration requirements" ], "metadata": { "reasoning": "OAuth2 provides better security and standardization" } } }, { "type": "create", "path": "project/backend/oauth2/provider-setup", "data": { "title": "Configure OAuth2 Providers", "dependencies": ["project/backend/oauth2"], "planningNotes": [ "List required OAuth2 providers", "Document configuration requirements" ], "metadata": { "reasoning": "Provider setup required before implementation" } } }, { "type": "update", "path": "project/backend/auth", "data": { "status": "CANCELLED", "completionNotes": [ "Functionality replaced by OAuth2 implementation" ], "metadata": { "reasoning": "Replaced by OAuth2 implementation" } } } ], "reasoning": "Transitioning authentication system to OAuth2. Creating necessary task structure and updating existing tasks to reflect the change." } |
| clear_all_tasks | Remove all tasks from the database. Impact: - Deletes ALL tasks permanently - Removes all relationships and dependencies - Clears all metadata and notes - Resets database to initial state - Cannot be undone When to Use: - Starting fresh project phase - Major project restructuring - Development environment reset - Test environment cleanup Best Practices: - Export tasks before clearing - Verify confirmation flag - Document clear reasoning - Consider selective deletion - Plan new task structure - Archive important metadata Safety Checks: - Requires explicit confirmation - Validates database state - Ensures clean deletion - Prevents partial clears Example: { "confirm": true, "reasoning": "Resetting task structure for Q2 planning. Previous tasks have been archived and new project structure will be implemented with updated requirements and dependencies." } |
| vacuum_database | Optimize database storage and performance. Performance Impact: - Reclaims unused space - Rebuilds indexes - Updates statistics - Optimizes query plans - May take several minutes When to Use: - After bulk operations (creates/deletes) - During maintenance windows - When performance degrades - After large deletions - Before major operations Best Practices: - Run during low activity - Monitor space usage - Schedule regularly - Backup before running - Check performance impact - Allow sufficient time - Monitor system resources Resource Usage: - CPU: Moderate to high - Memory: Temporary increase - Disk I/O: Heavy - Storage: Temporary spike Example: { "analyze": true, "reasoning": "Running optimization after bulk task deletion to reclaim space and update query statistics for better performance." } |
| repair_relationships | Fix task hierarchy and dependency issues. Repairs Performed: - Resolves circular dependencies - Fixes broken parent-child links - Removes invalid dependencies - Updates status inconsistencies - Corrects metadata anomalies When to Use: - After failed operations - Fixing circular dependencies - Resolving orphaned tasks - Maintaining task integrity - Before major updates Best Practices: - Run dry-run first - Fix critical paths - Verify results - Document changes - Update affected tasks - Monitor cascading effects Validation Steps: - Path integrity check - Dependency cycle detection - Parent-child validation - Status consistency check - Metadata validation Example: { "dryRun": true, "reasoning": "Checking for relationship issues after recent bulk operations. Using dry-run to assess the scope of necessary repairs before applying fixes." } |
| list_templates | List available task templates with descriptions and metadata |
| use_template | Instantiate a template with provided variables |
| get_template_info | Get detailed information about a template including its variables and tasks |