Dependencies / Environment View

[hoyt-harness]

Dependencies / Environment View

Summary

Replace the removed Services view with a Dependencies / Environment view that displays the health, versions, and availability of runtime prerequisites that MCP servers depend on. This provides genuinely useful, MCP-specific information that no OS-level tool duplicates.

Rationale

MCP servers depend on specific runtimes and tools — Node.js, Python, uv, npm, Go, etc. When a server fails to start or behaves unexpectedly, one of the first troubleshooting steps is verifying that its dependencies are present and at compatible versions. Currently, users must manually run node --version, python --version, etc. from a terminal to check this.

A dedicated Dependencies/Environment view surfaces this information proactively, giving users an at-a-glance health dashboard for their MCP server ecosystem's underlying requirements. This is especially valuable for non-technical users who may not be comfortable with command-line dependency checking.

Existing Infrastructure

MCPManager already has substantial backend support for this feature:

• internal/core/dependencies/check.go: A complete DependencyService with CheckDependencies() and CheckSingleDependency() methods. Supports four dependency types: runtime, tool, environment, and library. Includes version extraction, platform-aware installation instructions, and a testable CommandExecutor interface.
• internal/models/dependency.go: A Dependency model with Name, Type, RequiredVersion, DetectedVersion, InstallationInstructions fields and an IsInstalled() method with semver constraint checking.
• internal/models/enums.go: DependencyType enum with runtime, library, tool, and environment constants.
• frontend/src/stores/stores.ts: An existing serverDependencies writable store (Record<string, Dependency[]>) and a Dependency TypeScript interface.

The backend can already detect Node.js, Python, Go, npm, pip, git, and arbitrary tools. The gap is a frontend view to present this data.

Proposed Features

Core View

• Global Environment Summary: A top section showing system-wide runtime availability — Node.js (version), Python (version), Go (version), npm, uv, pip, git — with green/yellow/red status indicators.
  • Green: Detected, version satisfies all server requirements
  • Yellow: Detected, version mismatch or unknown version
  • Red: Not detected / not installed
• Per-Server Dependency Breakdown: Below the global summary, a collapsible section per discovered server showing that server's specific dependency requirements and whether they're met. This uses the existing MCPServer.Dependencies field and DependencyService.CheckDependencies().
• Installation Guidance: For missing dependencies, display the platform-specific installation instructions already generated by DependencyService.getInstallationInstructions().

Interactions

• Manual Refresh: A refresh button to re-scan all dependencies (re-runs the version detection commands).
• Expand/Collapse: Per-server sections are collapsible to manage visual density.
• Copy Install Command: A copy-to-clipboard button next to installation instructions for quick terminal pasting.

Sidebar Integration

• Replaces the removed Services view slot in the sidebar
• Icon suggestion: 📦 or 🔗 (package/dependency metaphor)
• Hover tip: "Runtime dependencies and environment"
• Keyboard shortcut: Inherits whatever slot Services previously held (currently Ctrl+5 if placed before Help, or a new slot)

Cost/Benefit

• Cost: Low-Medium. Backend infrastructure is already built and tested. Primary work is the frontend view component, a Wails-bound method to expose DependencyService results, and wiring the refresh flow.
• Benefit: High. Eliminates a common troubleshooting friction point. Differentiates MCPManager from generic OS tools. Makes the application more valuable for users managing multiple MCP servers with different runtime requirements.
• Priority: Medium — good candidate for the next feature pass.

Technical Notes

• The DependencyService uses exec.Command under the hood, which means dependency checks involve subprocess execution. Consider caching results with a reasonable TTL (30-60 seconds) and only refreshing on manual trigger or view activation, similar to the approach originally considered for the Services view.
• The CommandExecutor interface is already designed for testability — frontend-to-backend wiring should be straightforward.
• The Dependency TypeScript interface in stores.ts already matches the Go model's JSON serialization.

---

Feature concept by Claude (Architect) — March 13, 2026
Submitted by Hoyt Harness