dep-diff-mcp

Analyze multiple dependency changes in parallel

analyze_packages_bulk

Read-onlyIdempotent

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).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "changes": "<changes>"
    },
    "name": "analyze_packages_bulk"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 6, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral detail beyond the annotations: it discloses parallel execution, the unified risk report structure, the explicit recommendation ordering (security > caution > review > likely-safe > safe), the returned aggregates, and the 50-package limit with a chunking instruction. The readOnlyHint, openWorldHint, and idempotentHint are already provided by annotations, and the description does not contradict them. This is a strong, transparent behavioral profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tightly structured: purpose first, then use case, then return content, then a practical limit. It is four sentences with no filler, and every sentence adds information an agent needs to invoke correctly or set expectations. The limit and chunking guidance is efficiently placed at the end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one well-schematized parameter, a rich output schema, and annotations covering safety and idempotency, the description is complete. It covers what the tool does, common triggers, output content, and operational constraints (parallel, 50-item limit, chunking). Nothing an agent needs to decide between this and the singular sibling is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the schema already documents the 'changes' array and the ecosystem enum. The description adds contextual color by calling the items 'package upgrades' and referencing batch sources, but it does not add significant semantic detail about the fromVersion or toVersion fields, which remain self-explanatory. This meets the adequate threshold without exceeding the schema-driven baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Analyzes a list of package upgrades in parallel and returns a unified risk report with packages ranked by recommendation level.' It clearly distinguishes itself from the singular sibling tool by explicitly targeting 'many dependency changes' and listing concrete batch sources like Dependabot PRs, npm outdated output, lockfile diffs, and batch upgrades. The ranking order further clarifies the tool's specific output, leaving no ambiguity about what it does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear when-to-use context: 'Use when the user provides many dependency changes from a Dependabot PR, npm outdated output, lockfile diff, or batch upgrade.' This strongly implies that single changes belong to the sibling analyze_package_change tool, but it does not explicitly name the alternative or state a when-not condition. That is a clear usage context without formal exclusions, so it misses the top score only slightly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All dep-diff-mcp tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.