Provides tools for checking npm package health (downloads, last publish, deprecation, license), comparing alternatives, estimating bundle size via bundlephobia, detecting deprecations, and checking vulnerabilities via OSV.dev.
Provides tools for checking PyPI package health (downloads, last publish, yanked status, license), comparing alternatives, detecting yanked packages, and checking vulnerabilities via OSV.dev.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pkg-intel-mcp Is 'request' deprecated?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Package intelligence for AI coding agents. An MCP server that answers: is this npm package safe to recommend?
AI coding agents constantly recommend outdated or deprecated packages — request, moment, tslint — because their training data is frozen in time. pkg-intel-mcp gives any MCP client (Claude Desktop, Claude Code, Cursor, Windsurf, ...) live tools to check package health before suggesting an install.
Tool | What it answers | Registries |
| Is this package alive? Downloads, last publish, deprecation, license, and a healthy / caution / avoid verdict. | npm, PyPI |
| Which of these 2–5 alternatives should I pick? Side-by-side with a recommendation. | npm, PyPI |
| What does this cost my frontend bundle? Minified + gzip via bundlephobia. | npm |
| Is this deprecated (npm) or yanked (PyPI), and what should I use instead? | npm, PyPI |
| Any known CVEs in this package/version, and which version fixes them? Via OSV.dev. | npm, PyPI |
All registry-aware tools take an optional registry parameter ("npm" default, or "pypi"). No API keys required — everything runs against public endpoints (npm registry, PyPI, pypistats, bundlephobia, OSV.dev) with a 15-minute in-memory cache.
Related MCP server: @4da/mcp-server
Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"pkg-intel": {
"command": "npx",
"args": ["-y", "pkg-intel-mcp"]
}
}
}Restart Claude Desktop fully (quit from the menu bar), then ask: "Is request still okay to use? What should I use instead?"
Same JSON shape in ~/.cursor/mcp.json — see examples/ for copy-paste configs, including local development setup.
npm install
npm run dev # run with tsx
npm test # vitest, fully mocked, no network
npm run inspect # MCP Inspector against the built serverRules of the road: never console.log (stdout is the JSON-RPC channel — use console.error), keep module: Node16 in tsconfig, and verify tools in the Inspector before blaming a client config. See CLAUDE.md for full conventions.
stdio is the default and right for personal use. For a shared server:
pkg-intel-mcp --http 3000
# MCP endpoint: POST http://host:3000/mcp
# Liveness: GET http://host:3000/healthzThe HTTP mode is fully stateless — no sessions, no sticky routing — so it scales behind any plain load balancer.
v1: core tools, stdio, npm publish
v1.1: vulnerability_check via OSV.dev (also key-free)
v2: PyPI support, stateless Streamable HTTP transport
v2.1: migrate to MCP SDK v2 / 2026-07-28 spec once stable
Later: Rust crates.io support, SBOM audit tool
MIT
Get the minified and gzipped bundle size of an npm package (via bundlephobia), plus its dependency count. npm only — bundle size has no PyPI equivalent. Use when frontend bundle weight matters.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, e.g. 'express' or '@tanstack/react-query' (npm), 'requests' (PyPI) | |
| version | No | Exact version, e.g. '4.17.21'. Omit to use the latest version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It explains the data source (bundlephobia), the exact outputs (minified/gzipped size and dependency count), and the input expectations (npm package, optional version). No side effects are mentioned, but the read-only nature is implied and appropriate.
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 concise, using two sentences to convey purpose, scope, and usage context. Every clause adds value; no redundant information.
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 no output schema, the description adequately specifies what is returned (bundle size, gzip size, dependency count) and the data source. It does not mention error handling or edge cases, but for a straightforward query tool this is sufficient.
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%, so baseline is 3. The description adds minimal parameter-specific detail beyond the schema (e.g., it reinforces the npm-only context but does not elaborate on version handling), so no increase is warranted.
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 the tool retrieves minified and gzipped bundle size and dependency count via bundlephobia, with a specific resource (npm package). It also distinguishes itself by noting npm-only and no PyPI equivalent, which helps differentiation from siblings.
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 a clear usage condition ('when frontend bundle weight matters') and notes the npm-only scope, giving implicit comparison with siblings. However, it does not explicitly name alternative tools or when not to use it, so it's slightly less directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-5 packages from the same registry (npm or PyPI) side by side on adoption, maintenance freshness, deprecation status, and bundle size (npm only). Returns a structured comparison and a recommendation. Use when choosing between alternative libraries.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | 2-5 package names to compare side by side | |
| registry | No | Package registry to query: 'npm' for JavaScript/TypeScript packages, 'pypi' for Python packages. Defaults to npm. | npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must carry the burden. It describes the action and output (structured comparison and recommendation) but does not explicitly mention that it only reads registry data or any potential side effects/latency. It's implicit but not explicit.
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?
Two sentences, front-loaded with the action and scope. No superfluous words.
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?
Complete for decision-making: it explains what is compared, the registry constraint, and when to use it. The lack of output schema is compensated by the promise of a 'structured comparison and recommendation'.
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 descriptions cover both parameters (names array with min/max, registry enum with default). The description itself does not add extra beyond the schema, but it does reinforce the count and the bundle size caveat. Since coverage is 100%, baseline 3 applies.
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?
States a specific verb 'compare' and resource 'packages' with clear scope (same registry, side-by-side attributes). Clearly distinguishes from sibling tools by emphasizing comparison and the specific metrics.
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?
Explicitly states use case: 'Use when choosing between alternative libraries.' Also clarifies the registry limitation for bundle size (npm only) and that it compares within a single registry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an npm package is deprecated or a PyPI package is yanked, including the message which often names the recommended replacement.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, e.g. 'express' or '@tanstack/react-query' (npm), 'requests' (PyPI) | |
| registry | No | Package registry to query: 'npm' for JavaScript/TypeScript packages, 'pypi' for Python packages. Defaults to npm. | npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the action (check) and the return content (message), implying a read-only operation. It lacks an explicit side-effect statement, but the verb 'Check' strongly suggests non-mutating behavior.
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 a single, concise sentence that conveys all necessary information without redundancy. It is well-structured and easy to parse, with no filler or ambiguous wording.
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?
The description mentions the output (including the replacement message) but does not specify the exact return format (e.g., boolean, object with fields). Given the low complexity of the tool and the absence of an output schema, the description provides enough context for basic usage but could be more explicit.
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?
Both parameters have detailed descriptions in the schema, including examples for 'name' and a full explanation of the 'registry' enum with defaults and language associations. Schema coverage is 100%, and the descriptions add meaningful guidance beyond field labels.
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 uses the specific verb 'Check' and clearly identifies the resource (npm/PyPI packages) and the specific status (deprecated/yanked). It distinguishes itself from sibling tools like package_health or vulnerability_check by focusing solely on deprecation/yank status.
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 provides clear context about what the tool does and what it returns (including the replacement message), making its intended use obvious. It does not explicitly mention when to use this tool versus siblings, but the specific purpose is self-evident from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a health report for an npm or PyPI package: weekly downloads, last publish date, deprecation/yank status, license, and a healthy/caution/avoid verdict with reasons. Use this before recommending or installing a package.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, e.g. 'express' or '@tanstack/react-query' (npm), 'requests' (PyPI) | |
| registry | No | Package registry to query: 'npm' for JavaScript/TypeScript packages, 'pypi' for Python packages. Defaults to npm. | npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation that returns a report with specific fields. It does not mention side effects, errors, or external network calls, but for a simple query tool the description is sufficiently transparent.
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 concise and well-structured, with the core purpose and output fields in the first sentence and usage guidance in the second. It is front-loaded and every sentence adds value.
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 there is no output schema, the description compensates by listing the main output fields (weekly downloads, last publish date, deprecation/yank status, license, verdict). It does not detail error conditions or verdict criteria, but these are not essential for invoking the tool correctly in most cases.
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 coverage is 100%, so the baseline is 3. The parameter descriptions in the schema already explain the 'name' examples and the 'registry' enum values and default. The tool description adds no additional parameter semantics beyond the schema.
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 the tool retrieves a health report for an npm or PyPI package, listing key metrics like weekly downloads, last publish date, deprecation status, license, and a verdict. This distinguishes it from sibling tools such as compare_packages, bundle_size, deprecation_check, and vulnerability_check.
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 final sentence 'Use this before recommending or installing a package' gives explicit use context. However, it does not explicitly mention when not to use it in favor of the more specific sibling tools, though the name and description imply overall health rather than a single aspect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a package for known security vulnerabilities via OSV.dev. Give a version to check that exact version, or omit it to check the latest release. Returns advisory IDs, CVEs, severity, and fixed versions. Use before recommending a package or when auditing dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, e.g. 'express' or '@tanstack/react-query' (npm), 'requests' (PyPI) | |
| version | No | Exact version to check, e.g. '4.17.20'. Omit to list all known vulnerabilities for the package across versions. | |
| registry | No | Package registry to query: 'npm' for JavaScript/TypeScript packages, 'pypi' for Python packages. Defaults to npm. | npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data source (OSV.dev) and the return contents (advisory IDs, CVEs, severity, fixed versions), but omits details like network dependency or potential failure modes. Since no annotations are provided, the description carries the full burden and covers key behavior reasonably well.
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 concise and well-structured: it states the purpose, explains version behavior, lists return fields, and gives usage context—all in three sentences. No unnecessary verbosity.
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?
It provides a clear use case and a summary of return fields, which is helpful given no output schema. However, the contradictory behavior for omitted version undermines the completeness of usage instructions, leaving the agent uncertain about the correct action.
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?
The description directly contradicts the schema for the 'version' parameter: description says omitting it checks the latest release, while schema says omitting it lists all known vulnerabilities across versions. This misleading guidance can cause incorrect usage, despite helpful examples for 'name' and 'registry'.
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 the tool checks a package for known security vulnerabilities via OSV.dev, using the specific verb 'Check' and resource 'package'. It also distinguishes itself from sibling tools by mentioning its use before recommending a package or auditing dependencies.
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?
It explicitly says when to use the tool ('Use before recommending a package or when auditing dependencies') and explains the optional version parameter ('Give a version to check that exact version, or omit it to check the latest release'). This provides clear guidance on invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0bundle_sizecompare_packagesdeprecation_checkpackage_healthvulnerability_checkScored across 5 tools
Tools are mostly distinct, but deprecation_check overlaps with package_health since the latter already includes deprecation status. The other tools—compare_packages, bundle_size, and vulnerability_check—target clearly separate concerns, so an agent can usually pick correctly.
Naming mixes patterns: compare_packages is verb_noun while the rest are noun_noun or adjective_noun (package_health, bundle_size, deprecation_check, vulnerability_check). The convention is readable but not consistently verb-first.
Five tools is well within the ideal range for a focused package-intelligence server. Each tool serves a concrete evaluation need without bloating the surface.
Covers key evaluation aspects: health, security, deprecation, bundle size, and comparison. Minor gaps like raw metadata (description, homepage) or version history are absent, but they are not critical for the server's stated purpose.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.
Real-time Python package and vulnerability data for AI coding agents.
