Dep Diff Mcp

io.github.DigiCatalyst-Systems由 GitHub 账号 DigiCatalyst-Systems 发布v0.3.3更新于 Oct 30, 2026

Translates a lockfile diff into a human-readable upgrade plan for npm, PyPI, and GitHub Actions.

已验证Streamable HTTP可网页运行开发者工具安全与监控

概览

AI 生成的概览

把 lockfile 差异或 Dependabot PR 转成可读的升级计划,覆盖 npm、PyPI 与 GitHub Actions,给出语义化版本级别、破坏性变更、修复的漏洞与建议。

可以做什么
  • 分析单个包在两个版本之间的升级,支持 npm、PyPI 与 GitHub Actions,返回语义化版本级别、发布说明摘要、破坏性变更、安全修复、迁移链接与建议
  • 并行分析最多 50 项升级,返回统一风险报告,按 security、caution、review、likely-safe、safe 排序并附汇总计数
  • 结果同时以 JSON 文本块和符合已声明输出结构(outputSchema)的结构化内容返回
适用场景
适合在审查 Dependabot 拉取请求、npm outdated 输出或 lockfile 差异时使用,用来判断哪些升级真正紧急,而不只是变更幅度大小,尤其能发现藏在补丁版本里的安全修复。
运行要求
可作为基于 streamable HTTP 的远程托管端点使用,也可通过 npx 运行 npm 包在本地运行(需要 Node.js)。GitHub 令牌可选但建议配置:GITHUB_TOKEN 环境变量、已登录的 gh CLI,或在托管地址上附加 githubToken 查询参数;不配置时 GitHub API 每小时仅 60 次请求。
安装前请注意
GitHub 令牌会从 GITHUB_TOKEN、gh CLI 或 githubToken 网址参数读取;README 提醒配置文件以明文保存令牌,应使用仅可读公开仓库的最小权限。托管实例使用自己的令牌,并称无状态、不记录查询日志,但查询仍会发往第三方服务器;若希望令牌不离开本机,请本地运行 npm 包。包名与版本会发送给 GitHub 和 OSV.dev。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Dep Diff Mcp,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

交给智能体安装

把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。

阅读 https://sourceweft.com/mcp/io.github.DigiCatalyst-Systems%2Fdep-diff-mcp/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。

查看智能体所依据的安装指南

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。

{
  "mcpServers": {
    "dep-diff": {
      "type": "http",
      "url": "https://dep-diff.digicatalyst.ca/mcp"
    }
  }
}

README

dep-diff-mcp

MCP server that translates a lockfile diff into a human-readable upgrade plan.

Point your AI assistant (Cursor, Claude Desktop, Claude Code) at a Dependabot PR, npm outdated output, or any pair of package versions, and get back a ranked upgrade plan: semver class, breaking changes pulled from GitHub release notes, CVEs fixed in the range, migration guide links, and a clear recommendation per package.

What it looks like

Ask your assistant, in plain language:

Is it safe to bump lodash from 4.17.20 to 4.17.21?

It calls analyze_package_change and gets back:

json
{  "package": "lodash",  "ecosystem": "npm",  "fromVersion": "4.17.20",  "toVersion": "4.17.21",  "semverClass": "patch",  "repoUrl": "https://github.com/lodash/lodash",  "releaseCount": 0,  "breakingChanges": [],  "securityFixes": [    {      "id": "GHSA-29mw-wpgm-hmr9",      "summary": "Regular Expression Denial of Service (ReDoS) in lodash",      "severity": "MODERATE"    },    {      "id": "GHSA-35jh-r3h4-6jhm",      "summary": "Command Injection in lodash",      "severity": "HIGH"    }  ],  "migrationLinks": [],  "recommendation": "RECOMMENDED: 2 security fix(es) (incl. high/critical).",  "recommendationLevel": "security"}

A patch bump you would normally merge without looking. It closes a HIGH-severity command injection. That is the case this server exists for.

GitHub Actions

Dependabot opens more actions/* pull requests than almost anything else, and its scheduled version updates carry no advisory data. Ask:

Is it safe to bump tj-actions/changed-files from 45.0.7 to 46.0.1?

json
{  "package": "tj-actions/changed-files",  "ecosystem": "github-actions",  "semverClass": "major",  "repoUrl": "https://github.com/tj-actions/changed-files",  "securityFixes": [    {      "id": "GHSA-mrrh-fwg8-r2c3",      "summary": "tj-actions changed-files through 45.0.7 allows remote attackers to discover secrets",      "severity": "HIGH"    }  ],  "recommendation": "RECOMMENDED: 1 security fix(es) (incl. high/critical).",  "recommendationLevel": "security"}

A whole Dependabot batch

Here's my Dependabot PR — what's actually risky in it?

analyze_packages_bulk takes up to 50 changes at once and ranks them security > caution > review > likely-safe > safe:

json
{  "totalPackages": 5,  "bySemverClass": { "major": 1, "minor": 3, "patch": 1 },  "securityFixesTotal": 7,  "packagesWithBreakingChanges": 1,  "packages": [ /* one entry per package, same shape as above */ ]}

Condensing the recommendation field of each entry, that batch comes back in this order:

PackageChangeClassVerdict
lodash4.17.20 → 4.17.21patchRECOMMENDED — 2 security fixes (incl. high/critical)
axios1.6.0 → 1.7.9minorRECOMMENDED — 1 security fix (incl. high/critical)
express4.18.2 → 5.0.0majorRECOMMENDED — 2 security fixes; 3 breaking changes, migration guide
requests (PyPI)2.31.0 → 2.32.0minorRECOMMENDED — 2 security fixes
typescript5.3.3 → 5.4.5minorLIKELY SAFE — minor version, additive changes per semver

Note the ordering: the patch bump outranks the major one. Semver tells you how much changed; it does not tell you what is urgent.

Every response above is real output from the hosted instance, trimmed only where marked.

Install

Claude Code

One command, user scope (available in every project):

bash
claude mcp add -s user dep-diff -- npx -y @digicatalyst/dep-diff-mcp

Project scope (writes .mcp.json at repo root, team-shared):

bash
claude mcp add -s project dep-diff -- npx -y @digicatalyst/dep-diff-mcp

With an explicit token (skip this if you have the gh CLI authenticated — see GitHub token below):

bash
claude mcp add -s user --env GITHUB_TOKEN=ghp_xxx dep-diff -- npx -y @digicatalyst/dep-diff-mcp

Verify:

bash
claude mcp list

Restart the Claude Code session to pick up the server.

Cursor and Claude Desktop

Add to your MCP client config:

  • Cursor: ~/.cursor/mcp.json
  • Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows)
json
{  "mcpServers": {    "dep-diff": {      "command": "npx",      "args": ["-y", "@digicatalyst/dep-diff-mcp"]    }  }}

Restart your MCP client. Ask something like "what's risky in this Dependabot PR?" and the tools are invoked automatically.

Hosted remote (no install)

A hosted instance runs at https://dep-diff.digicatalyst.ca/mcp over streamable HTTP, so you can skip the npm package entirely:

bash
claude mcp add -s user -t http dep-diff https://dep-diff.digicatalyst.ca/mcp

Or in a client config:

json
{  "mcpServers": {    "dep-diff": {      "type": "http",      "url": "https://dep-diff.digicatalyst.ca/mcp"    }  }}

The hosted instance authenticates to GitHub with its own token, so release-note lookups work at full rate limits without you configuring anything. Pass ?githubToken=ghp_xxx on the URL only if you would rather requests counted against your own GitHub quota. It is stateless and keeps no logs of your queries — see PRIVACY.md. Run the npm package locally instead if you would rather your token never leave your machine.

The same instance is also listed on Smithery, which proxies to it through their gateway.

GitHub token (optional but recommended)

The server hits the GitHub API to read release notes. Without a token you get 60 requests per hour (GitHub's anonymous limit) — enough for occasional single-package queries, not enough for bulk lockfile analysis.

The server resolves a token in this order:

  1. GITHUB_TOKEN environment variable, if set.
  2. gh auth token — if the GitHub CLI is installed and authenticated, the server uses that token automatically. No config change needed.
  3. Anonymous (60 req/hr).

Recommended: use the gh CLI

If you already have gh installed (brew install gh && gh auth login), stop here — the server picks up your existing auth. No plaintext token anywhere.

Alternative: environment variable

Create a fine-grained token at https://github.com/settings/tokens:

  • Token name: dep-diff-mcp
  • Expiration: 90 days (rotate periodically)
  • Repository access: Public Repositories (read-only) — no private repo access
  • Permissions: none beyond the default public read — do not grant repo, workflow, user, or any write scope

Then reference it in the MCP config:

json
{  "mcpServers": {    "dep-diff": {      "command": "npx",      "args": ["-y", "@digicatalyst/dep-diff-mcp"],      "env": { "GITHUB_TOKEN": "github_pat_xxx" }    }  }}

Security notes

  • This config file lives on your disk in plaintext. Keep perms tight (chmod 600) and do not paste the token into AI chats, issues, or shared screens — transcripts are often retained.
  • The token in this config should be least-privilege (public repo read only). Even leaked, it can only read public data you could already read.
  • Rotate tokens periodically. Revoke any token that may have been exposed at https://github.com/settings/tokens.
  • The server never writes the token to stdout/stderr or the response payload.

Tools

analyze_package_change

Analyze one package upgrade. Inputs: ecosystem (npm, pypi, or github-actions), name, fromVersion, toVersion.

analyze_packages_bulk

Analyze up to 50 package upgrades in parallel. Returns packages ranked by risk (security > caution > review > likely-safe > safe), plus summary counts.

What you get back

  • Semver classification — major / minor / patch / downgrade / unknown
  • Breaking changes — extracted from GitHub release notes headers
  • Security fixes — CVEs present at fromVersion but resolved at toVersion (via OSV.dev)
  • Migration links — upgrade guide URLs found in release notes
  • Recommendation — single-line verdict + level

Both tools return this twice: as the JSON text block shown above, and as MCP structured content validated against a declared outputSchema. A client that supports structured output can read recommendationLevel or securityFixes[] straight off the response instead of re-parsing the text. Clients that don't are unaffected — the text block is unchanged.

Supported ecosystems

  • npm
  • PyPI
  • GitHub Actions — pass the action reference as the name (actions/checkout, or a nested github/codeql-action/init). An action reference is already a repository coordinate, so release notes and breaking changes resolve without a registry lookup, and bare major tags such as 4 -> 5 classify correctly.

Development

bash
npm installnpm run buildGITHUB_TOKEN=ghp_xxx npm run inspect   # MCP Inspector

License

MIT

来源:README.md,提交 7925ca1

工具

2

analyze_package_change

Analyze a single dependency version change

Given one package and two versions (from -> to), returns a structured upgrade analysis: semver classification, GitHub release notes summary, detected breaking changes, security advisories fixed in the range, migration guide links, and a clear recommendation. Use when the user asks about a specific package upgrade ('what changed between react 18 and 19', 'is it safe to bump axios from 0.27 to 1.0', 'what does upgrading lodash 4.17.20 to 4.17.21 fix'). Supports npm, pypi, and github-actions (use the action reference as the name, e.g. actions/checkout). For analyzing many packages at once or a Dependabot batch, use analyze_packages_bulk instead.

输入参数name必填ecosystem必填toVersion必填fromVersion必填

analyze_packages_bulk

Analyze multiple dependency changes in parallel

Analyzes a list of package upgrades in parallel and returns a unified risk report with packages ranked by recommendation level (security > caution > review > likely-safe > safe). Use when the user provides many dependency changes from a Dependabot PR, npm outdated output, lockfile diff, or batch upgrade. Returns: total count, breakdown by semver class, total security fixes found, packages with breaking changes, and per-package details. Limit 50 packages per call (chunk larger lists).

输入参数changes必填

版本历史

2
  1. v0.3.3最新Oct 30, 2026
  2. v0.3.2Sep 16, 2026

评分

已满足适用检查项的 100%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通必需25 分
  • 已声明认证方式必需10 分
  • 已列出工具必需15 分
  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分