copilot-mcp: a VS Code front end for MCP servers and Agent Skills

The gap between discovering an MCP server and having it usable in Copilot

MCP servers are distributed as repositories, npm packages, or Python entry points. Getting one into GitHub Copilot Chat means finding the project, working out whether it runs through npx or uvx, and writing a server entry into a config file with the right command and arguments. Agent Skills add a second surface: they are installed per agent, and the README states the extension pulls them from skills.sh. copilot-mcp targets the person doing that work in VS Code. A sidebar view lists servers, a Skills view searches and installs them, and an Installed Skills view allows uninstall with what the README calls agent-level controls. The scope is deliberately narrow: it manages discovery and installation, and leaves the actual tool execution to whatever runtime the server needs. If you expected the extension to host an MCP server or proxy tool calls, that is not what the feature list describes.

What the Activity Bar view actually controls

The mechanism is a VS Code extension written in TypeScript that presents MCP servers as a managed collection. The README describes connecting and managing multiple servers through a UI, and a Server Discovery panel that finds open source servers. There is one detail worth noting because it reveals how the extension classifies servers: when a server supports npx or uvx, the discovery panel offers a Deploy via Cloud MCP option, which the README frames as a way to run it remotely without installing anything. That means the extension distinguishes between locally runnable servers and servers that can be handed to a hosted endpoint, and the local path is the default. On the skills side, the flow is search, install, then manage installed skills with uninstall at agent level. The README does not document the on-disk layout for installed skills, nor the config format the extension writes when you connect a server. That is a real gap: if you want to know whether connecting a server mutates a workspace file or a user-level setting, the README does not say.

Installation and the settings you can point at

The install path is the VS Code Marketplace listing for AutomataLabs.copilot-mcp. The README also gives a direct link, vscode://AutomataLabs.copilot-mcp, which opens the extension page in VS Code. After installation, the entry point is the MCP Servers icon in the Activity Bar, with configuration available through the same view or through VS Code settings. The documented requirements are VS Code and the GitHub Copilot Chat extension. The one configuration key the README names explicitly is telemetry.telemetryLevel, which the extension honors: setting it to off stops the extension from sending anything. The README does not list other settings keys, so any server command, argument, or environment configuration is presumably handled through the UI rather than documented keys. For contributors rather than users, there are two npm scripts: npm run sync:copilot-provider writes the vendored upstream Copilot provider from anomalyco/opencode under vendor/opencode-copilot/src, and npm run sync:copilot-provider:check reports drift without writing files. A GitHub workflow, .github/workflows/sync-opencode-copilot.yml, opens daily sync pull requests.

Telemetry is opt-out and the README is unusually specific about it

The extension collects anonymous usage events: searches, install attempts, and clicks on in-extension links and calls to action. The properties listed include search terms typed in the sidebar and in @mcp chat prompts truncated to 100 characters, public GitHub repository names and URLs plus skill source locators for items you search for or act on, OS platform and architecture, extension version, and truncated error messages. The README states that file contents, workspace or repository contents, and account identifiers are never collected, and that account-shaped properties are stripped before sending. Search terms are the interesting case. They are not file contents, but they are your intent, and a truncated query can still name a private project or an internal tool. The opt-out is a single VS Code setting, telemetry.telemetryLevel set to off, and the README says the extension sends nothing in that state. If you work under a policy that forbids outbound telemetry, that setting is the control, and it is worth verifying it before first launch rather than after.

Where the extension stops being the right tool

The README is explicit that the extension is a client, and it carries the MCP Client badge. It does not run servers for you. A server that needs a database, a local daemon, or credentials with a long setup path still needs that setup, and the extension will only record how to launch it. The remote escape hatch, Deploy via Cloud MCP, points at cloudmcp.run, a separate hosted product from the same author. That is a real dependency to weigh: the README's remote workflow routes through a commercial service, and the extension's own repository is GPL-3.0. There is also a versioning signal. The releases listed are v0.0.97, v0.0.96, and v0.0.95, published within three days of each other in June 2026, and the version string in the README is 0.0.97. A 0.0.x line moving that fast suggests active churn, and the README offers no compatibility or migration notes between releases. If you need a stable interface for a team, that cadence is a reason to pin a version rather than track the marketplace default. Finally, telemetry covers install attempts and searches, which is the extension's core loop; there is no documented way to disable collection while keeping the extension functional other than the global VS Code telemetry level, which also affects other extensions.

The plain config file is the alternative, and the difference is who reviews it

The direct alternative is hand-writing MCP server entries into your client's configuration, the mcp.json-style file that VS Code, Claude Code, and Codex CLI each read. The difference in approach is not features, it is where the configuration lives and who sees it. A config file is a text artifact you can commit, diff, and review in a pull request. The extension's UI writes configuration through a panel, and the README does not document the resulting file format, so the review path is unclear. That matters for teams: an MCP server entry can include a command, arguments, and environment variables, and those are exactly the lines you want a second pair of eyes on. The extension wins on discovery and on skills. Searching skills.sh from a sidebar and uninstalling per agent is faster than cloning a skill repository by hand. The plain config wins on auditability. A reasonable split is to use the extension to find and evaluate servers, then move the ones you keep into a committed config file, if the extension's output can be copied out. The README does not confirm that it can.

Licence, maintenance, and what the vendored provider implies

The repository is GPL-3.0, and the README points to the LICENSE file. That is a copyleft licence, and it matters if you plan to fork the extension or bundle it into something you distribute: derivative works generally have to carry the same licence. Using the extension as an end user does not raise the same question, but the code is not available under a permissive term if you want to reuse parts of it. Maintenance cost has two sides. For users, the cost is tracking a fast 0.0.x release line with no documented migration notes. For anyone building on the repository, there is the vendored provider under vendor/opencode-copilot/src, sourced from anomalyco/opencode, kept in step by npm run sync:copilot-provider:check and a daily workflow that opens sync pull requests. That is a maintained integration rather than a one-time copy, but it also means the extension inherits upstream changes on a daily cadence, and a drift check that fails is a signal you have to act on. This is not legal advice; if the GPL-3.0 terms affect your distribution plans, read the licence text and get proper counsel.

Editorial conclusion

Adopt copilot-mcp if you already work inside VS Code with GitHub Copilot Chat and you want skills.sh discovery plus per-agent install and uninstall without hand-editing config files. Skip it if your MCP servers live in a repo-level config that your team reviews in pull requests, or if you run Claude Code and Codex CLI in terminals only, since a VS Code panel adds nothing there. Before installing, read the telemetry section of the README and decide whether telemetry.telemetryLevel set to off is acceptable to you, and check whether the Skills view exposes a target selector for the agents you actually use, because the README does not spell out how the extension decides which agents receive an installed skill.

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. VikashLoomba/copilot-mcp on GitHub