dep-diff-mcp
dep-diff-mcp
MCP-сервер, который превращает дифф lock-файла в читаемый план обновления пакетов.
Направьте своего ИИ-ассистента (Cursor, Claude Desktop, Claude Code) на Dependabot PR, на вывод npm outdated или на любую пару версий пакетов — и получите ранжированный план обновления: класс semver, ломающие изменения из релизных заметок GitHub, CVE, исправленные в диапазоне версий, ссылки на руководства по миграции и чёткую рекомендацию по каждому пакету.
Установка
Claude Code
Одна команда — на уровне пользователя (доступно в каждом проекте):
claude mcp add -s user dep-diff -- npx -y @digicatalyst/dep-diff-mcpНа уровне проекта (записывает .mcp.json в корень репозитория, общий для команды):
claude mcp add -s project dep-diff -- npx -y @digicatalyst/dep-diff-mcpС явным токеном (пропустите этот шаг, если CLI gh уже авторизован — см. Токен GitHub ниже):
claude mcp add -s user --env GITHUB_TOKEN=ghp_xxx dep-diff -- npx -y @digicatalyst/dep-diff-mcpПроверка:
claude mcp listПерезапустите сессию Claude Code, чтобы сервер подхватился.
Cursor и Claude Desktop
Добавьте в конфигурацию вашего MCP-клиента:
Cursor:
~/.cursor/mcp.jsonClaude Desktop:
~/Library/Application Support/Claude/claude_desktop_config.json(macOS) или%APPDATA%\Claude\claude_desktop_config.json(Windows)
{
"mcpServers": {
"dep-diff": {
"command": "npx",
"args": ["-y", "@digicatalyst/dep-diff-mcp"]
}
}
}Перезапустите MCP-клиента. Спросите что-то вроде «что тут рискованного в этом Dependabot PR?» — и инструменты будут вызваны автоматически.
Облачная версия (без установки)
Размещённый экземпляр работает по адресу https://dep-diff.digicatalyst.ca/mcp по протоколу streamable HTTP, так что от пакета npm можно полностью отказаться:
claude mcp add -s user -t http dep-diff https://dep-diff.digicatalyst.ca/mcpИли в конфигурации клиента:
{
"mcpServers": {
"dep-diff": {
"type": "http",
"url": "https://dep-diff.digicatalyst.ca/mcp"
}
}
}Если нужны более высокие лимиты запросов, передайте токен GitHub в URL с параметром ?githubToken=ghp_xxx. Размещённый экземпляр не сохраняет состояние и не ведёт логи ваших запросов — см. PRIVACY.md. Если вы предпочитаете, чтобы токен никогда не покидал вашу машину, запускайте пакет npm локально.
Related MCP server: upgrade-pilot-mcp
Токен GitHub (необязательно, но рекомендуется)
Сервер обращается к GitHub API, чтобы читать релизные заметки. Без токена доступно 60 запросов в час (анонимный лимит GitHub) — этого достаточно для отдельных запросов по одному пакету, но недостаточно для массового анализа lock-файла.
Сервер определяет токен в следующем порядке:
Переменная окружения
GITHUB_TOKEN, если она задана.gh auth token— если GitHub CLI установлен и авторизован, сервер использует этот токен автоматически. Изменять конфигурацию не нужно.Анонимный доступ (60 запросов/час).
Рекомендуемый способ: используйте CLI gh
Если у вас уже установлен gh (brew install gh && gh auth login), на этом можно остановиться — сервер сам подхватит вашу текущую авторизацию. Токен нигде не хранится в открытом виде.
Альтернативный вариант: переменная окружения
Создайте fine-grained токен на странице https://github.com/settings/tokens:
Имя токена:
dep-diff-mcpСрок действия: 90 дней (периодически перевыпускайте)
Доступ к репозиториям:
Public Repositories (read-only)— без доступа к приватным репозиториямРазрешения: только публичное чтение по умолчанию — не выдавайте области
repo,workflow,userили любые другие разрешения на запись
Затем укажите токен в конфигурации MCP:
{
"mcpServers": {
"dep-diff": {
"command": "npx",
"args": ["-y", "@digicatalyst/dep-diff-mcp"],
"env": { "GITHUB_TOKEN": "github_pat_xxx" }
}
}
}Примечания о безопасности
Этот конфигурационный файл хранится на вашем диске в открытом виде. Держите права доступа жёсткими (
chmod 600) и не вставляйте токен в AI-чаты, issues или общие демонстрации экрана — записи таких сессий часто сохраняются.Токен в конфиге должен иметь наименьшие привилегии (только чтение публичных репозиториев). Даже при утечке он сможет прочитать только те публичные данные, которые вы и так можете прочитать.
Периодически перевыпускайте токены. Отзывайте любой токен, который мог быть раскрыт, на https://github.com/settings/tokens.
Сервер никогда не выводит токен в stdout/stderr и не включает его в ответ (response payload).
Инструменты
analyze_package_change
Анализирует обновление одного пакета. Входные данные: ecosystem (npm или pypi), name, fromVersion, toVersion.
analyze_packages_bulk
Анализирует до 50 обновлений пакетов параллельно. Возвращает пакеты, отсортированные по уровню риска (security > caution > review > likely-safe > safe), плюс сводные счётчики по категориям.
Что вы получаете в ответ
Классификация semver — major / minor / patch / downgrade / unknown
Ломающие изменения — извлечённые из заголовков релизных заметок GitHub
Исправления безопасности — CVE, присутствующие в
fromVersion, но устранённые вtoVersion(через OSV)Ссылки для миграции — URL руководств по обновлению, найденные в релизных заметках
Рекомендация — вердикт в одну строку + уровень риска
Поддерживаемые экосистемы
npm
PyPI
Разработка
npm install
npm run build
GITHUB_TOKEN=ghp_xxx npm run inspect # MCP InspectorЛицензия
MIT
Available Tools
2 toolsanalyze_package_changeAnalyze a single dependency version changeARead-onlyIdempotentInspect
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 | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name (e.g. 'react', 'requests') | |
| ecosystem | Yes | Package ecosystem | |
| toVersion | Yes | Target version (e.g. '19.0.0') | |
| fromVersion | Yes | Current version (e.g. '18.2.0') |
Output Schema
| Name | Required | Description |
|---|---|---|
| package | Yes | Package name that was analyzed |
| repoUrl | Yes | Source repository URL, or null when none could be resolved |
| ecosystem | Yes | Package ecosystem |
| toVersion | Yes | Version being upgraded to |
| fromVersion | Yes | Version being upgraded from |
| semverClass | Yes | Semver relationship between the two versions |
| releaseCount | Yes | Number of GitHub releases found strictly between the two versions |
| securityFixes | Yes | Advisories affecting fromVersion that are resolved at toVersion |
| migrationLinks | Yes | Migration or upgrade guide URLs found in release notes |
| recommendation | Yes | Single-line verdict explaining the recommendation level |
| breakingChanges | Yes | Breaking changes extracted from release notes; empty when none were found |
| releaseExcerpts | No | Raw release-note excerpts, present only as a fallback when a major/minor bump yielded no breaking changes |
| recommendationLevel | Yes | Risk classification, used to rank packages in bulk results |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false). The description adds non-redundant behavioral context: it specifies the structured analysis contents, including semver classification, breaking-change detection, security advisories, and migration links. It also discloses ecosystem-specific naming behavior for github-actions, which is useful behavioral nuance beyond what annotations express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary behavior, then moves through triggers, supported ecosystems, and alternative routing. Every sentence earns its place: the output list sets expectations, the example queries illustrate intent, the ecosystem note prevents mis-use, and the sibling reference prevents mis-routing. The only minor redundancy is repeating 'single package' already in the title, but it reinforces scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and safety annotations covering side effects, the description leaves no critical gap. It explains what the tool returns, exactly when to invoke it, which ecosystems are supported, how to write the name for github-actions, and when to prefer the bulk sibling. An agent has everything necessary to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all four parameters have clear descriptions with examples, so the schema carries most of the burden. The description adds one genuinely useful parameter nuance beyond the schema: for github-actions, the name parameter should use the action reference like 'actions/checkout'. No other parameter semantics are added, so a 4 rather than 5 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource pairing: 'Given one package and two versions... returns a structured upgrade analysis' and enumerates the concrete outputs (semver classification, release notes, breaking changes, advisories, migration links, recommendation). It also explicitly distinguishes itself from the sibling by describing what analyze_packages_bulk is for, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage criteria: 'Use when the user asks about a specific package upgrade' followed by three concrete example queries. It also states the exclusion condition: 'For analyzing many packages at once or a Dependabot batch, use analyze_packages_bulk instead.' This gives clear when-to-use and when-not-to-use guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_packages_bulkAnalyze multiple dependency changes in parallelARead-onlyIdempotentInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| changes | Yes | List of package changes to analyze |
Output Schema
| Name | Required | Description |
|---|---|---|
| packages | Yes | Per-package results, ranked security > caution > review > likely-safe > safe |
| bySemverClass | Yes | Breakdown of the batch by semver class |
| totalPackages | Yes | Number of package changes submitted |
| securityFixesTotal | Yes | Total security advisories resolved across the whole batch |
| packagesWithBreakingChanges | Yes | How many packages had at least one breaking change |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with them. It adds useful behavioral context beyond the annotations by disclosing parallel execution and the 50-package limit with chunking guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three front-loaded sentences with no filler: purpose and result first, usage triggers second, output summary and limit third. Every sentence earns its place and the structure makes the tool easy to evaluate quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations covering safety, a single parameter with full schema coverage, and an output schema, the description is complete. It covers purpose, result contents, common input sources, and the chunking limit. The only minor omission is an explicit pointer to the singular sibling, but the plural focus makes that implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 100%, the schema already explains the single 'changes' parameter and its structure. The description reinforces the bulk nature and the 50-package limit, but it does not add new semantic detail about the parameter fields themselves, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb, resource, and result: it analyzes a list of package upgrades in parallel and returns a unified risk report with packages ranked by recommendation level. It distinguishes itself from the sibling analyze_package_change through its explicit plural/bulk focus, though it does not name the sibling directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance by listing concrete triggers: Dependabot PR, npm outdated output, lockfile diff, or batch upgrade. It does not explicitly state when not to use it or mention the singular alternative, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.3.2- Changed
analyze_package_change2 fields changed- changed
Input schema / properties / ecosystem / enumPrevious value: -[ - "npm", - "pypi" -]New value: +[ + "npm", + "pypi", + "github-actions" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "breakingChanges": { + "description": "Breaking changes extracted from release notes; empty when none were found", + "items": { + "type": "string" + }, + "type": "array" + }, + "ecosystem": { + "description": "Package ecosystem", + "enum": [ + "npm", + "pypi", + "github-actions" + ], + "type": "string" + }, + "fromVersion": { + "description": "Version being upgraded from", + "type": "string" + }, + "migrationLinks": { + "description": "Migration or upgrade guide URLs found in release notes", + "items": { + "type": "string" + }, + "type": "array" + }, + "package": { + "description": "Package name that was analyzed", + "type": "string" + }, + "recommendation": { + "description": "Single-line verdict explaining the recommendation level", + "type": "string" + }, + "recommendationLevel": { + "description": "Risk classification, used to rank packages in bulk results", + "enum": [ + "safe", + "likely-safe", + "review", + "caution", + "security" + ], + "type": "string" + }, + "releaseCount": { + "description": "Number of GitHub releases found strictly between the two versions", + "type": "number" + }, + "releaseExcerpts": { + "description": "Raw release-note excerpts, present only as a fallback when a major/minor bump yielded no breaking changes", + "items": { + "additionalProperties": false, + "properties": { + "excerpt": { + "description": "Short excerpt of the release notes", + "type": "string" + }, + "tag": { + "description": "Release tag the excerpt came from", + "type": "string" + } + }, + "required": [ + "tag", + "excerpt" + ], + "type": "object" + }, + "type": "array" + }, + "repoUrl": { + "description": "Source repository URL, or null when none could be resolved", + "type": [ + "string", + "null" + ] + }, + "securityFixes": { + "description": "Advisories affecting fromVersion that are resolved at toVersion", + "items": { + "additionalProperties": false, + "properties": { + "id": { + "description": "Advisory identifier (e.g. 'GHSA-29mw-wpgm-hmr9' or a CVE)", + "type": "string" + }, + "severity": { + "description": "Severity as reported by OSV (e.g. 'LOW', 'MODERATE', 'HIGH', 'CRITICAL')", + "type": "string" + }, + "summary": { + "description": "One-line description of the advisory", + "type": "string" + } + }, + "required": [ + "id", + "summary", + "severity" + ], + "type": "object" + }, + "type": "array" + }, + "semverClass": { + "description": "Semver relationship between the two versions", + "enum": [ + "major", + "minor", + "patch", + "downgrade", + "unknown" + ], + "type": "string" + }, + "toVersion": { + "description": "Version being upgraded to", + "type": "string" + } + }, + "required": [ + "package", + "ecosystem", + "fromVersion", + "toVersion", + "semverClass", + "repoUrl", + "releaseCount", + "breakingChanges", + "securityFixes", + "migrationLinks", + "recommendation", + "recommendationLevel" + ], + "type": "object" +}
- Changed
analyze_packages_bulk2 fields changed- changed
Input schema / properties / changes / items / properties / ecosystem / enumPrevious value: -[ - "npm", - "pypi" -]New value: +[ + "npm", + "pypi", + "github-actions" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "bySemverClass": { + "additionalProperties": false, + "description": "Breakdown of the batch by semver class", + "properties": { + "major": { + "description": "Count of major bumps", + "type": "number" + }, + "minor": { + "description": "Count of minor bumps", + "type": "number" + }, + "patch": { + "description": "Count of patch bumps", + "type": "number" + } + }, + "required": [ + "major", + "minor", + "patch" + ], + "type": "object" + }, + "packages": { + "description": "Per-package results, ranked security > caution > review > likely-safe > safe", + "items": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "breakingChanges": { + "description": "Breaking changes extracted from release notes; empty when none were found", + "items": { + "type": "string" + }, + "type": "array" + }, + "ecosystem": { + "description": "Package ecosystem", + "enum": [ + "npm", + "pypi", + "github-actions" + ], + "type": "string" + }, + "fromVersion": { + "description": "Version being upgraded from", + "type": "string" + }, + "migrationLinks": { + "description": "Migration or upgrade guide URLs found in release notes", + "items": { + "type": "string" + }, + "type": "array" + }, + "package": { + "description": "Package name that was analyzed", + "type": "string" + }, + "recommendation": { + "description": "Single-line verdict explaining the recommendation level", + "type": "string" + }, + "recommendationLevel": { + "description": "Risk classification, used to rank packages in bulk results", + "enum": [ + "safe", + "likely-safe", + "review", + "caution", + "security" + ], + "type": "string" + }, + "releaseCount": { + "description": "Number of GitHub releases found strictly between the two versions", + "type": "number" + }, + "releaseExcerpts": { + "description": "Raw release-note excerpts, present only as a fallback when a major/minor bump yielded no breaking changes", + "items": { + "additionalProperties": false, + "properties": { + "excerpt": { + "description": "Short excerpt of the release notes", + "type": "string" + }, + "tag": { + "description": "Release tag the excerpt came from", + "type": "string" + } + }, + "required": [ + "tag", + "excerpt" + ], + "type": "object" + }, + "type": "array" + }, + "repoUrl": { + "description": "Source repository URL, or null when none could be resolved", + "type": [ + "string", + "null" + ] + }, + "securityFixes": { + "description": "Advisories affecting fromVersion that are resolved at toVersion", + "items": { + "additionalProperties": false, + "properties": { + "id": { + "description": "Advisory identifier (e.g. 'GHSA-29mw-wpgm-hmr9' or a CVE)", + "type": "string" + }, + "severity": { + "description": "Severity as reported by OSV (e.g. 'LOW', 'MODERATE', 'HIGH', 'CRITICAL')", + "type": "string" + }, + "summary": { + "description": "One-line description of the advisory", + "type": "string" + } + }, + "required": [ + "id", + "summary", + "severity" + ], + "type": "object" + }, + "type": "array" + }, + "semverClass": { + "description": "Semver relationship between the two versions", + "enum": [ + "major", + "minor", + "patch", + "downgrade", + "unknown" + ], + "type": "string" + }, + "toVersion": { + "description": "Version being upgraded to", + "type": "string" + } + }, + "required": [ + "package", + "ecosystem", + "fromVersion", + "toVersion", + "semverClass", + "repoUrl", + "releaseCount", + "breakingChanges", + "securityFixes", + "migrationLinks", + "recommendation", + "recommendationLevel" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "description": "Why the analysis could not be completed", + "type": "string" + }, + "package": { + "description": "Package name whose analysis failed", + "type": "string" + }, + "recommendationLevel": { + "const": "review", + "description": "Always 'review' — a package that could not be analyzed cannot be cleared automatically", + "type": "string" + } + }, + "required": [ + "package", + "error", + "recommendationLevel" + ], + "type": "object" + } + ] + }, + "type": "array" + }, + "packagesWithBreakingChanges": { + "description": "How many packages had at least one breaking change", + "type": "number" + }, + "securityFixesTotal": { + "description": "Total security advisories resolved across the whole batch", + "type": "number" + }, + "totalPackages": { + "description": "Number of package changes submitted", + "type": "number" + } + }, + "required": [ + "totalPackages", + "bySemverClass", + "securityFixesTotal", + "packagesWithBreakingChanges", + "packages" + ], + "type": "object" +}
2 tool updates
v0.1.1- First observed
analyze_package_change - First observed
analyze_packages_bulk
TDQS
The two tools are clearly separated by scope: one handles a single package upgrade, the other handles multiple packages in bulk. Each description explicitly references the other, so an agent can unambiguously choose based on input size.
Both tools follow the same analyze_package_* pattern, with the singular 'change' and plural 'bulk' clearly differentiating them. This is a consistent and predictable verb_noun convention.
Two tools is minimal, but the server's narrow purpose of dependency upgrade analysis is well served by one individual and one bulk entry point. It is slightly thin but not unreasonable for the domain.
The pair covers both single-package and multi-package analysis, which covers most workflows. A minor gap is the lack of direct lockfile/diff parsing, but users can supply the package list from those sources.
Maintenance
Related MCP Connectors
Check exact npm/PyPI upgrades for evidence-backed breaking changes; query APIs and components.
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
npm/PyPI dependency upgrades: package security, compatibility, target ranking, and migration plans.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Related MCP Servers
- AlicenseAqualityCmaintenanceAI-powered dependency vulnerability and breaking change analyzer that scans dependencies, identifies vulnerabilities via OSV.dev, and uses AI to assess real impact and suggest fixes.3Apache 2.0
- AlicenseBqualityDmaintenanceEnables AI agents to safely upgrade JavaScript and TypeScript projects through dependency analysis, upgrade path detection, breaking change identification, codemod application, and PR summary generation.1419MIT
- AlicenseAqualityDmaintenanceAnalyzes database migrations for risks like lock contention and data loss before they run. Supports Flyway and Liquibase formats, providing risk scores and rollback generation.618MIT
- FlicenseNot gradedqualityDmaintenanceProvides breaking changes analysis for libraries across multiple languages, enabling version upgrade planning, dependency audits, and migration reports through MCP tool access and expert workflows.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DigiCatalyst-Systems/dep-diff-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server