What can Package Registry Search do?

multi-registry package metadata retrieval, package version history and release timeline retrieval, package dependency graph extraction, cross-registry package search and discovery, package metadata normalization and schema mapping, package download statistics and popularity metrics retrieval

Package Registry Search

MCP ServerFree

** - Search and get up-to-date information about NPM, Cargo, PyPi, and NuGet packages.

Open Source

/ 100

6 capabilities

Capabilities6 decomposed

multi-registry package metadata retrieval

Medium confidence

Fetches real-time package metadata from four major package registries (NPM, Cargo, PyPI, NuGet) through their public APIs, normalizing responses into a unified schema. Implements registry-specific API clients that handle authentication, rate limiting, and response parsing for each ecosystem's distinct metadata format, enabling unified querying across language boundaries without requiring separate tool integrations.

Solves for

I need to check if a package exists and get its latest version across multiple languagesI want to retrieve dependency information for a package in any supported ecosystemI need to fetch package metadata (author, license, description) from a single query interfaceI'm building a tool that needs to work with packages from multiple registries without separate API calls

Best for

polyglot development teams managing dependencies across Node.js, Python, Rust, and .NET projects

AI agents and LLM applications that need to reason about package ecosystems

dependency management tools and package analysis platforms

Requires

Network connectivity to NPM Registry (registry.npmjs.org), PyPI (pypi.org), Cargo (crates.io), and NuGet (api.nuget.org)

MCP server runtime (Node.js 16+ or compatible)

No API keys required for public package queries

Limitations

Rate limiting varies by registry — NPM allows ~600 requests/hour, PyPI ~60 requests/minute; no built-in rate limit management or queuing

Metadata freshness depends on registry update frequency; PyPI and Cargo may lag 5-30 seconds behind actual publishes

No support for private registries, scoped packages with authentication, or registry mirrors

What makes it unique

Unified MCP interface abstracting four distinct package registry APIs (NPM, Cargo, PyPI, NuGet) with normalized response schemas, allowing single-query access across language ecosystems without maintaining separate API client libraries or authentication flows

vs alternatives

Broader registry coverage than npm-only tools like npm-check-updates, and simpler integration than maintaining separate clients for each registry's REST API

package version history and release timeline retrieval

Medium confidence

Queries registry APIs to retrieve complete version history, release dates, and changelog metadata for a package across all supported registries. Parses registry-specific version schemas (semver for NPM/Cargo, PEP 440 for PyPI, NuGet versioning) and returns chronologically ordered release information with timestamps, enabling version-aware dependency analysis and upgrade planning.

Solves for

I need to see all available versions of a package to understand its release cadenceI want to find when a specific bug was fixed or feature was added by checking release datesI need to identify deprecated or yanked versions before upgrading dependenciesI'm analyzing package maturity by examining version history and release frequency

Best for

dependency upgrade planners and security vulnerability scanners

package maintainers analyzing release patterns and version adoption

AI agents performing semantic versioning analysis and compatibility checks

Requires

Network connectivity to target package registry

MCP server runtime

Package name and registry identifier

Limitations

Changelog content is not extracted — only version numbers and timestamps are returned; detailed release notes require separate scraping

Yanked/deprecated version metadata is inconsistent across registries — NPM clearly marks yanked versions, but PyPI and Cargo require additional API calls

Version history is limited to last 100-500 versions depending on registry; full history for very old packages may be incomplete

What makes it unique

Normalizes version schema differences across four ecosystems (semver, PEP 440, NuGet versioning) into a unified timeline format with registry-specific metadata like yanked status, enabling cross-registry version comparison without manual schema translation

vs alternatives

Handles version history across multiple ecosystems in one call, whereas npm-check-updates and similar tools are language-specific and require separate queries per registry

package dependency graph extraction

Medium confidence

Extracts direct and transitive dependencies for a specified package version from registry metadata, parsing dependency manifests (package.json for NPM, Cargo.toml for Cargo, requirements.txt metadata for PyPI, packages.config for NuGet). Returns structured dependency lists with version constraints, enabling downstream dependency analysis, conflict detection, and supply chain mapping without requiring local package installation.

Solves for

I need to see what dependencies a package requires before installing itI want to detect potential dependency conflicts or version constraint mismatchesI'm mapping the full dependency tree to understand supply chain riskI need to find which packages depend on a specific library to assess impact of updates

Best for

supply chain security tools analyzing transitive dependencies

dependency conflict resolution engines in package managers

AI agents building dependency graphs for vulnerability propagation analysis

Requires

Network connectivity to target package registry

MCP server runtime

Package name and specific version (not latest)

Limitations

Only direct dependencies are reliably available from registry metadata; transitive dependency resolution requires recursive queries and is not built-in

Conditional dependencies (e.g., platform-specific, optional) are not fully parsed — returned as-is from registry without normalization

Dependency version constraints are returned as-is (e.g., '^1.2.3', '~1.2', '>=1.0,<2.0'); no constraint resolution or compatibility checking is performed

What makes it unique

Parses and normalizes dependency manifests from four distinct package manager formats (package.json, Cargo.toml, PyPI metadata, NuGet packages.config) into a unified dependency schema without requiring local package installation or manifest downloads

vs alternatives

Avoids the overhead of npm install or pip install by reading metadata directly from registries, making it 10-100x faster than local dependency resolution for quick audits

cross-registry package search and discovery

Medium confidence

Implements keyword-based search across all four supported registries, querying each registry's search API and returning ranked results with relevance scores. Normalizes search result schemas from different registries and optionally aggregates results across registries, enabling discovery of similar or alternative packages across language ecosystems without switching tools.

Solves for

I need to find a package that does X but I'm not sure of the exact nameI want to discover alternative implementations of a library across different languagesI'm searching for packages matching specific keywords to evaluate optionsI need to find all packages by a specific author or organization across registries

Best for

developers exploring package ecosystems and discovering new libraries

package recommendation systems and AI agents suggesting alternatives

teams evaluating multiple language implementations of the same functionality

Requires

Network connectivity to target package registries

MCP server runtime

Search query string (minimum 2-3 characters for most registries)

Limitations

Search relevance algorithms differ by registry — NPM uses download popularity, PyPI uses recency, Cargo uses quality metrics; no unified ranking across registries

Search API rate limits are stricter than metadata queries — typically 10-30 requests/minute depending on registry

Full-text search is not supported for all registries; some registries only search package names and descriptions, not code content

What makes it unique

Aggregates search results from four distinct registry search APIs with different ranking algorithms and result formats, normalizing them into a unified result set with cross-registry comparison capabilities

vs alternatives

Enables single-query cross-language package discovery, whereas developers typically search each registry separately using language-specific tools or web interfaces

package metadata normalization and schema mapping

Medium confidence

Normalizes heterogeneous metadata schemas from four package registries into a unified data structure, mapping registry-specific fields (e.g., NPM's 'dist.tarball' to Cargo's 'crate_url') and handling missing or optional fields gracefully. Implements field mapping logic that translates between registry conventions (e.g., 'author' vs 'authors', 'license' vs 'licenses') and provides consistent access patterns for downstream consumers.

Solves for

I need consistent package metadata regardless of which registry it comes fromI want to build tools that work with packages from multiple registries without conditional logicI need to compare package metadata across registries in a normalized formatI'm building a database or index that aggregates packages from multiple sources

Best for

package aggregation platforms and polyglot package indexes

AI agents that need consistent metadata schemas for reasoning

tools that need to work uniformly across multiple package ecosystems

Requires

MCP server runtime

Package metadata from one or more registries (typically output from metadata retrieval capability)

Limitations

Some registry-specific metadata is lost in normalization — e.g., NPM's 'dist' object details, Cargo's 'yanked' status are not fully preserved

Optional fields may be null or missing in normalized output; no default values are provided for missing metadata

Nested metadata structures (e.g., multiple authors, licenses) are flattened; complex relationships may be lost

What makes it unique

Implements bidirectional schema mapping between four distinct package metadata formats, preserving registry-specific semantics while providing a unified interface that abstracts away ecosystem differences

vs alternatives

Eliminates the need for consumers to write registry-specific parsing logic; provides a single normalized schema instead of requiring conditional handling for each registry

package download statistics and popularity metrics retrieval

Medium confidence

Fetches download counts, usage statistics, and popularity metrics from registries that expose them (NPM, PyPI), aggregating data points like weekly downloads, total downloads, and trend information. Normalizes popularity metrics across registries that use different measurement approaches (NPM uses npm-stat API, PyPI uses BigQuery public dataset), enabling comparative popularity analysis across ecosystems.

Solves for

I want to compare package popularity across different registriesI need to assess package adoption and community usage before depending on itI'm analyzing ecosystem trends and package growth patternsI want to identify rising packages and declining projects in my dependency tree

Best for

package recommendation engines that factor in popularity and adoption

ecosystem analysis tools tracking package trends and growth

AI agents evaluating package maturity and community support

Requires

Network connectivity to NPM stat API and PyPI BigQuery dataset (or PyPI JSON API for basic stats)

MCP server runtime

Package name and registry identifier

Limitations

Download statistics are only available for NPM and PyPI; Cargo and NuGet do not expose download counts, limiting cross-registry popularity comparison

NPM download data is delayed by 1-2 days; PyPI data is updated daily but may lag actual downloads

Download counts can be inflated by CI/CD systems, bots, and automated tools; raw counts do not reflect actual human usage

What makes it unique

Aggregates download statistics from NPM and PyPI using their distinct data sources (npm-stat API vs PyPI BigQuery), normalizing metrics into comparable popularity scores despite different measurement methodologies

vs alternatives

Provides unified popularity metrics across multiple registries, whereas npm-check-updates and similar tools only track downloads within a single ecosystem

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Related Artifactssharing capabilities

Artifacts that share capabilities with Package Registry Search, ranked by overlap. Discovered automatically through the match graph.

Model36

opensrc

Fetch source code for npm packages to give AI coding agents deeper context

list and inspect fetched packages with metadata reportingmulti-registry package discovery and resolutionnpm registry integration with version resolution

3 shared capabilities

MCP Server21

spm-mcp

** - iOS Swift Package Manager server written in Swift

package metadata and registry queryingtransitive dependency graph traversal and analysis

2 shared capabilities

MCP Server20

NPM Search

** - Search for npm packages

npm-package-metadata-extractionnpm-registry-package-search

2 shared capabilities

MCP Server21

godoc-mcp-server

** - MCP server to provide golang packages and their information from pkg.go.dev

golang-package-version-history-and-release-trackinggolang-package-dependency-graph-traversal

2 shared capabilities

Product20

Chroma Package Search

** - Add to coding agents like Claude or Cursor to give them the ability to understand and better use thousands of dependencies.

dependency compatibility and version resolution guidancesemantic package dependency search and retrieval

2 shared capabilities

MCP Server44

octocode-mcp

MCP server for semantic code research and context generation on real-time using LLM patterns | Search naturally across public & private repos based on your permissions | Transform any accessible codebase/s into AI-optimized knowledge on simple and complex flows | Find real implementations and live d

package registry search and dependency analysis

1 shared capability

Best For

✓polyglot development teams managing dependencies across Node.js, Python, Rust, and .NET projects
✓AI agents and LLM applications that need to reason about package ecosystems
✓dependency management tools and package analysis platforms
✓developers building cross-language monorepos or multi-ecosystem CI/CD pipelines
✓dependency upgrade planners and security vulnerability scanners
✓package maintainers analyzing release patterns and version adoption
✓AI agents performing semantic versioning analysis and compatibility checks
✓teams evaluating package stability before adopting new dependencies

Known Limitations

⚠Rate limiting varies by registry — NPM allows ~600 requests/hour, PyPI ~60 requests/minute; no built-in rate limit management or queuing
⚠Metadata freshness depends on registry update frequency; PyPI and Cargo may lag 5-30 seconds behind actual publishes
⚠No support for private registries, scoped packages with authentication, or registry mirrors
⚠Response latency is additive across registries — querying all four registries sequentially adds 2-4 seconds per request
⚠Changelog content is not extracted — only version numbers and timestamps are returned; detailed release notes require separate scraping
⚠Yanked/deprecated version metadata is inconsistent across registries — NPM clearly marks yanked versions, but PyPI and Cargo require additional API calls

Requirements

Network connectivity to NPM Registry (registry.npmjs.org), PyPI (pypi.org), Cargo (crates.io), and NuGet (api.nuget.org)MCP server runtime (Node.js 16+ or compatible)No API keys required for public package queriesNetwork connectivity to target package registryMCP server runtimePackage name and registry identifierPackage name and specific version (not latest)Network connectivity to target package registries

Input / Output

Accepts: package name (string), registry identifier (enum: npm, cargo, pypi, nuget), optional version specifier (semver range or exact version), optional limit parameter for number of versions to return, package version (string, required for accurate dependency resolution), search query (string, free-form keywords), registry identifier (enum: npm, cargo, pypi, nuget, or 'all' for cross-registry search), optional result limit and offset for pagination, raw registry API response (JSON), registry identifier (enum: npm, cargo, pypi, nuget) for schema selection, registry identifier (enum: npm, pypi; cargo and nuget not supported), optional time range for historical statistics (e.g., last 30 days, last year)

Produces: structured JSON with package metadata (name, version, description, author, license, homepage, repository URL), dependency list with version constraints, download statistics and publish timestamps, array of version objects with: version string, publish timestamp, yanked/deprecated status, chronologically ordered release timeline, version count and date range span, array of dependency objects with: dependency name, version constraint, optional/required flag, structured JSON mapping dependencies to their constraints, dependency count and constraint complexity metrics, array of search result objects with: package name, description, author, download/popularity metrics, registry source, relevance score or ranking position, total result count and pagination metadata, normalized package metadata object with consistent field names and structure, JSON schema conforming to unified package metadata specification, metadata completeness score indicating which fields are populated, download count (total and weekly/monthly averages), trend data (growth rate, velocity), popularity rank within registry, timestamp of last update

UnfragileRank

Adoption15%(30% weight)

Quality14%(25% weight)

Ecosystem30%(25% weight)

Match Graph10%(15% weight)

Freshness75%(5% weight)

UnfragileRank is computed from adoption signals, documentation quality, ecosystem connectivity, match graph feedback, and freshness. No artifact can pay for a higher rank.

Type: MCP Server

6 capabilities

Visit Package Registry Search→

About

** - Search and get up-to-date information about NPM, Cargo, PyPi, and NuGet packages.

Alternatives to Package Registry Search

IntelliCode50Extension

AI-assisted development

Compare →

GitHub Copilot Chat53Extension

AI chat features powered by Copilot

Compare →

GitHub Copilot52Extension

Your AI pair programmer

Compare →

Claude Code for VS Code52Extension

Claude Code for VS Code: Harness the power of Claude Code without leaving your IDE

Compare →

Are you the builder of Package Registry Search?

Claim this artifact to get a verified badge, access match analytics, see which intents users search for, and manage your listing.

Claim this artifact →Verification via email

Get the weekly brief

New tools, rising stars, and what's actually worth your time. No spam.

Data Sources

github awesome

Looking for something else?

Search →

Capabilities6 decomposed

multi-registry package metadata retrieval

Medium confidence

Solves for

Best for

polyglot development teams managing dependencies across Node.js, Python, Rust, and .NET projects

AI agents and LLM applications that need to reason about package ecosystems

dependency management tools and package analysis platforms

Requires

Network connectivity to NPM Registry (registry.npmjs.org), PyPI (pypi.org), Cargo (crates.io), and NuGet (api.nuget.org)

MCP server runtime (Node.js 16+ or compatible)

No API keys required for public package queries

Limitations

Rate limiting varies by registry — NPM allows ~600 requests/hour, PyPI ~60 requests/minute; no built-in rate limit management or queuing

Metadata freshness depends on registry update frequency; PyPI and Cargo may lag 5-30 seconds behind actual publishes

No support for private registries, scoped packages with authentication, or registry mirrors

What makes it unique

vs alternatives

Broader registry coverage than npm-only tools like npm-check-updates, and simpler integration than maintaining separate clients for each registry's REST API

package version history and release timeline retrieval

Medium confidence

Solves for

Best for

dependency upgrade planners and security vulnerability scanners

package maintainers analyzing release patterns and version adoption

AI agents performing semantic versioning analysis and compatibility checks

Requires

Network connectivity to target package registry

MCP server runtime

Package name and registry identifier

Limitations

Changelog content is not extracted — only version numbers and timestamps are returned; detailed release notes require separate scraping

Yanked/deprecated version metadata is inconsistent across registries — NPM clearly marks yanked versions, but PyPI and Cargo require additional API calls

Version history is limited to last 100-500 versions depending on registry; full history for very old packages may be incomplete

What makes it unique

vs alternatives

Handles version history across multiple ecosystems in one call, whereas npm-check-updates and similar tools are language-specific and require separate queries per registry

package dependency graph extraction

Medium confidence

Solves for

Best for

supply chain security tools analyzing transitive dependencies

dependency conflict resolution engines in package managers

AI agents building dependency graphs for vulnerability propagation analysis

Requires

Network connectivity to target package registry

MCP server runtime

Package name and specific version (not latest)

Limitations

Only direct dependencies are reliably available from registry metadata; transitive dependency resolution requires recursive queries and is not built-in

Conditional dependencies (e.g., platform-specific, optional) are not fully parsed — returned as-is from registry without normalization

Dependency version constraints are returned as-is (e.g., '^1.2.3', '~1.2', '>=1.0,<2.0'); no constraint resolution or compatibility checking is performed

What makes it unique

vs alternatives

Avoids the overhead of npm install or pip install by reading metadata directly from registries, making it 10-100x faster than local dependency resolution for quick audits

cross-registry package search and discovery

Medium confidence

Solves for

Best for

developers exploring package ecosystems and discovering new libraries

package recommendation systems and AI agents suggesting alternatives

teams evaluating multiple language implementations of the same functionality

Requires

Network connectivity to target package registries

MCP server runtime

Search query string (minimum 2-3 characters for most registries)

Limitations

Search relevance algorithms differ by registry — NPM uses download popularity, PyPI uses recency, Cargo uses quality metrics; no unified ranking across registries

Search API rate limits are stricter than metadata queries — typically 10-30 requests/minute depending on registry

Full-text search is not supported for all registries; some registries only search package names and descriptions, not code content

What makes it unique

vs alternatives

Enables single-query cross-language package discovery, whereas developers typically search each registry separately using language-specific tools or web interfaces

package metadata normalization and schema mapping

Medium confidence

Solves for

Best for

package aggregation platforms and polyglot package indexes

AI agents that need consistent metadata schemas for reasoning

tools that need to work uniformly across multiple package ecosystems

Requires

MCP server runtime

Package metadata from one or more registries (typically output from metadata retrieval capability)

Limitations

Some registry-specific metadata is lost in normalization — e.g., NPM's 'dist' object details, Cargo's 'yanked' status are not fully preserved

Optional fields may be null or missing in normalized output; no default values are provided for missing metadata

Nested metadata structures (e.g., multiple authors, licenses) are flattened; complex relationships may be lost

What makes it unique

vs alternatives

Eliminates the need for consumers to write registry-specific parsing logic; provides a single normalized schema instead of requiring conditional handling for each registry

package download statistics and popularity metrics retrieval

Medium confidence

Solves for

Best for

package recommendation engines that factor in popularity and adoption

ecosystem analysis tools tracking package trends and growth

AI agents evaluating package maturity and community support

Requires

Network connectivity to NPM stat API and PyPI BigQuery dataset (or PyPI JSON API for basic stats)

MCP server runtime

Package name and registry identifier

Limitations

Download statistics are only available for NPM and PyPI; Cargo and NuGet do not expose download counts, limiting cross-registry popularity comparison

NPM download data is delayed by 1-2 days; PyPI data is updated daily but may lag actual downloads

Download counts can be inflated by CI/CD systems, bots, and automated tools; raw counts do not reflect actual human usage

What makes it unique

vs alternatives

Provides unified popularity metrics across multiple registries, whereas npm-check-updates and similar tools only track downloads within a single ecosystem

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Alternatives to Package Registry Search

IntelliCode50Extension

AI-assisted development

Compare →

GitHub Copilot Chat53Extension

AI chat features powered by Copilot

Compare →

GitHub Copilot52Extension

Your AI pair programmer

Compare →

Claude Code for VS Code52Extension

Claude Code for VS Code: Harness the power of Claude Code without leaving your IDE

Compare →

Package Registry Search

Capabilities6 decomposed

multi-registry package metadata retrieval

package version history and release timeline retrieval

package dependency graph extraction

cross-registry package search and discovery

package metadata normalization and schema mapping

package download statistics and popularity metrics retrieval

Related Artifactssharing capabilities

opensrc

spm-mcp

NPM Search

godoc-mcp-server

Chroma Package Search

octocode-mcp

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

About

Categories

Alternatives to Package Registry Search

Are you the builder of Package Registry Search?

Get the weekly brief

Data Sources

Package Registry Search

Capabilities6 decomposed

multi-registry package metadata retrieval

package version history and release timeline retrieval

package dependency graph extraction

cross-registry package search and discovery

package metadata normalization and schema mapping

package download statistics and popularity metrics retrieval

Related Artifactssharing capabilities

opensrc

spm-mcp

NPM Search

godoc-mcp-server

Chroma Package Search

octocode-mcp

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

About

Categories

Alternatives to Package Registry Search

Are you the builder of Package Registry Search?

Get the weekly brief

Data Sources