You've just pulled down the latest security advisory and your solution has three vulnerable transitive dependencies buried four levels deep. You know the drill: run dotnet list package --vulnerable, cross-reference target frameworks, figure out which direct dependency to bump so the transitive one resolves to a patched version, and pray nothing breaks. It's tedious, error-prone work that doesn't scale across large solutions.

The NuGet MCP Server changes this. It's a Model Context Protocol server that plugs into your IDE's AI assistant — GitHub Copilot in Visual Studio, VS Code, or even a GitHub Copilot coding agent — and gives it the ability to query NuGet feeds, resolve dependency graphs, and update packages on your behalf. Instead of manually piecing together compatible version combinations, you type "fix my package vulnerabilities" and let the tooling do the graph resolution.

It's been generally available since early 2026, ships built-in with Visual Studio 2026, and has quietly accumulated nearly two million downloads on NuGet.org. If you haven't set it up yet, here's everything you need to know.

What MCP actually is

Model Context Protocol is an open standard that lets AI models interact with external tools through a well-defined interface. Think of it as a contract: an MCP server advertises a set of tools (functions with typed inputs and outputs), and an MCP client — your IDE — invokes those tools on behalf of the language model during a conversation.

The NuGet MCP Server exposes five tools that give Copilot the ability to work with your package graph in ways that go beyond simple text completion. The server runs locally via stdio transport, meaning your project files and package sources never leave your machine.

The five tools

The server currently exposes these tools:

Tool What it does
get-nuget-solver Finds the minimum compatible non-vulnerable version for all vulnerable packages, including transitive dependencies
get-nuget-solver-latest-versions Same as above, but targets the latest compatible version rather than the minimum fix
get-latest-package-version Returns the latest version of a specific package from configured feeds
get-package-context Retrieves the llms.txt context for a package if available, falling back to the package README
update-package Updates an installed package to a specified version, checking compatibility with your target framework(s)

The two solver tools are the standout features. They use NuGetSolver — an algorithm developed in collaboration with Microsoft Research — to walk your entire dependency graph, identify vulnerable transitive packages, and compute the minimal set of direct package updates needed to resolve them. This is the same kind of resolution logic that would take you fifteen minutes of manual detective work.

Setting it up

Visual Studio 2026

The NuGet MCP Server is built-in. You just need to enable it:

  1. Open the GitHub Copilot Chat window.
  2. Click the tools icon in the bottom toolbar.
  3. Find "nuget" in the server list and tick the checkbox.

That's it. The server starts automatically and its tools become available in agent mode.

Visual Studio 2022 (17.14+)

You'll need to configure it manually. Create or edit an .mcp.json file — either at your solution root for project-scoped configuration or at %USERPROFILE%\.mcp.json for a global setup:

.mcp.json 
{
  "servers": {
    "nuget": {
      "type": "stdio",
      "command": "dnx",
      "args": ["NuGet.Mcp.Server", "--source", "https://api.nuget.org/v3/index.json", "--yes"]
    }
  }
}

VS Code

VS Code supports one-click installation through the MCP server registry. After installation, verify it's working by opening the Copilot Chat tools menu — you should see "nuget" listed with its five tools.

GitHub Copilot coding agent

For CI/agent scenarios, add the server to your repository's Copilot coding agent settings:

.github/copilot/mcp.json 
{
  "mcpServers": {
    "NuGet": {
      "type": "local",
      "command": "dnx",
      "args": ["NuGet.Mcp.Server", "--yes"],
      "tools": ["*"],
      "env": {}
    }
  }
}

You'll also need a setup workflow that installs .NET 10 or later so the dnx command is available:

.github/workflows/copilot-setup-steps.yml 
name: "Copilot Setup Steps"
on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Install .NET
        uses: actions/setup-dotnet@v5
        with:
          dotnet-version: "10.x"

The dnx command

If you haven't encountered dnx before, it's a tool runner introduced in .NET 10 that downloads and executes .NET tools without permanently installing them — conceptually similar to npx in the Node ecosystem. When you run dnx NuGet.Mcp.Server, it pulls the package from NuGet.org into your global package cache and executes it directly. No dotnet tool install required, no shims added to your PATH.

The --yes flag auto-confirms the download, and the --source flag lets you specify private feeds if your organisation hosts internal packages.

Real-world usage

Fixing vulnerabilities

The most common use case. In Copilot agent mode, type:

Fix my package vulnerabilities

Copilot calls get-nuget-solver, which analyses your project files, walks the dependency graph, checks each package against known vulnerability databases, and returns a set of version updates. Copilot then applies those updates to your .csproj files.

What makes this better than dotnet list package --vulnerable followed by manual edits is the transitive resolution. If PackageA 2.0.0 depends on VulnerableLib 1.3.0, and PackageA 2.1.0 depends on VulnerableLib 1.4.0 (the patched version), the solver knows to bump PackageA rather than trying to add a direct reference to VulnerableLib.

Updating all packages

For routine maintenance:

Update all my packages to the latest compatible versions

This uses the solver tools to compute the highest compatible version for each package given your target framework constraints. It's framework-aware, so a project targeting net8.0 won't get packages that require net10.0.

Querying package information

The get-package-context tool is particularly useful when evaluating packages. It retrieves the llms.txt file — a machine-readable summary that package authors can publish alongside their package — or falls back to the README. This gives Copilot enough context to answer questions like:

What does the Polly package do and how do I configure retry policies?

Without you leaving your editor or opening a browser tab.

Targeted updates

When you need a specific version:

Update Serilog to version 4.2.0

The update-package tool checks compatibility with your project's target frameworks before making any changes. If the requested version isn't compatible, it tells you why rather than silently breaking your build.

How the solver works under the hood

The NuGetSolver algorithm is the real differentiator. Traditional package update tooling works at the direct dependency level — it can tell you which of your top-level packages have updates available, but it doesn't reason about the full transitive graph.

NuGetSolver treats the dependency graph as a constraint satisfaction problem. Given your target frameworks, your current direct dependencies, and the vulnerability database, it computes the minimal set of direct dependency version changes that resolve all known vulnerabilities while maintaining framework compatibility. This is significantly more useful than a flat list of outdated packages because it accounts for diamond dependency conflicts, framework-specific package versions, and transitive pinning.

The tool approval model

When Copilot invokes an MCP tool, your IDE prompts you to confirm the action. This is a sensible default — the NuGet MCP Server runs locally and modifies your project files, so you want to see what it's about to do.

In Visual Studio 2026, you can scope approvals to:

For routine package updates in a trusted environment, setting session-level approval avoids the confirmation fatigue. For CI agents, the tools run without interactive prompts.

// TIP

If you're using the NuGet MCP Server primarily for vulnerability scanning, consider enabling only the get-nuget-solver and get-nuget-solver-latest-versions tools and leaving update-package disabled until you've reviewed the proposed changes.

Configuration file precedence

Visual Studio discovers MCP server configurations from multiple locations, checked in this order:

  1. %USERPROFILE%\.mcp.json — global, applies to all solutions
  2. <SolutionDir>\.vs\mcp.json — user-specific, per-solution (not source controlled)
  3. <SolutionDir>\.mcp.json — shared, source-controllable
  4. <SolutionDir>\.vscode\mcp.json — VS Code compatibility
  5. <SolutionDir>\.cursor\mcp.json — Cursor compatibility

For team-wide consistency, commit .mcp.json at the solution root. For personal tool preferences, use the %USERPROFILE% location.

Common pitfalls

Forgetting the .NET 10 SDK requirement. The dnx command was introduced in .NET 10. If you're on an earlier SDK, the server won't start. Run dotnet --info to check.

Not enabling the server after configuration. In Visual Studio, MCP tools are disabled by default even after the server starts. You have to explicitly enable them in the tools menu. If Copilot isn't using the NuGet tools, this is usually why.

Private feed authentication. If your organisation uses private NuGet feeds, pass the --source argument pointing to your feed URL. The server respects your nuget.config for source resolution, but explicitly specifying sources avoids ambiguity. There's a known issue with 401 errors when credentials are provided via nuget.config — check the NuGet GitHub repository for the latest status.

Expecting the solver to handle incompatible upgrades. The solver only proposes updates that maintain target framework compatibility. If the only patched version of a package requires a newer framework than your project targets, the solver will report that no compatible update is available. The fix is to upgrade your target framework — which is outside the tool's scope.

Running the server without --yes in automation. In CI or agent scenarios, omitting --yes causes dnx to prompt for download confirmation, which hangs the process. Always include it in non-interactive environments.

// WARNING

The update-package tool modifies your .csproj files directly. Always review the changes before committing, especially in multi-project solutions where a single package update can cascade across shared dependencies.

Where this is heading

The NuGet MCP Server is still actively evolving. Version 1.2.3 landed on 24 March 2026 with support for both net10.0 and net11.0 target frameworks. The get-package-context tool's support for llms.txt hints at a broader trend — package authors publishing machine-readable summaries specifically for AI consumption. As more packages adopt this, the quality of AI-assisted package evaluation will improve significantly.

The combination of MCP as a protocol standard and NuGetSolver as a dependency resolution engine makes this more than a novelty feature. It's a genuinely useful tool for the two most tedious aspects of NuGet management: vulnerability remediation and cross-framework dependency resolution.

Summary