Enhances rate limits for npm API requests through a GitHub token, improving performance and reliability when performing multiple package lookups.
Provides tools to look up npm package versions and perform security signal analysis, enabling AI assistants to check package up-to-dateness and detect suspicious indicators.
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-booper check latest version of axios"
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.
Boop your dependencies' snoots.
An MCP server that gives AI assistants tools to check up-to-date npm package versions, as well as gleaning other security heuristics. It's not a super comprehensive analysis, just a lil' snoot boop.
pkg-booper is a Model Context Protocol (MCP) server that provides npm package intelligence for AI-assisted development. It fills the gap where documentation tools exist but version/health checking doesn't.
Key features:
Quick version lookups for any npm package
Security signal analysis using transparent indicators
Batch analysis of entire package.json files
Caching for fast repeated lookups
Related MCP server: Dependency Freshness MCP Server
Run directly with npx:
npx pkg-booperOr install globally:
npm install -g pkg-booper
pkg-booperAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"pkg-booper": {
"command": "npx",
"args": ["-y", "pkg-booper"]
}
}
}Add to your Cursor MCP settings (.cursor/mcp.json):
{
"mcpServers": {
"pkg-booper": {
"command": "npx",
"args": ["-y", "pkg-booper"]
}
}
}Add to your Claude Code MCP settings file (.mcp.json):
{
"mcpServers": {
"pkg-booper": {
"command": "npx",
"args": ["-y", "pkg-booper"]
}
}
}Add to your Cline MCP settings:
{
"mcpServers": {
"pkg-booper": {
"command": "npx",
"args": ["-y", "pkg-booper"]
}
}
}Quick version lookup for an npm package.
Input:
{
"package": "lodash",
"skipCache": false
}Output:
{
"success": true,
"package": "lodash",
"latest": "4.17.21",
"tags": {
"latest": "4.17.21"
},
"summary": "lodash@4.17.21"
}Signal-based security analysis of an npm package. Returns information that lets the AI reason about the combination of indicators.
Input:
{
"package": "express",
"version": "4.18.2",
"compareVersions": true,
"skipCache": false
}Output:
{
"success": true,
"package": "express",
"version": "4.18.2",
"facts": {
"age": { "days": 4500, "created": "2010-12-29" },
"lastPublish": { "days": 180, "version": "4.18.2" },
"weeklyDownloads": 30000000,
"maintainerCount": 3,
"versionCount": 275,
"hasTypes": true,
"hasRepository": true
},
"definitiveIndicators": [],
"behavioralSignals": [],
"info": ["Popular package: 30M weekly downloads"],
"summary": "express@4.18.2: No concerning signals detected"
}Signal Categories:
definitiveIndicators: Critical security issues (malware markers, deprecated status)
behavioralSignals: Patterns that warrant investigation (new package, single maintainer, suspicious scripts)
info: Neutral observations (popularity, age, features)
Batch analyze all dependencies from a package.json file.
Input:
{
"path": "/path/to/package.json",
"includeDevDependencies": true,
"skipCache": false
}Output:
{
"success": true,
"packageJsonPath": "/path/to/package.json",
"results": {
"lodash": { "success": true, "package": "lodash", "..." },
"express": { "success": true, "package": "express", "..." }
},
"summary": {
"total": 15,
"clean": 14,
"suspicious": 1,
"outdated": 3,
"definiteThreats": 0,
"failed": 0
},
"humanSummary": "Analyzed 15 packages: 14 clean, 1 suspicious, 0 threats"
}Batch analyze a provided list of dependencies.
Input:
{
"dependencies": {
"lodash": "^4.17.21",
"express": "^4.18.2",
"axios": "^1.6.0"
},
"skipCache": false
}Output: Same format as pkg-booper-big-sniff-file.
Clear cached npm package data.
Input:
{
"package": "lodash",
"type": "all"
}package: Optional. Clear cache for specific package, or omit for all.
type: "all" | "versions" | "health" | "popular"
Output:
{
"success": true,
"cleared": ["lodash:versions", "lodash:health"],
"summary": "Cleared 2 cache entries for lodash"
}pkg-booper can be configured via YAML files, environment variables, or programmatic overrides.
Files are checked in this order (first found wins):
PKG_BOOPER_CONFIG environment variable path
./pkg-booper.yaml (project directory)
~/.config/pkg-booper/config.yaml (user config)
# pkg-booper.yaml
cache:
directory: ~/.cache/pkg-booper
ttl: 86400 # 24 hours in seconds
popularPackagesTtl: 604800 # 7 days for popular packages
thresholds:
levenshtein: 2 # Typosquat detection sensitivity
lowDownloads: 100 # Weekly downloads below this trigger a signal
scoring:
weights:
maturity: 0.15
popularity: 0.25
maintenance: 0.25
trust: 0.25
completeness: 0.10
github:
token: ${GITHUB_TOKEN} # Interpolates from environment
timeout: 10000 # Request timeout in ms
rateLimit:
npm:
requestsPerSecond: 10
github:
requestsPerMinute: 30
debug: falseVariable | Description | Default |
| GitHub API token for enhanced rate limits | - |
| Path to custom config file | - |
| Cache directory |
|
| Cache TTL in seconds |
|
| Request timeout in ms |
|
| Enable debug logging |
|
User: "What's the latest version of React?"
AI uses pkg-booper-boop:
React is currently at version 18.2.0.User: "Analyze the security of this package.json"
AI uses pkg-booper-big-sniff-file:
I analyzed 23 dependencies:
- 21 packages look clean
- 2 packages have behavioral signals worth noting:
- some-package: New package (< 30 days old), single maintainer
- another-pkg: Significantly outdated (2 major versions behind)
No definitive threats detected, but you may want to review the flagged packages.User: "Is 'lod-ash' a legit package?"
AI uses pkg-booper-sniff:
Warning: 'lod-ash' appears to be a typosquat of 'lodash':
- Very similar name (Levenshtein distance: 1)
- Much lower download count than lodash
- Created recently compared to lodash
I'd recommend using the official 'lodash' package instead.This is licensed under the AGPLv3.
Why? I feel like information deserves to be free. Code is a sort of information, and I know the AGPL is pretty good at encouraging sharing. That, and I think of the code I put together with the help of generative AI less like an original composition, and more like a silly mashup.
I don't feel comfortable publishing my mashups under anything less open ;)
Batch analyze all dependencies from a package.json file for security signals
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the package.json file to analyze | |
| skipCache | No | Skip cache and fetch fresh data | |
| includeDevDependencies | No | Include devDependencies in analysis (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the tool is read-only, performs network fetches, respects or bypasses cache by default, requires authentication, or has rate limits; it only restates the high-level analysis purpose.
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 front-loaded sentence with no filler. It immediately communicates the operation, scope, and resource.
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 no annotations and no output schema, the description should do more to explain behavioral context such as caching, return format, or what 'security signals' includes. It leaves key operational details to inference despite the batch-analysis complexity.
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 the schema already documents path, skipCache, and includeDevDependencies. The description adds no parameter-level detail beyond implying a package.json path and dependency analysis, making the baseline of 3 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 states a clear verb-resource pair: batch analyze dependencies from a package.json file for security signals. It distinguishes this file-based tool from its list-based sibling implicitly through 'from a package.json file', but it does not explicitly name or contrast with alternatives like pkg-booper-big-sniff-list.
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?
No when-to-use, when-not-to-use, or alternative-selection guidance is provided. An agent can infer this is for analyzing a package.json file, but must guess how it differs from pkg-booper-sniff, pkg-booper-big-sniff-list, or pkg-booper-clear-cache.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch analyze a provided list of dependencies for security signals
| Name | Required | Description | Default |
|---|---|---|---|
| skipCache | No | Skip cache and fetch fresh data | |
| dependencies | Yes | Map of package names to version specifiers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only says it 'analyzes for security signals.' It does not disclose what signals are returned, whether results are cached, the effect of skipCache, or any auth/rate-limit constraints. For a tool with a cache-skipping parameter, the behavioral picture is thin.
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?
A single front-loaded sentence with no filler; the core action and input are stated immediately. However, the brevity borders on under-specification for a batch analysis tool rather than being optimally informative.
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?
There is no output schema and no annotations, so the description is the only source of return-value and behavior information, and it omits both. An agent cannot tell what a 'security signal' result contains or how batch results are structured.
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 both parameters (dependencies map, skipCache) are documented in the schema itself. The description adds no format details, examples of the dependency map shape, or version-specifier syntax beyond what the schema states, so 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?
The description gives a clear verb ('batch analyze'), resource ('list of dependencies'), and purpose ('security signals'), and the word 'list' implicitly contrasts with the sibling pkg-booper-big-sniff-file. It stops short of explicitly naming or differentiating from siblings like pkg-booper-sniff or pkg-booper-boop.
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?
There is no guidance on when to use this tool versus pkg-booper-sniff (single package?) or pkg-booper-big-sniff-file (file-based input). No prerequisites, no conditions, no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the latest version and dist-tags for an npm package
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | ||
| skipCache | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does not state that results may be cached (implied only by the skipCache parameter), does not mention network/registry calls, rate limits, or behavior for nonexistent or unpublished packages.
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?
A single clean, front-loaded sentence with no filler. It is appropriately terse, though the brevity is partly what leaves the behavioral and parameter gaps unfilled.
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 no annotations, no output schema, 0% schema description coverage, and 2 undocumented parameters, the description is too thin for the tool's complexity. It should at minimum explain the package identifier format and the cache parameter's effect.
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 0% across 2 parameters, so the schema contributes nothing semantic. The description mentions neither the `package` naming/scope format nor what `skipCache` does (cache bypass vs. freshness), leaving both parameters undocumented in prose and schema alike.
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 and resource: 'look up the latest version and dist-tags for an npm package'. An agent knows exactly what it returns. However, it offers no differentiation from the sibling retrieval tools (pkg-booper-sniff, pkg-booper-big-sniff-file, pkg-booper-big-sniff-list), whose names suggest overlapping package-inspection behavior.
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?
No guidance on when to choose this over the sniff siblings, which appear to be alternative package-inspection tools. No prerequisites, no exclusions, no mention of how it relates to pkg-booper-clear-cache despite the skipCache parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear cached npm package data. Optionally filter by package name or cache type (versions, health, popular)
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Cache type to clear: versions, health, popular, or all (default) | |
| package | No | Package name to clear cache for, or omit to clear all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It never states whether a clear is destructive/irreversible, whether omitting both filters wipes the entire cache, whether it requires elevated permissions, or what happens to in-flight consumers of the cache.
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 short sentences with the core action front-loaded and the filtering behavior immediately after. No filler or repetition.
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?
For a simple two-parameter tool with a fully described schema and no output schema, the description covers what an agent needs to invoke it. The only shortfall is the undocumented default (clearing everything when no filters are given), which is left 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?
Schema description coverage is 100%, so both parameters and the enum are already fully documented in the schema; baseline 3 applies. The description restates the enum values but omits the "all" default, adding no meaning 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?
States a specific verb and resource: clear cached npm package data. The sibling tools (boop, sniff, big-sniff-file, big-sniff-list) share the pkg-booper prefix but have no overlapping purpose, so there is nothing to disambiguate against.
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?
"Optionally filter by package name or cache type" implies the tool can be used globally or scoped, but there is no explicit when-to-use guidance, no prerequisites, and no statement about when clearing the whole cache is preferred over a scoped clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze an npm package for security signals, facts, and indicators
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | ||
| version | No | Specific version to analyze (defaults to latest) | |
| skipCache | No | ||
| compareVersions | No | Compare with previous version to detect changes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read/analyze operation, but does not state read-only safety, network or registry access, authentication requirements, caching behavior, rate limits, or what the returned security signals actually contain.
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 front-loaded sentence with no filler or repetition. It is efficient, though for a security-analysis tool it is arguably too terse to be fully appropriately sized.
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 no annotations and no output schema, the description needs to carry more context for a four-parameter security-analysis tool. It omits return content, analysis depth, caching implications, and usage context, leaving the agent with an incomplete behavioral picture.
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 only 50%, and the description adds no parameter meaning at all. The package and skipCache parameters are left undocumented in both the schema and the description, while version and compareVersions are covered only by 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 states a specific verb ('Analyze') and resource ('an npm package') and indicates the output domain ('security signals, facts, and indicators'). It does not distinguish this package-level analysis from sibling tools such as pkg-booper-big-sniff-file or pkg-booper-big-sniff-list.
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?
There is no when-to-use, when-not-to-use, or alternative-tool guidance. Sibling tools imply there are related analysis options, but the description never explains which one to choose or under what conditions.
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.
v0.1.2pkg-booper-big-sniff-filepkg-booper-big-sniff-listpkg-booper-booppkg-booper-clear-cachepkg-booper-sniffScored across 5 tools
boop (version lookup) and sniff (security analysis) are clearly distinct, and clear-cache is unambiguous. The only overlap is big-sniff-file vs big-sniff-list, which differ solely by input source (package.json vs provided list), though the descriptions do clarify the boundary.
All tools use the same kebab-case, pkg-booper- prefixed pattern, which is highly consistent. However the actionable verbs are playful and non-self-documenting (boop, sniff, big-sniff), so the scheme is predictable but not transparently descriptive.
Five tools are well-scoped for an npm lookup-and-security-inspection server, with no filler. Each tool maps to a distinct capability (version lookup, single analysis, two batch modes, cache management).
The surface covers version lookup, single/batch security analysis, and cache control, forming a coherent lifecycle. Minor gaps exist around per-package detail (license, maintainers, diff/compare) that agents might want but can work around.
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
Verify npm packages before your AI agent installs them: hallucinations, advisories, API drift.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.