-
Notifications
You must be signed in to change notification settings - Fork 37.4k
Description
Right now, the npm, Python, NuGet, and Docker MCP server installation flow is hard coded to check the central (public) registries for whether the MCP server exists. This is good for the majority of cases, but it would be great if the custom package sources (such as Azure Artifacts, GitHub Package Registry, or Artifactory) could be used too.
https://github.com/microsoft/vscode-copilot-chat/blob/518c22efd9664945024985a4c00fe1e44ddac1d3/src/extension/mcp/vscode-node/commands.ts#L202
I propose we use tooling native to the package ecosystem instead of making HTTP requests directly to the registry, if possible. For example, call out to npm CLI or dotnet CLI instead of making REST calls in proc.
This would also relate to the current working directory that the MCP server is launched from, since package manager CLIs often use cwd to determine config (such as .npmrc or NuGet.config).
Right now, MCP servers have their cwd default to homedir. I think this should probably be the workspace directory (first, in a mutli-root workspace, arbitrarily) instead of homedir. The would be a better default for the MCP server assisted flow since there is no place to specify the cwd -- VS Code mcp.json DOES have a place to configure it but it defaults to homedir as mentioned before.
For NuGet, this would look roughly like:
- Use the workspace dir for cwd instead of a temp dir or homedir.
- Use
dotnet package search <id> --exact-matchto check if the version exists on any configured source- this does not return owners (publisher), we would probably need to special case to nuget.org if its in
dotnet nuget list source
- this does not return owners (publisher), we would probably need to special case to nuget.org if its in
- the rest of the flow is the same (use
dotnettooling to install the local tool to check theserver.jsonper [NuGet MCP] Use the server.json inside the .nupkg if available instead of the README (AI-assisted MCP) #257679)
A lot of this logic applies to MCP Registry integration too. There is no guarantee a package name in server.json is on the central package registry.