CLI-323 configure MCP for Copilot integration; Refactor Claude MCP

[sophio-japharidze-sonarsource]

No description provided.

[hashicorp-vault-sonar-prod]

CLI-323

[sonar-review-alpha]

Summary

Summary

This PR configures MCP (Model Context Protocol) server support for Copilot integration and refactors the shared MCP setup logic to eliminate code duplication between Claude and Copilot.

Key Changes:

• Copilot MCP Support: Added --global and --project options to the integrate-copilot command, implementing actual MCP server configuration (previously was placeholder "coming soon" stub)
• Shared MCP Setup: Extracted common MCP server configuration logic into a new shared module (src/cli/commands/integrate/_common/mcp.ts) with setupMcpServerForAgent() function used by both integrations
• Refactored MCP Helpers: Renamed and split server-config.ts → mcp-helper.ts, separating CLI-based config (getMcpConfig) from container-based config (getMcpContainerCommand)
• Simplified Config Writing: writeMcpServerEntry() now handles only global MCP server merging; file path determination is delegated to getMcpConfigFilePath() which supports both agents and global/project modes
• Added Platform CLI Command: New CLI_COMMAND constant in config-constants.ts resolves to platform-specific sonar executable

Impact: Both Claude and Copilot can now use the same MCP infrastructure, with support for both global (~/.claude.json, ~/.copilot/mcp-config.json) and project-level (.mcp.json) configurations.

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
87.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

What reviewers should know

What to Review

Start with the architecture:

• src/cli/commands/integrate/_common/mcp.ts - The new shared entry point; simple and agent-agnostic
• src/lib/mcp/mcp-helper.ts - The refactored helper module; getMcpConfig() is the new, simpler logic for this PR (it generates sonar run mcp commands, not container commands)

Then review the integrations:

• src/cli/commands/integrate/copilot/index.ts - Now actually implements MCP setup instead of stub
• src/cli/commands/integrate/claude/index.ts - Updated to use shared function; behavior shouldn't change
• src/cli/command-tree.ts - CLI option changes for copilot integrate command

Key decisions to understand:

• setupMcpServerForAgent() is deliberately simple—it just calls getMcpConfig() (CLI-based) and writes to the target config file. Container runtime detection is no longer part of this path.
• getMcpContainerCommand() is separate; used only by sonar run mcp command to spawn Docker/Podman, not by the integrate commands.
• writeMcpServerEntry() now only merges into mcpServers top-level (removed project-specific nesting). File path logic is delegated so each agent/mode can have its own paths.
• Global vs project-level mode is determined by getMcpConfigFilePath() based on agent + isGlobal flag.

Test changes:

• Removed Docker/Podman runtime detection tests from setupMcpServer* (now a container concern only)
• New test file for Copilot integration with comprehensive option coverage
• Renamed test describe block from getMcpServerConfig to getMcpContainerConfig to clarify scope

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[damien-urruty-sonarsource]

LGTM, I just foresee that this common MCP config will not be common for all agents, but for now it's fine. Another thing that bothers me is that we have 2 different folders that are used for shared helper functionality: lib/ and src/cli/commands/_common/. It's a bit confusing, and maybe we should group them. But it's out of scope of this PR

[damien-urruty-sonarsource]

I don't think having a common method for all MCP configs will work in the long run. Each Agent comes with different syntax or subtleties in their MCP config files. But for now it should be fine

[damien-urruty-sonarsource]

Maybe to discuss with Clifford, but I know for some other commands, we fail if some options are incompatible. I think it's less confusing because as a user you don't know which option 'wins'