4da MCP Server

@4da/mcp-server

Upgrade intelligence for AI coding agents. Before your agent bumps a dependency it learns what changes between the version you run and the one you want, which of your files that touches, and which vulnerabilities the move fixes, from your own lockfiles, on your machine. Plus vulnerability scanning at osv-scanner parity, ranked upgrade plans and decision memory. Zero config, no account.

You:     "Upgrade axum to 0.8"

Agent → upgrade_impact { package: "axum", to_version: "0.8.4" }

axum 0.7.9 -> 0.8.4: 5 releases (0.8.2 yanked), changelog from the 0.8.4 crate. 12 breaking entries, 8 touch your code (Path, Query, Router, extract, serve): breaking Remove OptionalFromRequestParts impl for Query (you use Query) breaking Require Sync for all handlers added to Router (you use Router) ... Your code: 10 files import axum.

*(Real output, abridged, run on this repository, 2026-10-02.)*

One command to install. No API keys. No accounts. Your code never leaves your machine.

Install

Requires Node.js 22 or later.

The server uses Node's built-in node:sqlite (Node 22.13 and later), so it needs no install script and works with npm 12's default of blocking them. On Node 22.0-22.12 it uses the optional better-sqlite3, whose native module npm 10 and 11 build on install. npx @4da/mcp-server@6.2.7 --doctor shows which one is in use.

claude mcp add 4da -- npx @4da/mcp-server@6.2.7

Every command and config on this page pins the version (@6.2.7), so what runs changes only when you change it. To update, replace the version with the newest one on npm (npm view @4da/mcp-server version); the changelog says what changed. Without a version, npx runs whatever it has cached or the newest release, which you did not review.

As a Claude Code plugin (the MCP server plus a hook):

claude plugin marketplace add 4DA-Systems/4da-mcp-server

claude plugin install 4da@4da

The hook: when your agent edits a dependency's version in package.json, Cargo.toml, pyproject.toml, requirements.txt or go.mod, it is told which packages moved and given the exact dependency_check and upgrade_impact calls to make before it installs and builds. The hook is plain Node, contacts nothing, and stays silent for every other edit.

Cursor / Windsurf / Devin Desktop

Add to ~/.cursor/mcp.json (Cursor), ~/.codeium/windsurf/mcp_config.json (Windsurf), or ~/.config/devin/mcp_config.json (Devin Desktop and Devin CLI; %APPDATA%\devin\mcp_config.json on Windows):

{

"mcpServers": { "4da": { "command": "npx", "args": ["@4da/mcp-server@6.2.7"] } } }

</details>

VS Code (Copilot)

Run MCP: Open User Configuration and add the entry, or edit the file directly: %APPDATA%\Code\User\mcp.json (Windows), ~/Library/Application Support/Code/User/mcp.json (macOS), ~/.config/Code/User/mcp.json (Linux). VS Code uses servers, not mcpServers:

{

"servers": { "4da": { "type": "stdio", "command": "npx", "args": ["@4da/mcp-server@6.2.7"] } } }

</details>

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{

"mcpServers": { "4da": { "command": "npx", "args": ["@4da/mcp-server@6.2.7"] } } }

</details>

Auto-setup (detects all installed editors)

npx @4da/mcp-server@6.2.7 --setup --dry-run   # show each file and entry, write nothing

npx @4da/mcp-server@6.2.7 --setup

Writes Cursor, VS Code (and Insiders), Windsurf, Devin Desktop and Claude Desktop configs it finds, merging into what is there: other servers, settings and comments are kept, a backup (.bak) is written first, and a file it cannot parse is left untouched with the entry to add by hand. For Claude Code it prints the claude mcp add command instead of editing ~/.claude.json.

Then ask your AI: "What changes if I upgrade X to Y?", "Scan for vulnerabilities" or "What should I upgrade first?"

How It Works

The server reads every lockfile of the project it is started in, including independently-locked projects below the root (a repo with src-tauri/Cargo.lock beside a root pnpm-lock.yaml is scanned whole): package-lock.json / npm-shrinkwrap.json, pnpm-lock.yaml (v5–v9), yarn.lock (v1 and berry), bun.lock, Cargo.lock (Cargo workspaces included), poetry.lock, uv.lock, pdm.lock, Pipfile.lock, requirements pins (*requirements*.txt, requirements/*.txt, with -r and -c), go.mod / go.sum (Go's build list), Gemfile.lock (RubyGems; git and path gems are local code, not releases) and composer.lock (Packagist). Every Python source in a folder is read, not only the first. Every installed copy is scanned, not one version per name, with the lockfile's own dev flags. It re-reads them whenever a lockfile changes, and for npm it also checks what node_modules actually holds. A lockfile is what is installed, so it is read whether or not .gitignore lists it, and a dot-directory (.github/actions/*) is a directory like any other. What is not scanned is said: a directory .gitignore excludes is left out (it is as often a scratch clone as the project's own code), and installed code, build output and caches (node_modules, target, dist, .venv, .git ...) are never entered, but every lockfile found in an ignored directory, or sitting directly in a build/-style one, is listed by path under coverage.not_scanned.lockfiles. The walk goes 4 levels down and up to 256 projects; whatever it leaves out is listed the same way. So is every manifest with no lockfile: its declared ranges are not installs and are not scanned, its exact pins are checked but the packages they pull in are resolved nowhere (coverage.unresolved_manifests, and coverage.manifests_without_lockfile for a manifest in a subdirectory that no lockfile above holds as a workspace member). The coverage block is present only when something was left out, and then always says complete: false; nothing is dropped silently. So are manifests of ecosystems it does not read (Maven pom.xml, Gradle, .NET *.csproj / packages.lock.json, Pub, Hex, SwiftPM, CocoaPods: coverage.not_covered), lockfiles that exist but cannot be read (merge-conflict markers, invalid JSON, Bun's binary bun.lockb: coverage.unreadable_lockfiles), lockfiles that are truncated or damaged and were read only up to the damage (coverage.partial_lockfiles), a second lockfile in a directory that disagrees with the one that was read (coverage.conflicting_lockfiles), requirements with no pinned version such as pydantic>=2.0.0 (coverage.unpinned_requirements: there is no installed version to check), dependencies installed from git or a URL (coverage.not_checkable: they are not the registry package of that name, so they are never matched against it), files of a supported ecosystem in a form that is not read (environment.yml, setup.py, pylock.toml), and lockfiles under test-fixture directories (tests/, test/, fixtures/, testdata/, __fixtures__/, conformance/ ...), which are not scanned as the project's own unless you pass include_test_fixtures: true (coverage.not_scanned).

An incomplete answer is never a clean one. When OSV.dev cannot answer for some dependencies (outage, HTTP error, timeout, the query budget), vulnerability_scan starts with summary: "NOT CHECKED: ... N of M dependencies have no vulnerability answer", counts them in coverage.unchecked_dependencies, and sets total_vulnerable_packages and by_severity to null (what the checked part found is under found_in_checked_dependencies); dependency_health withholds its score and vulnerable count, and upgrade_planner sets vulnerabilityDataAvailable: false. Large trees are queried in batches of 1,000 as OSV's budget allows, so a tree past 10,000 dependencies is answered in full, and a long answer is read to its last page. An advisory OSV matched whose record it then failed to return is listed as details: "NOT CHECKED": its severity is unknown, not low, no severity_filter drops it, and it is asked for again on the next scan instead of being cached. The scan the other tools reuse is at most one hour old; past that it is taken again.

Measured against osv-scanner on 19 public repositories (npm, pnpm v5-v9, yarn v1 and berry, bun, Cargo, Poetry, uv, Pipfile, requirements, Go; 2026-10-10), every difference settled by OSV's own API: precision 1.00 over 19,115 findings, recall 19,115 of 19,116 on the lockfiles it reads (Maven/Gradle are not read). Newly read requirement files were also checked against pip-audit.

Measured with a coding agent (pre-registered, 49 dependency tasks x 3 trials, claude-sonnet-5-5, shell and web off in both arms): it wrote a vulnerable version in 82 of 138 well-posed runs without the server and 0 of 138 with it. Harness, tasks, pinned truth and results: bench/g7.

• OSV.dev for known vulnerabilities, matched to exact installed versions
• npm registry, crates.io, PyPI, Go module proxy (registry.npmjs.org, crates.io and index.crates.io, pypi.org, proxy.golang.org) for versions, deprecations and yanks
• npm download counts (api.npmjs.org), for dependency_health's weekly-downloads figure, and for dependency_check when a new dependency's name is a near-miss of a popular package (that name and the popular one, nothing else)
• The package's own registry archive (registry.npmjs.org, static.crates.io, files.pythonhosted.org, proxy.golang.org) for the changelog upgrade_impact reads; GitHub only if you opt in with FOURDA_GITHUB_CHANGELOG=true (below)
• npm full packument, the crates.io versions API, the PyPI JSON API and the Go proxy's version list for dependency_check (publish times, yanks and retractions; on npm and crates.io also publishers, install scripts, per-version dependencies). These requests carry the package name only; the version you have installed is never sent to a registry, except that the Go proxy's list has no dates, so it is asked for the .info of the versions being judged (the same request go get makes). OSV.dev's advisory list for the package lets dependency_check name the safe releases in a constraint. Packuments are cached on disk and revalidated with If-None-Match; crates.io API reads are spaced one per second.
• Hacker News Algolia API (hn.algolia.com), only when you call ecosystem_pulse
• GitHub (api.github.com, raw.githubusercontent.com), only with FOURDA_GITHUB_CHANGELOG=true
• Your embedding provider, only if you configure one for semantic recall (a local Ollama URL, or api.openai.com; see below)

Those are all the hosts the server contacts.

Results are cached (24h for registry data, 1h for vulnerabilities, 30min for news) and rate-limited per source.

What's sent over the network, and when: nothing when your editor starts the server and lists its tools; the project is read locally, and the first request goes out when a tool that needs it is called (vulnerability_scan, what_should_i_know, dependency_check ...). Then: package names and versions (the same dat