n8n-workflow-builder-mcp 0.1.0

package/.roo/rules/dev_workflow.md

@@ -0,0 +1,219 @@
+---
+description: Guide for using Task Master to manage task-driven development workflows
+globs: **/*
+alwaysApply: true
+---
+# Task Master Development Workflow
+
+This guide outlines the typical process for using Task Master to manage software development projects.
+
+## Primary Interaction: MCP Server vs. CLI
+
+Task Master offers two primary ways to interact:
+
+1.  **MCP Server (Recommended for Integrated Tools)**:
+    - For AI agents and integrated development environments (like Roo Code), interacting via the **MCP server is the preferred method**.
+    - The MCP server exposes Task Master functionality through a set of tools (e.g., `get_tasks`, `add_subtask`).
+    - This method offers better performance, structured data exchange, and richer error handling compared to CLI parsing.
+    - Refer to [`mcp.md`](mdc:.roo/rules/mcp.md) for details on the MCP architecture and available tools.
+    - A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in [`taskmaster.md`](mdc:.roo/rules/taskmaster.md).
+    - **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
+
+2.  **`task-master` CLI (For Users & Fallback)**:
+    - The global `task-master` command provides a user-friendly interface for direct terminal interaction.
+    - It can also serve as a fallback if the MCP server is inaccessible or a specific function isn't exposed via MCP.
+    - Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
+    - The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
+    - Refer to [`taskmaster.md`](mdc:.roo/rules/taskmaster.md) for a detailed command reference.
+
+## Standard Development Workflow Process
+
+-   Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) to generate initial tasks.json
+-   Begin coding sessions with `get_tasks` / `task-master list` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) to see current tasks, status, and IDs
+-   Determine the next task to work on using `next_task` / `task-master next` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)).
+-   Analyze task complexity with `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) before breaking down tasks
+-   Review complexity report using `complexity_report` / `task-master complexity-report` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)).
+-   Select tasks based on dependencies (all marked 'done'), priority level, and ID order
+-   Clarify tasks by checking task files in tasks/ directory or asking for user input
+-   View specific task details using `get_task` / `task-master show <id>` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) to understand implementation requirements
+-   Break down complex tasks using `expand_task` / `task-master expand --id=<id> --force --research` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) with appropriate flags like `--force` (to replace existing subtasks) and `--research`.
+-   Clear existing subtasks if needed using `clear_subtasks` / `task-master clear-subtasks --id=<id>` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) before regenerating
+-   Implement code following task details, dependencies, and project standards
+-   Verify tasks according to test strategies before marking as complete (See [`tests.md`](mdc:.roo/rules/tests.md))
+-   Mark completed tasks with `set_task_status` / `task-master set-status --id=<id> --status=done` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md))
+-   Update dependent tasks when implementation differs from original plan using `update` / `task-master update --from=<id> --prompt="..."` or `update_task` / `task-master update-task --id=<id> --prompt="..."` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md))
+-   Add new tasks discovered during implementation using `add_task` / `task-master add-task --prompt="..." --research` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)).
+-   Add new subtasks as needed using `add_subtask` / `task-master add-subtask --parent=<id> --title="..."` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)).
+-   Append notes or details to subtasks using `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='Add implementation notes here...\nMore details...'` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)).
+-   Generate task files with `generate` / `task-master generate` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) after updating tasks.json
+-   Maintain valid dependency structure with `add_dependency`/`remove_dependency` tools or `task-master add-dependency`/`remove-dependency` commands, `validate_dependencies` / `task-master validate-dependencies`, and `fix_dependencies` / `task-master fix-dependencies` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) when needed
+-   Respect dependency chains and task priorities when selecting work
+-   Report progress regularly using `get_tasks` / `task-master list`
+
+## Task Complexity Analysis
+
+-   Run `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) for comprehensive analysis
+-   Review complexity report via `complexity_report` / `task-master complexity-report` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) for a formatted, readable version.
+-   Focus on tasks with highest complexity scores (8-10) for detailed breakdown
+-   Use analysis results to determine appropriate subtask allocation
+-   Note that reports are automatically used by the `expand_task` tool/command
+
+## Task Breakdown Process
+
+-   Use `expand_task` / `task-master expand --id=<id>`. It automatically uses the complexity report if found, otherwise generates default number of subtasks.
+-   Use `--num=<number>` to specify an explicit number of subtasks, overriding defaults or complexity report recommendations.
+-   Add `--research` flag to leverage Perplexity AI for research-backed expansion.
+-   Add `--force` flag to clear existing subtasks before generating new ones (default is to append).
+-   Use `--prompt="<context>"` to provide additional context when needed.
+-   Review and adjust generated subtasks as necessary.
+-   Use `expand_all` tool or `task-master expand --all` to expand multiple pending tasks at once, respecting flags like `--force` and `--research`.
+-   If subtasks need complete replacement (regardless of the `--force` flag on `expand`), clear them first with `clear_subtasks` / `task-master clear-subtasks --id=<id>`.
+
+## Implementation Drift Handling
+
+-   When implementation differs significantly from planned approach
+-   When future tasks need modification due to current implementation choices
+-   When new dependencies or requirements emerge
+-   Use `update` / `task-master update --from=<futureTaskId> --prompt='<explanation>\nUpdate context...' --research` to update multiple future tasks.
+-   Use `update_task` / `task-master update-task --id=<taskId> --prompt='<explanation>\nUpdate context...' --research` to update a single specific task.
+
+## Task Status Management
+
+-   Use 'pending' for tasks ready to be worked on
+-   Use 'done' for completed and verified tasks
+-   Use 'deferred' for postponed tasks
+-   Add custom status values as needed for project-specific workflows
+
+## Task Structure Fields
+
+- **id**: Unique identifier for the task (Example: `1`, `1.1`)
+- **title**: Brief, descriptive title (Example: `"Initialize Repo"`)
+- **description**: Concise summary of what the task involves (Example: `"Create a new repository, set up initial structure."`)
+- **status**: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
+- **dependencies**: IDs of prerequisite tasks (Example: `[1, 2.1]`)
+    - Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
+    - This helps quickly identify which prerequisite tasks are blocking work
+- **priority**: Importance level (Example: `"high"`, `"medium"`, `"low"`)
+- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`) 
+- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`) 
+- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`) 
+- Refer to task structure details (previously linked to `tasks.md`).
+
+## Configuration Management (Updated)
+
+Taskmaster configuration is managed through two main mechanisms:
+
+1.  **`.taskmasterconfig` File (Primary):**
+    *   Located in the project root directory.
+    *   Stores most configuration settings: AI model selections (main, research, fallback), parameters (max tokens, temperature), logging level, default subtasks/priority, project name, etc.
+    *   **Managed via `task-master models --setup` command.** Do not edit manually unless you know what you are doing.
+    *   **View/Set specific models via `task-master models` command or `models` MCP tool.**
+    *   Created automatically when you run `task-master models --setup` for the first time.
+
+2.  **Environment Variables (`.env` / `mcp.json`):**
+    *   Used **only** for sensitive API keys and specific endpoint URLs.
+    *   Place API keys (one per provider) in a `.env` file in the project root for CLI usage.
+    *   For MCP/Roo Code integration, configure these keys in the `env` section of `.roo/mcp.json`.
+    *   Available keys/variables: See `assets/env.example` or the Configuration section in the command reference (previously linked to `taskmaster.md`).
+
+**Important:** Non-API key settings (like model selections, `MAX_TOKENS`, `LOG_LEVEL`) are **no longer configured via environment variables**. Use the `task-master models` command (or `--setup` for interactive configuration) or the `models` MCP tool.
+**If AI commands FAIL in MCP** verify that the API key for the selected provider is present in the `env` section of `.roo/mcp.json`.
+**If AI commands FAIL in CLI** verify that the API key for the selected provider is present in the `.env` file in the root of the project.
+
+## Determining the Next Task
+
+- Run `next_task` / `task-master next` to show the next task to work on.
+- The command identifies tasks with all dependencies satisfied
+- Tasks are prioritized by priority level, dependency count, and ID
+- The command shows comprehensive task information including:
+    - Basic task details and description
+    - Implementation details
+    - Subtasks (if they exist)
+    - Contextual suggested actions
+- Recommended before starting any new development work
+- Respects your project's dependency structure
+- Ensures tasks are completed in the appropriate sequence
+- Provides ready-to-use commands for common task actions
+
+## Viewing Specific Task Details
+
+- Run `get_task` / `task-master show <id>` to view a specific task.
+- Use dot notation for subtasks: `task-master show 1.2` (shows subtask 2 of task 1)
+- Displays comprehensive information similar to the next command, but for a specific task
+- For parent tasks, shows all subtasks and their current status
+- For subtasks, shows parent task information and relationship
+- Provides contextual suggested actions appropriate for the specific task
+- Useful for examining task details before implementation or checking status
+
+## Managing Task Dependencies
+
+- Use `add_dependency` / `task-master add-dependency --id=<id> --depends-on=<id>` to add a dependency.
+- Use `remove_dependency` / `task-master remove-dependency --id=<id> --depends-on=<id>` to remove a dependency.
+- The system prevents circular dependencies and duplicate dependency entries
+- Dependencies are checked for existence before being added or removed
+- Task files are automatically regenerated after dependency changes
+- Dependencies are visualized with status indicators in task listings and files
+
+## Iterative Subtask Implementation
+
+Once a task has been broken down into subtasks using `expand_task` or similar methods, follow this iterative process for implementation:
+
+1.  **Understand the Goal (Preparation):**
+    *   Use `get_task` / `task-master show <subtaskId>` (see [`taskmaster.md`](mdc:.roo/rules/taskmaster.md)) to thoroughly understand the specific goals and requirements of the subtask.
+
+2.  **Initial Exploration & Planning (Iteration 1):**
+    *   This is the first attempt at creating a concrete implementation plan.
+    *   Explore the codebase to identify the precise files, functions, and even specific lines of code that will need modification.
+    *   Determine the intended code changes (diffs) and their locations.
+    *   Gather *all* relevant details from this exploration phase.
+
+3.  **Log the Plan:**
+    *   Run `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<detailed plan>'`.
+    *   Provide the *complete and detailed* findings from the exploration phase in the prompt. Include file paths, line numbers, proposed diffs, reasoning, and any potential challenges identified. Do not omit details. The goal is to create a rich, timestamped log within the subtask's `details`.
+
+4.  **Verify the Plan:**
+    *   Run `get_task` / `task-master show <subtaskId>` again to confirm that the detailed implementation plan has been successfully appended to the subtask's details.
+
+5.  **Begin Implementation:**
+    *   Set the subtask status using `set_task_status` / `task-master set-status --id=<subtaskId> --status=in-progress`.
+    *   Start coding based on the logged plan.
+
+6.  **Refine and Log Progress (Iteration 2+):**
+    *   As implementation progresses, you will encounter challenges, discover nuances, or confirm successful approaches.
+    *   **Before appending new information**: Briefly review the *existing* details logged in the subtask (using `get_task` or recalling from context) to ensure the update adds fresh insights and avoids redundancy.
+    *   **Regularly** use `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<update details>\n- What worked...\n- What didn't work...'` to append new findings.
+    *   **Crucially, log:**
+        *   What worked ("fundamental truths" discovered).
+        *   What didn't work and why (to avoid repeating mistakes).
+        *   Specific code snippets or configurations that were successful.
+        *   Decisions made, especially if confirmed with user input.
+        *   Any deviations from the initial plan and the reasoning.
+    *   The objective is to continuously enrich the subtask's details, creating a log of the implementation journey that helps the AI (and human developers) learn, adapt, and avoid repeating errors.
+
+7.  **Review & Update Rules (Post-Implementation):**
+    *   Once the implementation for the subtask is functionally complete, review all code changes and the relevant chat history.
+    *   Identify any new or modified code patterns, conventions, or best practices established during the implementation.
+    *   Create new or update existing rules following internal guidelines (previously linked to `cursor_rules.md` and `self_improve.md`).
+
+8.  **Mark Task Complete:**
+    *   After verifying the implementation and updating any necessary rules, mark the subtask as completed: `set_task_status` / `task-master set-status --id=<subtaskId> --status=done`.
+
+9.  **Commit Changes (If using Git):**
+    *   Stage the relevant code changes and any updated/new rule files (`git add .`).
+    *   Craft a comprehensive Git commit message summarizing the work done for the subtask, including both code implementation and any rule adjustments.
+    *   Execute the commit command directly in the terminal (e.g., `git commit -m 'feat(module): Implement feature X for subtask <subtaskId>\n\n- Details about changes...\n- Updated rule Y for pattern Z'`).
+    *   Consider if a Changeset is needed according to internal versioning guidelines (previously linked to `changeset.md`). If so, run `npm run changeset`, stage the generated file, and amend the commit or create a new one.
+
+10. **Proceed to Next Subtask:**
+    *   Identify the next subtask (e.g., using `next_task` / `task-master next`).
+
+## Code Analysis & Refactoring Techniques
+
+- **Top-Level Function Search**:
+    - Useful for understanding module structure or planning refactors.
+    - Use grep/ripgrep to find exported functions/constants:
+      `rg "export (async function|function|const) \w+"` or similar patterns.
+    - Can help compare functions between files during migrations or identify potential naming conflicts.
+
+---
+*This workflow provides a general guideline. Adapt it based on your specific project needs and team practices.*

package/.roo/rules/mcp.md

@@ -0,0 +1,430 @@
+---
+description:
+globs:
+alwaysApply: false
+---
+# MCP Server Implementation Best Practices
+
+These guidelines ensure our MCP server follows the latest Model Context Protocol (2025) standards, providing a consistent API experience for AI model interactions.
+
+## Core Architecture
+
+- **Follow JSON-RPC 2.0 Message Format**
+  - All server responses must include `jsonrpc: "2.0"`, `id`, and either `result` or `error`
+  - Error objects must contain `code` and `message` properties
+  - Include proper request IDs in all responses
+
+  ```javascript
+  // ✅ DO: Format responses following JSON-RPC 2.0
+  const createJsonRpcResponse = (id, result) => ({
+    jsonrpc: "2.0",
+    id,
+    result
+  });
+
+  const createJsonRpcError = (id, code, message) => ({
+    jsonrpc: "2.0",
+    id,
+    error: { code, message }
+  });
+  
+  // ❌ DON'T: Return arbitrary JSON structures
+  res.json({ success: true, data: result });
+  ```
+
+- **Implement Proper Transport Layers**
+  - Support standard MCP transports (Stdio, HTTP, WebSockets)
+  - Transport selection should be configurable
+  - Handle connection lifecycle events properly
+
+  ```javascript
+  // ✅ DO: Use standardized transport implementations
+  const { StdioServerTransport } = require('@modelcontextprotocol/sdk/server/stdio.js');
+  const transport = new StdioServerTransport();
+  server.connect(transport);
+  
+  // ❌ DON'T: Create custom message formats
+  process.stdin.on('data', (data) => {
+    // Custom parsing logic...
+  });
+  ```
+
+- **Implement Capability Negotiation**
+  - Explicitly declare supported capabilities (tools, resources, prompts, sampling)
+  - Follow the MCP specification version declaration
+  - Respond to capability request messages
+
+  ```javascript
+  // ✅ DO: Properly declare server capabilities
+  app.post('/mcp/capabilities', (req, res) => {
+    res.status(200).json({
+      jsonrpc: "2.0",
+      id: req.body.id,
+      result: {
+        capabilities: {
+          tools: true,
+          resources: true,
+          prompts: false,
+          sampling: false
+        },
+        version: "2025-03-26"
+      }
+    });
+  });
+  ```
+
+## Tool Definitions
+
+- **Standardize Tool Schemas**
+  - Each tool must have `name`, `description`, and `parameters`
+  - Parameter validation must follow JSON Schema (via Zod, Ajv, etc.)
+  - Include required vs. optional parameter designation
+  - Document expected inputs and outputs
+
+  ```javascript
+  // ✅ DO: Use well-structured tool definitions
+  const createTool = (description, parameters, execute) => ({
+    description,
+    parameters: {
+      type: 'object',
+      properties: parameters,
+      required: Object.keys(parameters).filter(key => !parameters[key].optional)
+    },
+    execute,
+    required_on_execute: true,
+    categories: ['workflow'],
+    parallelizable: false
+  });
+  
+  // ❌ DON'T: Use loosely typed parameters
+  const simpleTool = {
+    run: (params) => {
+      // No validation before execution
+    }
+  };
+  ```
+
+- **Implement Comprehensive Parameter Validation**
+  - Validate all parameters before tool execution
+  - Provide descriptive error messages for invalid parameters
+  - Include type checking, bounds checking, and format validation
+  - Support nested objects and array validation
+
+  ```javascript
+  // ✅ DO: Validate parameters with detailed errors
+  const validate = ajv.compile(schema);
+  const valid = validate(params);
+  
+  if (!valid) {
+    const errors = validate.errors.map(err =>
+      `${err.instancePath} ${err.message}`
+    ).join('; ');
+    
+    throw new Error(`Invalid parameters: ${errors}`);
+  }
+  
+  // ❌ DON'T: Use loose validation or manual checks
+  if (!params.name) {
+    throw new Error('Name is required');
+  }
+  ```
+
+## Security
+
+- **Implement Robust Authentication & Authorization**
+  - Authenticate all MCP requests
+  - Apply authorization rules for tool execution
+  - Log authentication failures
+  - Use refresh tokens and proper session management
+
+  ```javascript
+  // ✅ DO: Implement proper auth with tool-specific authorization
+  const enhancedAuth = (req, res, next) => {
+    // Validate authentication
+    authenticate(req, res, (err) => {
+      if (err) return next(err);
+      
+      // Add authorization check
+      const { toolInfo } = req;
+      if (toolInfo && !authorizeToolAccess(req.user, toolInfo)) {
+        return res.status(403).json({
+          error: {
+            message: 'Not authorized to use this tool',
+            code: 'UNAUTHORIZED_TOOL_ACCESS'
+          }
+        });
+      }
+      next();
+    });
+  };
+  
+  // ❌ DON'T: Use simple global authentication without tool-specific authorization
+  app.use(basicAuthMiddleware);
+  ```
+
+- **Secure Configuration Management**
+  - Store secrets in environment variables or secure storage
+  - Support multiple environments (dev, staging, prod)
+  - Never hardcode credentials
+  - Use separate configuration files for non-sensitive settings
+
+  ```javascript
+  // ✅ DO: Use environment variables for secrets
+  require('dotenv').config();
+  const apiKey = process.env.API_KEY;
+  
+  // ❌ DON'T: Hardcode credentials
+  const apiKey = 'sk_live_abcdef123456';
+  ```
+
+## Error Handling
+
+- **Implement Consistent Error Responses**
+  - Use standardized error codes
+  - Provide human-readable error messages
+  - Include debugging information in development
+  - Mask sensitive data in error responses
+
+  ```javascript
+  // ✅ DO: Return structured error responses
+  const createErrorResponse = (message, code, status = 500) => {
+    logger.error(`MCP Error: ${code} - ${message}`);
+    
+    return {
+      error: {
+        message,
+        code
+      },
+      status
+    };
+  };
+  
+  // ❌ DON'T: Return inconsistent error formats
+  res.status(500).json({ message: "Something went wrong" });
+  ```
+
+- **Log Errors with Context**
+  - Include request context in error logs
+  - Log stack traces in development
+  - Use structured logging formats (JSON)
+  - Implement different log levels (debug, info, error)
+
+  ```javascript
+  // ✅ DO: Log detailed error context
+  logger.error({
+    message: `Tool execution error: ${error.message}`,
+    toolName: req.toolInfo.name,
+    parameters: maskSensitiveData(req.toolInfo.parameters),
+    errorCode: error.code,
+    stack: process.env.NODE_ENV === 'development' ? error.stack : undefined
+  });
+  
+  // ❌ DON'T: Log minimal information
+  console.error("Error:", error.message);
+  ```
+
+## Performance & Scalability
+
+- **Implement Rate Limiting**
+  - Limit requests per client/API key
+  - Apply graduated rate limits based on client tier
+  - Return standard 429 responses when limits exceeded
+  - Include rate limit information in response headers
+
+  ```javascript
+  // ✅ DO: Implement proper rate limiting
+  app.use(rateLimit({
+    windowMs: 15 * 60 * 1000, // 15 minutes
+    max: 100, // limit each IP to 100 requests per windowMs
+    standardHeaders: true, // Return rate limit info in the `RateLimit-*` headers
+    handler: (req, res) => {
+      const error = createErrorResponse(
+        'Too many requests, please try again later.',
+        'RATE_LIMIT_EXCEEDED',
+        429
+      );
+      res.status(error.status).json({ error: error.error });
+    }
+  }));
+  ```
+
+- **Optimize Tool Execution**
+  - Implement caching for frequently used tool results
+  - Use connection pooling for external API calls
+  - Apply timeouts for long-running operations
+  - Consider async execution for non-blocking operations
+
+  ```javascript
+  // ✅ DO: Implement caching for expensive operations
+  const cache = new NodeCache({ stdTTL: 300 }); // 5 minute default TTL
+  
+  const getCachedOrFetch = async (key, fetchFn) => {
+    const cached = cache.get(key);
+    if (cached) return cached;
+    
+    const result = await fetchFn();
+    cache.set(key, result);
+    return result;
+  };
+  ```
+
+## Testing & Reliability
+
+- **Create Comprehensive Test Suites**
+  - Test all tool endpoints
+  - Include positive and negative test cases
+  - Test parameter validation logic
+  - Mock external dependencies
+
+  ```javascript
+  // ✅ DO: Test success and error cases
+  it('should return 400 if tool name is missing', async () => {
+    const response = await request(app)
+      .post('/mcp/execute')
+      .send({ parameters: {} });
+    
+    expect(response.status).toBe(400);
+    expect(response.body).toHaveProperty('error');
+    expect(response.body.error).toHaveProperty('code', 'MISSING_TOOL_NAME');
+  });
+  
+  it('should process valid tool execution request', async () => {
+    const response = await request(app)
+      .post('/mcp/execute')
+      .send({ 
+        name: 'workflow_list', 
+        parameters: { limit: 10 } 
+      });
+    
+    expect(response.status).toBe(200);
+    expect(response.body).toHaveProperty('tool', 'workflow_list');
+  });
+  ```
+
+- **Implement Health Checks**
+  - Create a health endpoint that verifies all dependencies
+  - Include version information in health response
+  - Check external service connectivity
+  - Implement readiness and liveness probes
+
+  ```javascript
+  // ✅ DO: Implement detailed health checks
+  app.get('/health', async (req, res) => {
+    try {
+      // Check database connection
+      await db.ping();
+      
+      // Check external API connectivity
+      await externalApi.status();
+      
+      res.status(200).json({ 
+        status: 'ok', 
+        version: '0.1.0',
+        uptime: process.uptime(),
+        timestamp: new Date().toISOString()
+      });
+    } catch (error) {
+      res.status(503).json({ 
+        status: 'error', 
+        message: 'Service unavailable',
+        details: error.message
+      });
+    }
+  });
+  ```
+
+## Resources & Context
+
+- **Implement Resource Endpoints**
+  - Expose useful context via resource endpoints
+  - Structure resources hierarchically
+  - Support resource retrieval by ID
+  - Include metadata with resources
+
+  ```javascript
+  // ✅ DO: Implement proper resource endpoints
+  app.post('/mcp/resources/list', authenticate, (req, res) => {
+    const resources = [
+      { id: 'workflow-templates', name: 'Workflow Templates', type: 'collection' },
+      { id: 'node-types', name: 'Node Types', type: 'collection' },
+      { id: 'integration-docs', name: 'Integration Documentation', type: 'document' }
+    ];
+    
+    const response = createJsonRpcResponse(req.body.id, { resources });
+    res.status(200).json(response);
+  });
+  ```
+
+- **Support Context Awareness**
+  - Allow tools to access contextual information
+  - Share context between related tool calls
+  - Maintain session state when appropriate
+  - Document context dependencies
+
+  ```javascript
+  // ✅ DO: Implement context-aware tools
+  const executeWorkflow = async (params, context) => {
+    // Access the current user context
+    const userId = context.user.id;
+    
+    // Access previously established session information
+    const sessionData = context.session.get('workflowData') || {};
+    
+    // Store results for future tool calls
+    context.session.set('lastExecutionId', executionId);
+    
+    return result;
+  };
+  ```
+
+## Documentation
+
+- **Generate API Documentation**
+  - Create OpenAPI/Swagger documentation
+  - Document all tools and their parameters
+  - Include example requests and responses
+  - Provide error code references
+
+  ```javascript
+  // ✅ DO: Use OpenAPI annotations for documentation
+  /**
+   * @openapi
+   * /mcp/execute:
+   *   post:
+   *     summary: Execute an MCP tool
+   *     requestBody:
+   *       required: true
+   *       content:
+   *         application/json:
+   *           schema:
+   *             type: object
+   *             required:
+   *               - name
+   *             properties:
+   *               name:
+   *                 type: string
+   *                 description: Tool name in format "category_action"
+   *               parameters:
+   *                 type: object
+   *                 description: Tool-specific parameters
+   */
+  ```
+
+- **Provide Clear Tool Documentation**
+  - Document each tool's purpose and behavior
+  - Explain parameter requirements clearly
+  - Provide usage examples
+  - Document potential errors and resolutions
+
+  ```javascript
+  // ✅ DO: Document tools thoroughly
+  /**
+   * Create a new n8n workflow
+   * 
+   * @param {Object} parameters - Tool parameters
+   * @param {string} parameters.name - Name of the workflow
+   * @param {boolean} [parameters.active=false] - Whether the workflow should be active
+   * @returns {Promise<Object>} Created workflow details
+   * @throws {Error} If workflow creation fails
+   */
+  ```