hermes - 💡(How to fix) Fix Feature: workspace-scoped MCP config equivalent to VS Code .vscode/mcp.json [1 participants]

Summary

Add first-class support in Hermes Agent for workspace-scoped MCP server configuration, similar to VS Code's .vscode/mcp.json, so project-local MCP servers can be discovered and used without manually duplicating them into global Hermes config.

Motivation

In today's WSL session, the active project already had MCP servers defined in .vscode/mcp.json, including a local operations-history server. Hermes could inspect that file, but it could not use those servers natively because Hermes MCP discovery currently relies on Hermes config rather than workspace-scoped project config.

This creates friction for setups where:

• VS Code / Copilot already has working MCP definitions
• the user is running Hermes inside WSL on the same workspace
• the same project should also work on a personal native Linux machine later
• MCP servers are project-specific and should travel with the repo rather than live only in a global agent config

Proposed capability

Support a Hermes workspace-level MCP config that is functionally equivalent to .vscode/mcp.json, or provide compatibility with that file directly.

Possible approaches:

1. Directly read .vscode/mcp.json when Hermes is launched inside a repo/workspace
2. Support a Hermes-native workspace file and optionally import/translate .vscode/mcp.json
3. Merge global ~/.hermes/config.yaml MCP servers with workspace-local MCP servers using clear precedence rules

Desired behavior

• Hermes launched inside a repo can discover project-local MCP servers automatically
• Workspace variables such as ${workspaceFolder} resolve correctly
• Works in WSL paths and on native Linux paths
• Clear handling for stdio and SSE/HTTP transports
• Easy diagnostics for why a workspace MCP server did or did not load
• No requirement to duplicate the same MCP definitions into global config just to use them from Hermes

Notes / design considerations

• Precedence between global and workspace-local server definitions
• Security model for trusting repo-local MCP definitions
• Environment variable inheritance and path translation in WSL
• Optional commands like hermes mcp import-vscode or hermes mcp reload-workspace
• Potential support for per-workdir MCP loading alongside existing workdir semantics

Use case

A repo contains local MCP infrastructure (for example, an operations-history SQLite MCP server) and already ships .vscode/mcp.json for VS Code/Copilot. Hermes running in that same repo should be able to use those MCP servers with minimal or no reconfiguration on both WSL and Linux.