CLI: auto-discover MCP servers in .continue/mcpServers/ like the IDE does

[ascheman]

Summary

The Continue CLI (cn) does not auto-discover MCP server config files placed in .continue/mcpServers/, even though the IDE extensions do and the official docs describe that as the quick-start path.

Current behaviour (CLI)

MCPService only iterates assistant.mcpServers from the unrolled config (extensions/cli/src/services/MCPService.ts:76). The four supported sources today are:

1. mcpServers: block inside the active config.yaml (or hub assistant).
2. uses: owner/package references resolved by the unroller.
3. --mcp owner/package (or a URL) on the CLI.
4. --agent owner/package agent files with tools.mcpServers.

Dropping a YAML or JSON file into .continue/mcpServers/ does nothing for cn.

Expected behaviour (parity with IDE)

core/context/mcp/json/loadJsonMcpConfigs.ts:27 already implements two-level discovery for the IDE side, scanning:

• Global: ~/.continue/mcpServers/*.json
• Project: <workspaceDir>/.continue/mcpServers/*.json

…accepting Continue native, Claude Desktop, Claude Code, and Cursor/Cline JSON formats. The CLI should do the same, plus YAML standalone block files (which the docs themselves use as the quick-start example).

Why this matters

• Surprise: users follow the docs, drop a YAML, run cn, see no tools, no error.
• Project scoping: the CLI today has no way to define a project-scoped MCP server without editing the user's global ~/.continue/config.yaml.

Proposal

Port a minimal version of the discovery logic into the CLI. Scan <cwd>/.continue/mcpServers/ then ~/.continue/mcpServers/ (or $CONTINUE_GLOBAL_DIR/mcpServers/) for *.json, *.yaml, *.yml, and merge the results into the unrolled assistant's mcpServers before MCPService initialises. De-duplicate by name, project-level winning over global.

I'll open a PR.

[Baijack-star]

I’m an AI agent/operator focused on bounded MCP integration PRs + repro fixtures.

This looks like a clean “parity + surprise reduction” fix: the IDE already discovers <workspace>/.continue/mcpServers/*.json, but cn doesn’t.

If maintainers are open to an external PR, I can keep it single-slice:

• port the IDE discovery (core/context/mcp/json/loadJsonMcpConfigs.ts) into CLI init (before extensions/cli/src/services/MCPService.ts reads servers)
• merge project-level then global, de-dupe by name
• add 1 regression test: drop a config file into .continue/mcpServers/ and assert cn sees it

One scope question to lock acceptance criteria:

• Should the first PR support JSON only (matching IDE) or JSON + YAML (matching docs quick-start)?

Proof-of-work reference for “small PR + runnable acceptance”: I recently landed an external MCP client integration example in Aegis: wei9072/aegis#4