Add MCP server configuration and initialization to TUI

.cursor/rules/closing-issue-workflow.mdc

@@ -0,0 +1,16 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+When closing an issue:
+
+1.  Confirm with the user that the issue is ready to be closed.
+2.  Make sure to run `goimports -w .` and `go fmt ./...` before your commit any code.
+3.  Run tests by executing the `make test` command in the terminal using `run_terminal_cmd`.
+4.  **If tests fail:**
+    *   You have to fix the tests.
+    *   DO NOT proceed with closing the issue.
+5.  **If tests pass:**
+    *   Proceed with committing and pushing the changes, follow the `commit-and-push-workflow`.
+    *   After the `commit-and-push-workflow` is successful, then use the `mcp_github_update_issue` tool to change the state of the issue to 'closed'. Make sure to specify the `owner` as `giantswarm`, `repo` as `envctl`, and the correct `issue_number`.

.cursor/rules/commit-and-push-workflow.mdc

@@ -0,0 +1,23 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+When committing and pushing changes after an issue is successfully closed and tests have passed:
+
+1.  **Get current Git branch:**
+    *   Run `git rev-parse --abbrev-ref HEAD` using `run_terminal_cmd` to get the current branch name. Let this be `current_branch`.
+2.  Let the closed issue number be `issue_num` and its title be `issue_title`.
+3.  **Branch Management:**
+    *   Set `target_branch` to `current_branch`.
+    *   If `current_branch` is `main` or `master`:
+        *   Generate a new branch name. The suggested pattern is `<type>/issue-<issue_num>-<slugified_issue_title>`, where `<type>` could be `feature`, `fix`, `refactor`, etc., based on the nature of the work. I will generate a slug from the issue title (e.g., lowercase, hyphens for spaces, remove special characters). Example: `refactor/issue-37-getpodnameforportforward-context-handling`.
+        *   Run `git checkout -b <new_branch_name>` using `run_terminal_cmd`.
+        *   Set `target_branch` to this `<new_branch_name>`.
+        *   Inform the user that a new branch `<new_branch_name>` has been created and checked out.
+4.  **Stage changes:** Run `git add .` using `run_terminal_cmd`.
+5.  **Commit changes:**
+    *   Construct a commit message. The suggested pattern is: `<CommitType>: <issue_title> (closes #<issue_num>)`. Example: `Refactor: Refactor getPodNameForPortForward for clarity, scope, and context handling (closes #37)`. The `<CommitType>` (e.g., Refactor, Fix, Feat) should match the nature of the work.
+    *   Run `git commit -m "<commit_message>"` using `run_terminal_cmd`.
+6.  **Push changes:** Run `git push origin <target_branch>` using `run_terminal_cmd`.
+7.  Inform the user that the changes have been committed to `<target_branch>` and pushed to origin.

.cursor/rules/creating-issue-workflow.mdc

@@ -0,0 +1,10 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+When creating a new issue:
+
+1. Gather the necessary information for the issue: `title` and `body`. `labels` and `assignees` can also be included if provided.
+2. Use the `create_issue` tool to create the new issue in the `giantswarm/envctl` repository. Set `owner` to `giantswarm` and `repo` to `envctl`.
+3. Announce the new issue (title and number) in the chat after it has been created.

.cursor/rules/next-issue-workflow.mdc

@@ -0,0 +1,13 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+When beginning work on a new task:
+
+1. Use the `list_issues` tool to fetch the list of open issues from the `giantswarm/envctl` repository, ordered by issue number descending (newest first).
+2. Decide which is the next best issue in that list (still open issue) and use the `get_issue` tool with its issue number to retrieve full details.
+3. Summarize that issue (title, number, body, key tasks) in the chat before starting implementation steps.
+4. After summarizing, outline the approach for addressing the issue and continue with the implementation.
+
+This rule ensures every new coding session starts with up-to-date context from the roadmap.

.cursor/rules/testing-guidelines.mdc

@@ -0,0 +1,17 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+## Testing Guidelines
+
+When implementing new features or fixing bugs, ensure the following testing criteria are met:
+To run all tests and linters, use the `make test` command in your terminal. If you changed or added view tests use the terminal to execute 'NO_COLOR=true go test ./internal/tui/view/... -update' so that the view tests have been updated not to use any colors.
+
+- New functionality must be covered by appropriate unit, integration, or end-to-end tests.
+- Existing tests must be updated to reflect any changes in behavior.
+- If the changes affect the TUI views:
+    - Corresponding golden files (located in `internal/tui/view/testdata/*.golden`) must be generated or updated.
+    - This is typically done by running `go test ./internal/tui/view/... -update`.
+    - The updated golden files must be carefully reviewed and verified to ensure they reflect the intended visual changes.
+- Strive to meet or improve test coverage for the modified packages. There should be a minimum of 80% test coverage.

.envctl/config.yaml.example

@@ -0,0 +1,14 @@
+# Project-specific configuration for envctl
+# Copy this to .envctl/config.yaml and update with your values
+
+mcpServers:
+  - name: grafana
+    type: localCommand
+    enabledByDefault: true
+    icon: "📊"
+    category: "Monitoring"
+    command: ["mcp-grafana"]
+    env:
+      GRAFANA_URL: "http://localhost:3000"
+      GRAFANA_API_KEY: "YOUR_GRAFANA_SERVICE_ACCOUNT_TOKEN_HERE"
+    requiresPortForwards: ["mc-grafana"] 

.github/pull_request_template.md

@@ -14,6 +14,12 @@
 
 ### What is needed from the reviewers?
 
+### Testing
+
+- [ ] New functionality is covered by unit/integration tests.
+- [ ] Existing tests have been updated to reflect changes.
+- [ ] For UI changes involving golden files (e.g., in `internal/tui/view/testdata/`), new files have been generated/updated (e.g., by running `go test ./internal/tui/view/... -update`) and meticulously verified.
+
 ### Do the docs need to be updated?
 
 ### Should this change be mentioned in the release notes?

.github/workflows/docker-mcp-servers.yaml

@@ -0,0 +1,73 @@
+name: Build MCP Server Docker Images
+
+on:
+  push:
+    branches:
+      - main
+      - master
+    paths:
+      - 'docker/mcp-servers/**'
+      - '.github/workflows/docker-mcp-servers.yaml'
+  pull_request:
+    paths:
+      - 'docker/mcp-servers/**'
+      - '.github/workflows/docker-mcp-servers.yaml'
+  release:
+    types: [published]
+
+env:
+  REGISTRY: ghcr.io
+  IMAGE_PREFIX: ${{ github.repository_owner }}/mcp-server
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        server: [kubernetes, prometheus, grafana]
+
+    permissions:
+      contents: read
+      packages: write
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Log in to GitHub Container Registry
+        if: github.event_name != 'pull_request'
+        uses: docker/login-action@v3
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Extract metadata
+        id: meta
+        uses: docker/metadata-action@v5
+        with:
+          images: ${{ env.REGISTRY }}/${{ env.IMAGE_PREFIX }}-${{ matrix.server }}
+          tags: |
+            type=ref,event=branch
+            type=ref,event=pr
+            type=semver,pattern={{version}}
+            type=semver,pattern={{major}}.{{minor}}
+            type=raw,value=latest,enable={{is_default_branch}}
+
+      - name: Build and push Docker image
+        uses: docker/build-push-action@v5
+        with:
+          context: docker/mcp-servers/${{ matrix.server }}
+          push: ${{ github.event_name != 'pull_request' }}
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
+
+      - name: Test image (if built)
+        if: github.event_name == 'pull_request'
+        run: |
+          docker run --rm ${{ env.REGISTRY }}/${{ env.IMAGE_PREFIX }}-${{ matrix.server }}:pr-${{ github.event.pull_request.number }} --version || echo "No version command available" 

.gitignore

@@ -1,2 +1,3 @@
 envctl
 dist/
+.envctl/config.yaml

CHANGELOG.md

@@ -0,0 +1,19 @@
+# Changelog
+
+## [Unreleased]
+
+### Added
+- Support for containerized MCP servers (#41)
+  - New `type: container` option for MCP server definitions
+  - Docker runtime implementation in `internal/containerizer` package
+  - Container lifecycle management (pull, start, stop, logs, port detection)
+  - Example Dockerfiles for kubernetes, prometheus, and grafana MCP servers
+  - GitHub Actions workflow for building and publishing container images
+  - Documentation for containerized MCP server configuration
+
+### Changed
+- Updated `MCPServerDefinition` to support container-specific fields
+- Modified `StartAllMCPServers` to handle both local command and container types
+- Enhanced startup logic to initialize container runtime when needed
+
+## [Previous versions...] 

Makefile

@@ -57,6 +57,13 @@ check: lint-yaml ## Run YAML linter
 
 ##@ Testing
 
+.PHONY: test
+test: ## Run go test and go vet
+	@echo "Running Go tests (with NO_COLOR=true)..."
+	@NO_COLOR=true go test -cover ./...
+	@echo "Running go vet..."
+	@go vet ./...
+
 # Note: These targets require Docker and 'act' to be installed.
 # See: https://github.com/nektos/act#installation
 

README.md

@@ -9,7 +9,7 @@ It automates the process of logging into clusters via Teleport (`tsh`) and setti
 ## Features ✨
 
 *   **Simplified Connection:** Connect to management and workload clusters with a single command.
-*   **Automatic Context Switching:** Sets your `kubectl` context correctly.
+*   **Automatic Context Switching:** Sets your Kubernetes context correctly.
 *   **Port-Forwarding Management:** 
     *   Prometheus and Grafana services (always from the Management Cluster)
     *   Alloy Metrics (from the Workload Cluster if specified, otherwise from the Management Cluster)
@@ -31,7 +31,12 @@ Before using `envctl`, ensure you have the following installed and configured:
 
 1.  **Go:** Version 1.21 or later ([Installation Guide](https://go.dev/doc/install)).
 2.  **Teleport Client (`tsh`):** You need `tsh` installed and logged into your Giant Swarm Teleport proxy.
-3.  **`kubectl`:** The Kubernetes command-line tool.
+3.  **`mcp-proxy`:** This tool is used by `envctl` to proxy your actual MCP servers. ([Installation Guide](https://github.com/sparfenyuk/mcp-proxy#installation)).
+4.  **Underlying MCP Server Executables:** `envctl` expects specific MCP server commands to be available in your PATH, as it will invoke them via `mcp-proxy`. These are typically:
+    *   For Kubernetes: `npx mcp-server-kubernetes` (requires Node.js and `npx`)
+    *   For Prometheus: `uvx mcp-server-prometheus` (requires `uv` and the Python-based `mcp-server-prometheus`)
+    *   For Grafana: `uvx mcp-server-grafana` (requires `uv` and the Python-based `mcp-server-grafana` - if you use a Grafana MCP).
+    (Ensure `uv` is installed if you intend to use `uvx` for these servers: [uv Installation](https://github.com/astral-sh/uv#installation)).
 
 ## Installation 🛠️
 
@@ -90,7 +95,7 @@ envctl self-update
 # Use the CLI mode without TUI (for scripts or CI environments)
 # This mode will:
 # - Log into the specified cluster(s) via tsh.
-# - Set the kubectl context.
+# - Sets the Kubernetes context.
 # - Start port-forwarding for:
 #   - Prometheus (MC) on localhost:8080
 #   - Grafana (MC) on localhost:3000
@@ -116,7 +121,7 @@ envctl connect <management-cluster> [workload-cluster-shortname] --no-tui
 
     *   Launches an interactive terminal UI
     *   Logs into `myinstallation` via `tsh kube login myinstallation`.
-    *   Sets the current `kubectl` context to `teleport.giantswarm.io-myinstallation`.
+    *   Sets the current Kubernetes context to `teleport.giantswarm.io-myinstallation`.
     *   Starts port-forwarding for Prometheus (MC) on `localhost:8080`, Grafana (MC) on `localhost:3000`, and Alloy Metrics (MC) on `localhost:12345`.
     *   Displays cluster health and connection status
     *   Allows management of port-forwards and contexts
@@ -129,7 +134,7 @@ envctl connect <management-cluster> [workload-cluster-shortname] --no-tui
 
     *   Logs into `myinstallation` via `tsh kube login myinstallation`.
     *   Logs into the *full* workload cluster name (`myinstallation-myworkloadcluster`) via `tsh`.
-    *   Sets the current `kubectl` context to the *full* workload cluster name (`teleport.giantswarm.io-myinstallation-myworkloadcluster`).
+    *   Sets the current Kubernetes context to the *full* workload cluster name (`teleport.giantswarm.io-myinstallation-myworkloadcluster`).
     *   Starts port-forwarding for Prometheus using the *management cluster* context (`teleport.giantswarm.io-myinstallation`) to `localhost:8080`.
     *   Starts port-forwarding for Grafana using the *management cluster* context (`teleport.giantswarm.io-myinstallation`) to `localhost:3000`.
     *   Starts port-forwarding for Alloy metrics using the *workload cluster* context (`teleport.giantswarm.io-myinstallation-myworkloadcluster`) to `localhost:12345`.
@@ -153,17 +158,19 @@ When running `envctl connect`, the Terminal User Interface (TUI) provides a visu
 
 | Key          | Action                                   |
 |--------------|------------------------------------------|
-| Tab          | Navigate to next panel                   |
-| Shift+Tab    | Navigate to previous panel               |
+| Tab / j / ↓  | Navigate to next panel                   |
+| Shift+Tab / k / ↑ | Navigate to previous panel               |
 | q / Ctrl+C   | Quit the application                     |
 | r            | Restart port forwarding for focused panel|
 | s            | Switch Kubernetes context                |
 | N            | Start new connection                     |
 | h            | Toggle help overlay                      |
 | L            | Toggle log overlay                       |
+| C            | Toggle MCP config overlay                |
 | D            | Toggle dark/light mode                   |
 | z            | Toggle debug information                 |
-| Esc          | Close help/log overlay                   |
+| y            | Copy logs/config (when in overlay)       |
+| Esc          | Close help/log/config overlay            |
 
 For more details on the implementation and architecture of the TUI, see the [TUI documentation](docs/tui.md).
 
@@ -201,34 +208,51 @@ Now you can use TAB to complete cluster names:
 envctl connect myinstallation <TAB>      # Shows short names of workload clusters for myinstallation
 ```
 
+## Flexible Configuration via YAML ⚙️
+
+`envctl` supports a powerful YAML-based configuration system to customize its behavior, define new MCP servers, and manage port-forwarding rules. This allows you to tailor `envctl` precisely to your development needs.
+
+Configurations are loaded in layers (default, user-global, project-specific), with later layers overriding earlier ones. You can manage global settings, define how MCP servers are run (as local commands or containers), and specify detailed port-forwarding rules, including dynamic Kubernetes context targeting (`"mc"`, `"wc"`, or explicit contexts).
+
+For a detailed explanation of the configuration file structure, all available options, and comprehensive examples, please see the [**Flexible Configuration Documentation (docs/configuration.md)**](docs/configuration.md).
+
 ## MCP Integration Notes 💡
 
-*   After running `envctl connect`, services should be available at:
-    *   Prometheus: `http://localhost:8080/prometheus` (context: Management Cluster)
-    *   Grafana: `http://localhost:3000` (context: Management Cluster)
-    *   Alloy Metrics: `http://localhost:12345` (context depends on your connection type):
-        *   If you specified both a Management Cluster and a Workload Cluster, the Alloy Metrics port-forward uses the Workload Cluster context.
-        *   If you specified only a Management Cluster, the Alloy Metrics port-forward uses that Management Cluster context.
-*   Ensure your `mcp.json` (e.g., `~/.cursor/mcp.json`) has the correct `PROMETHEUS_URL` for the Prometheus MCP server:
-    ```json
-    {
-      "mcpServers": {
-        "kubernetes": {
-          "command": "npx",
-          "args": ["mcp-server-kubernetes"]
-        },
-        "prometheus": {
-          "command": "uv", // Or your specific command
-          "args": [ ... ], // Your specific args
-          "env": {
-            "PROMETHEUS_URL": "http://localhost:8080/prometheus"
-          }
-        }
-        // ... other servers ...
-      }
-    }
-    ```
-*   You may need to **restart your MCP servers** or your IDE after running `envctl connect` for them to pick up the new Kubernetes context and Prometheus connection.
+*   `envctl connect` uses `mcp-proxy` to manage connections for the following predefined MCP services:
+    *   **Kubernetes**: Proxied on `http://localhost:8001/sse` (underlying command: `npx mcp-server-kubernetes`)
+    *   **Prometheus**: Proxied on `http://localhost:8002/sse` (underlying command: `uvx mcp-server-prometheus`, expects Prometheus port-forward on `localhost:8080` via `PROMETHEUS_URL` env var)
+    *   **Grafana**: Proxied on `http://localhost:8003/sse` (underlying command: `uvx mcp-server-grafana`, expects Grafana port-forward on `localhost:3000` via `GRAFANA_URL` env var - this is started if you have a Grafana MCP server with this name and command).
+*   `envctl` no longer reads `~/.cursor/mcp.json` to determine how to start these servers. The commands listed above are hardcoded.
+*   You must have `mcp-proxy` installed and the respective underlying MCP server executables (e.g., `mcp-server-kubernetes`, `mcp-server-prometheus`) available in your system's PATH.
+*   **IDE Configuration (Cursor/VSCode):** Update your IDE's MCP settings to point to these SSE endpoints:
+    *   Kubernetes: `http://localhost:8001/sse`
+    *   Prometheus: `http://localhost:8002/sse`
+    *   Grafana: `http://localhost:8003/sse` (if you use a Grafana MCP server)
+*   Port-forwarded services (like Prometheus on `localhost:8080` and Grafana on `localhost:3000`) are started by `envctl` as before. The `mcp-proxy` instances for Prometheus and Grafana will use these via environment variables.
+*   You may need to **restart your IDE** after running `envctl connect` and configuring these `mcp-proxy` SSE endpoints for changes to take effect.
+
+### Customizing MCP Server Configuration
+
+If you need to customize how MCP servers are run, you can use environment variables to override the default configurations:
+
+* Each MCP server's configuration can be customized using environment variables with the pattern:
+  * `ENVCTL_MCP_<SERVER>_COMMAND`: Override the command (e.g., `ENVCTL_MCP_PROMETHEUS_COMMAND=uvx`)
+  * `ENVCTL_MCP_<SERVER>_ARGS`: Override the command arguments (e.g., `ENVCTL_MCP_PROMETHEUS_ARGS="mcp-server-prometheus --debug"`)
+  * `ENVCTL_MCP_<SERVER>_ENV_<KEY>`: Set an environment variable for the command (e.g., `ENVCTL_MCP_PROMETHEUS_ENV_PROMETHEUS_URL=http://localhost:9090`)
+
+For example, to use a custom Prometheus MCP server installation:
+
+```bash
+export ENVCTL_MCP_PROMETHEUS_COMMAND="python3"
+export ENVCTL_MCP_PROMETHEUS_ARGS="-m custom_prometheus_mcp_server"
+export ENVCTL_MCP_PROMETHEUS_ENV_PROMETHEUS_URL="http://localhost:9090"
+export ENVCTL_MCP_PROMETHEUS_ENV_DEBUG="true"
+
+# Then run envctl as usual
+envctl connect myinstallation
+```
+
+These environment variables will be detected automatically at startup, allowing you to customize the MCP server configurations without modifying the source code.
 
 ## Future Development 🔮