niradler/dependency-mcp

Dependency MCP Server

A Model Context Protocol (MCP) server for checking package versions across multiple package managers and registries.

Features

• Multi-language support: Check packages from NPM, PyPI, Maven, NuGet, RubyGems, Crates.io, and Go modules
• Latest version lookup: Get the most recent version of any package
• Version existence check: Verify if a specific version exists
• Package information: Get detailed package metadata including all versions
• Batch processing: Check multiple packages simultaneously for improved efficiency
• Easy installation: Install and run via npx

Supported Package Managers

• npm - Node.js packages
• pypi - Python packages
• maven - Java packages (format: groupId:artifactId)
• nuget - .NET packages
• rubygems - Ruby gems
• crates - Rust crates
• go - Go modules

Installation

Global Installation

npm install -g dependency-mcp

Run with npx (no installation needed)

npx dependency-mcp

Local Development

git clone <repository>
cd dependency-mcp
npm install
npm start

Usage

The server runs as an MCP server using stdio transport. It's designed to be used with MCP-compatible clients.

Available Tools

Single Package Tools

Use these tools when you need to check 1-2 packages or require detailed information:

1. get_latest_version

Get the latest version of a package. Use for dependency updates, version checks, or when you need the most recent stable release.

Parameters:

• package_name (string): Name of the package
• registry (string): Package registry (npm, pypi, maven, nuget, rubygems, crates, go)

Example:

{
  "package_name": "express",
  "registry": "npm"
}

2. check_version_exists

Check if a specific version exists. Use for dependency validation, CI/CD checks, or ensuring version compatibility.

Parameters:

• package_name (string): Name of the package
• version (string): Version to check
• registry (string): Package registry

Example:

{
  "package_name": "flask",
  "version": "2.3.0",
  "registry": "pypi"
}

3. get_package_info

Get detailed package information including all versions. Use for dependency audits, security reviews, or when you need comprehensive package metadata.

Parameters:

• package_name (string): Name of the package
• registry (string): Package registry

Example:

{
  "package_name": "lodash",
  "registry": "npm"
}

Multi-Package Tools

Use these tools when you need to check 3+ packages or perform bulk operations:

4. get_latest_versions

Get latest versions for multiple packages simultaneously. Use when checking 3+ dependencies - processes up to 100 packages in parallel.

Parameters:

• packages (array): Array of package names
• registry (string): Package registry

Example:

{
  "packages": ["react", "lodash", "axios"],
  "registry": "npm"
}

5. check_versions_exist

Check if specific versions exist for multiple packages. Use for bulk dependency validation, CI/CD pipeline checks, or ensuring multiple package version compatibility.

Parameters:

• packages (array): Array of package objects with package_name and version
• registry (string): Package registry

Example:

{
  "packages": [
    { "package_name": "react", "version": "18.2.0" },
    { "package_name": "lodash", "version": "4.17.21" },
    { "package_name": "axios", "version": "1.6.0" }
  ],
  "registry": "npm"
}

6. get_packages_info

Get comprehensive package details for multiple packages. Use for dependency audits, security reviews, or bulk package analysis.

Parameters:

• packages (array): Array of package names
• registry (string): Package registry

Example:

{
  "packages": ["react", "lodash", "axios"],
  "registry": "npm"
}

Tool Selection Guide

When to Use Single Package Tools:

• 1-2 packages to check
• Detailed information needed (versions, homepage, repository)
• Specific version validation for one package
• Quick checks during development

When to Use Multi-Package Tools:

• 3+ packages to check
• Bulk dependency validation
• CI/CD pipeline checks
• Dependency audits or security reviews
• Performance-critical scenarios with multiple packages

Performance Notes:

• Single package tools: Faster for 1-2 packages
• Multi-package tools: 3-5x faster for 5+ packages due to parallel processing
• Error isolation: Failed packages don't break the entire batch
• Batch limits: Maximum 100 packages per request

Batch Processing

The multi-package tools provide significant performance improvements when checking multiple packages:

Benefits

• Eliminates round-trip delays: Check up to 100 packages in a single request
• Consistent error handling: Individual package failures don't break the entire batch
• Parallel processing: All packages are checked concurrently for maximum efficiency
• Reduced API overhead: Fewer HTTP requests to external registries

Limitations

• Maximum batch size: 100 packages per request
• Rate limiting: Built-in delays prevent overwhelming external APIs
• Timeout handling: 10-second timeout per request with graceful fallback
• Memory usage: Large batches may consume more memory

When to Use Batch Tools

• Dependency audits: Check multiple packages in your project
• Version comparisons: Compare versions across multiple packages
• Bulk updates: Identify which packages have newer versions available
• CI/CD pipelines: Validate multiple package versions simultaneously

Production Considerations

Performance

• Concurrent processing: Multi-package tools use Promise.all for parallel execution
• Rate limiting: Built-in 100ms delay between requests to external APIs
• Timeout handling: 10-second timeout with graceful error handling
• Memory management: Efficient processing of large batches

Reliability

• Error isolation: Individual package failures don't affect others in the batch
• Network resilience: Handles temporary network issues gracefully
• API fallbacks: Graceful degradation when external APIs are unavailable
• Validation: Comprehensive input validation prevents invalid requests
• Registry-specific handling: Maven registry may be slower in some network environments

Security

• Input sanitization: All inputs are validated and sanitized
• Rate limiting: Prevents abuse of external APIs
• Error messages: Safe error messages that don't expose internal details
• Timeout protection: Prevents hanging requests

Monitoring

• Timestamps: All responses include ISO timestamps for tracking
• Error tracking: Detailed error information for debugging
• Performance metrics: Built-in timeout and rate limiting tracking

Configuration with Claude Desktop

Add this to your Claude Desktop configuration file:

Windows

%APPDATA%\Claude\claude_desktop_config.json

macOS

~/Library/Application Support/Claude/claude_desktop_config.json

Linux

~/.config/claude/claude_desktop_config.json

{
  "mcpServers": {
    "dependency-checker": {
      "command": "npx",
      "args": ["dependency-mcp"]
    }
  }
}

Example Responses

Latest Version Response

{
  "package": "express",
  "registry": "npm",
  "found": true,
  "latest_version": "4.18.2",
  "description": "Fast, unopinionated, minimalist web framework"
}

Version Check Response

{
  "package": "flask",
  "version": "2.3.0",
  "registry": "pypi",
  "exists": true
}

Package Info Response

{
  "package": "lodash",
  "registry": "npm",
  "found": true,
  "latest_version": "4.17.21",
  "description": "Lodash modular utilities.",
  "versions": ["4.17.21", "4.17.20", "..."],
  "homepage": "https://lodash.com/",
  "repository": "git+https://github.com/lodash/lodash.git"
}

Special Format Notes

Maven

Maven packages should be specified in the format groupId:artifactId:

{
  "package_name": "org.springframework:spring-core",
  "registry": "maven"
}

Go Modules

Go modules should use the full module path:

{
  "package_name": "github.com/gorilla/mux",
  "registry": "go"
}

Error Handling

The server provides detailed error messages for common scenarios:

• Package not found
• Network connectivity issues
• Invalid package name formats
• Registry API errors
• Rate limiting exceeded
• Server errors (5xx responses)
• Request timeouts
• Input validation errors

Error Response Format

All error responses include:

• error: Human-readable error message
• timestamp: ISO timestamp of when the error occurred
• package: Package name that caused the error
• registry: Registry where the error occurred

Input Validation

The server validates all inputs:

• Package names: Must be non-empty strings under 500 characters
• Versions: Must be non-empty strings under 100 characters
• Registry: Must be one of the supported registries
• Batch size: Maximum 100 packages per request
• Required parameters: All required fields must be present

Response Expectations

Single Package Tools:

• Success: Returns complete package information with found: true
• Not Found: Returns found: false with error message
• Network Issues: Returns error with descriptive message
• Always includes: timestamp, package, registry fields

Multi-Package Tools:

• Success: Returns array of results, each with individual status
• Partial Success: Some packages succeed, others fail - each has individual result
• Error Isolation: Failed packages don't affect successful ones
• Batch Processing: All packages processed in parallel for efficiency
• Consistent Format: Each result follows same structure as single package tools

Development

Project Structure

dependency-mcp/
├── src/
│   ├── index.js          # Main MCP server
│   └── packageChecker.js # Package registry handlers
├── test/
│   └── test.js          # Basic tests
├── package.json
└── README.md

Running Tests

npm test

Debug Mode

npm run dev

License

MIT