VS Code and GitHub Copilot use different documented MCP configuration formats, so sharing server definitions across them means producing the right format for each. For developers coordinating MCP setup across editors, the key is to preserve each client’s requirements and test the server separately from the files that describe it.

Choose the configuration format for each client

An MCP server exposes tools and other capabilities to AI clients. Microsoft documents two relevant formats: VS Code’s own format and a portable format that Copilot harness sessions read directly. The files use different paths, top-level JSON keys, and environment-variable references. Microsoft’s MCP configuration reference describes them this way:

FormatWorkspace fileUser fileTop-level keyEnvironment references
VS Code.vscode/mcp.jsonmcp.json in the VS Code user profileservers${env:NAME}
Portable Copilot.mcp.json$COPILOT_HOME/mcp-config.json, falling back to ~/.copilot/mcp-config.jsonmcpServers${NAME} or ${NAME:-default}

The distinction matters when a server is available in VS Code but not in a Copilot harness session. Copilot reads the portable format directly. VS Code can forward eligible servers from its own format, but it does not forward servers that require interactive ${input:...} values. VS Code also treats bare $NAME as literal text.

Check what portable configuration leaves out

Portable configuration does not carry every VS Code setting. Microsoft lists input prompts, envFile, development mode, and per-server sandbox settings as capabilities that the portable format does not support. If a team relies on any of them, generating a portable file alone will not preserve that behavior; keep the VS Code-specific configuration for the editor.

Generate files, then test the server

A shared source file can help keep server definitions consistent while generating separate outputs for different clients. Tech Insider described a workflow that generates editor-specific files from one source and checks JSON parsing, top-level keys, variable syntax, secret-like values, and server-name parity. Its tutorial also describes a CI drift check. Treat those as checks on the configuration files: a clean audit does not show that a server can launch, authenticate, connect, or provide its intended tools.

A practical sequence is:

  1. List the clients and harnesses your team uses. This determines which configuration formats you need.
  2. Keep a separate output for each documented format. Use servers for the VS Code format and mcpServers for portable Copilot files.
  3. Audit the generated files. Check that they parse, use the right top-level keys and variable syntax, and keep the server lists aligned. A CI check can flag drift between the source and generated files.
  4. Test the server in the intended client. Tech Insider’s tutorial recommends MCP Inspector and a representative tool call as checks beyond file structure.

Configure managed Cursor workspaces

For organizations that provision developer workspaces centrally, Coder describes a separate Cursor approach: its module accepts MCP JSON in a workspace template and writes it to ~/.cursor/mcp.json when the workspace starts. Coder presents Terraform templates as the place to version-control that setup. This is a managed-workspace option for Cursor, distinct from generating shared VS Code and Copilot files.