What can you do with this server?

The NPM Sentinel MCP server provides AI-powered analysis and insights for NPM packages to optimize and secure package management: * Version Analysis: Track package versions and get the latest version information * Dependency Analysis: Map and analyze package dependencies and devDependencies * Security Scanning: Identify known vulnerabilities in packages * Quality Metrics: Assess package quality, maintenance status, and popularity * Download Trends: View download statistics and popularity metrics * TypeScript Support: Verify TypeScript compatibility and type availability * Package Size: Analyze bundle size, dependencies, and import costs * Real-time Comparisons: Compare multiple packages based on various metrics * Maintainer Insights: Retrieve maintainer information and activity * License Compliance: Check license compatibility between packages * Repository Stats: Get repository metrics for packages * Deprecation Check: Identify deprecated packages and find alternatives * Changelog Analysis: Summarize and analyze changelogs and release history * Package Search: Search for NPM packages with customizable options * README Access: Retrieve README content for packages * Documentation: Access the server's own documentation and specifications

Which integrations are available for this server?

Provides repository statistics and metrics for NPM packages hosted on GitHub Offers comprehensive NPM package analysis including version tracking, dependency mapping, security scanning, and quality metrics Verifies TypeScript support and compatibility for NPM packages

How do I use NPM Sentinel MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NPM Sentinel MCP scan react for security vulnerabilities" 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.

de en es ja ko ru zh

NPM Sentinel MCP

by Nekzus

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

NPM Sentinel MCP

Github Workflow npm version npm-month npm-total Docker Hub Ask DeepWiki Donate

A powerful Model Context Protocol (MCP v2) server built on @modelcontextprotocol/server and @modelcontextprotocol/core (v2) that revolutionizes NPM package analysis through AI. Built to integrate seamlessly with Claude, Anthropic AI, and any MCP v2 compatible client, it provides real-time intelligence on package security, dependencies, and performance.

This server features Modular ESM Architecture (src/), Dual Output Protocol Returns (content + structuredContent), Zod Output Schemas (outputSchema), Embedded SVG Data URI Icons, and Real-Time Context Logging.

Key Features

MCP v2 Native Protocol: Fully upgraded to MCP v2 with outputSchema Zod validation, dual structuredContent returning, and diagnostic context logging (ctx.mcpReq.log).
Self-Contained Vector Icons: Pre-configured SVG Data URIs (data:image/svg+xml) embedded across all 19 tools, resources, and prompts for enhanced client UI presentation.
Advanced Security Scanning: Recursive dependency checks powered by Google's deps.dev and OSV.dev, ecosystem awareness, and accurate version resolution.
Smart Alternatives Filtering (npmAlternatives): Intelligent search based on functional domain keywords with strict ecosystem plugin/extension filtering (e.g., excludes express-rate-limit when searching for alternatives to express).
Strict Input Validation & Batch Rate Control: Input sanitization via Zod against Path Traversal, SSRF, and Command Injection. Search queries (npmSearch) are capped at 100 characters and filtered for control characters. Batch analysis tools enforce a strict cap of 25 packages per request to prevent registry enumeration DoS.
Dependency & Transitive Mapping: Complete dependency tree analysis mapping through deps.dev.
Package Quality & Maintenance Metrics: Real-time scoring using OpenSSF Scorecard, GitHub repository metrics, and npms.io.
Download Trends & Performance: Real-time download statistics and bundle size analysis.
Smart SemVer Shorthand & Range Resolution: Transparently resolves major version shorthands, prefixes, and ranges (e.g., express@2, express@v4, zod@3.x, react@^18, lodash@~4.17) to the highest matching release without failing on missing exact version keys.
Indirect Prompt Injection Defense (OWASP LLM01): All tools returning raw 3rd-party Markdown/text (npmPackageReadme, npmChangelogAnalysis) wrap untrusted content in <untrusted_external_content> tags, attach _meta.untrustedExternalContent = true flags, and enforce strict tool schema warnings.
Efficient Caching System: Automated cache invalidation on workspace lockfile changes (pnpm-lock.yaml, package-lock.json, yarn.lock) with manual bypass (ignoreCache: true).

Related MCP server: NPM Helper MCP

Security & OWASP LLM01 Compliance

This server implements Defense-in-Depth controls aligned with OWASP LLM01:2025 (Indirect Prompt Injection):

XML Data Demarcation: Content from external packages (README.md, GitHub changelogs, release notes) is wrapped inside <untrusted_external_content source="..." package="..." type="..."> tags so consuming LLM models distinguish untrusted data from instructions.
Metadata Signaling (_meta): Responses include _meta.untrustedExternalContent = true and _meta.sources arrays for programmatic client-side detection and policy enforcement.
Tool & Prompt Safety Warnings: Tool descriptions and prompt definitions explicitly instruct LLM agents to treat documentation as passive data and ignore embedded execution commands.
Batch Size Capping & Query Sanitization: All 18 multi-package analysis tools enforce a 25-package limit per request (PackageListSchema). Search queries are sanitized and capped at 100 characters (SearchQuerySchema).
Prototype Pollution Protection: Enforces Object.hasOwn() checks on dictionary lookups (blocking reserved properties like constructor and __proto__).

To ensure data accuracy while maintaining high performance:

Automatic Invalidation: The cache is automatically invalidated whenever pnpm-lock.yaml, package-lock.json, or yarn.lock changes in your workspace.
Force Refresh: All tools accept an optional ignoreCache: true parameter to bypass the cache and force a fresh lookup from the NPM registry.

Example Usage (JSON-RPC)

{
  "name": "npmVersions",
  "arguments": {
    "packages": ["react"],
    "ignoreCache": true
  }
}

Installation & Transports

Dual-Era MCP Architecture (v1 `2025-11-25` + v2 `2026-07-28`)

This MCP server features native Dual-Era Protocol Compatibility, seamlessly serving both modern MCP v2 clients (2026-07-28) and legacy MCP v1 clients (2025-11-25) out of the box across both STDIO and Streamable HTTP transports:

STDIO Mode (npx @nekzus/mcp-server): Powered by serveStdio({ legacy: "serve" }). Handles modern server/discover probes sessionlessly and conjoins seamlessly with legacy initialize handshakes for local execution (Claude Desktop, Cursor, Docker).
Streamable HTTP / SSE Mode (@nekzus/mcp-server/http): Powered by createMcpHandler({ legacy: "stateless" }). Designed for serverless and web-standard runtimes (Cloudflare Workers, Hono, Express, Vercel API Routes, Smithery.ai).

Example: Mounting HTTP Handler (Cloudflare Workers / Hono / Express)

import { createMcpHttpHandler } from '@nekzus/mcp-server/http';

const handleRequest = createMcpHttpHandler();

export default {
  async fetch(request, env, ctx) {
    return handleRequest(request);
  }
};

Development Commands:

# Install dependencies
pnpm install

# Compile TypeScript to dist/
pnpm run build

# Start STDIO server (Dual-Era)
pnpm run start

# Development server with Smithery CLI playground
pnpm run dev

# Run full unit and integration test suite (238 tests)
pnpm test -- --run

# Run full E2E tarball verification
node __tests__/full-e2e-pack-validation.js

Install in VS Code / Cursor

Add this to your VS Code / Cursor MCP configuration:

{
  "inputs": [],
  "servers": {
    "npm-sentinel": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@nekzus/mcp-server@latest"]
    }
  }
}

Install in Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "npm-sentinel": {
      "command": "npx",
      "args": ["-y", "@nekzus/mcp-server@latest"]
    }
  }
}

Configuration File Locations:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Smithery.ai Deployment

{
  "mcpServers": {
    "npm-sentinel": {
      "type": "http",
      "url": "https://smithery.ai/server/@Nekzus/npm-sentinel-mcp"
    }
  }
}

Docker Usage

# Build Docker image
docker build -t nekzus/npm-sentinel-mcp .

# Run with local volume mount
docker run -i --rm -w /projects -v ${PWD}:/projects nekzus/npm-sentinel-mcp node dist/index.js

Web Standard Streamable HTTP & Cloudflare Workers Integration

The package exports createMcpHttpHandler and WebStandardStreamableHTTPServerTransport for serverless platforms (Cloudflare Workers, Hono, Vercel, Express, Fastify, Next.js API routes) requiring official Web Standard Streamable HTTP transport under MCP v2:

import { createMcpHttpHandler } from '@nekzus/mcp-server/http';

const handleMcpRequest = createMcpHttpHandler();

export default {
  async fetch(request: Request): Promise<Response> {
    return handleMcpRequest(request);
  },
};

100% MCP v2 Compliance: Powered by WebStandardStreamableHTTPServerTransport, this handler natively activates all 3 MCP primitives (Tools, Resources, and Prompts) with peak performance, SSE streaming support, and full Web Standard Request $\rightarrow$ Response compatibility.

Configuration

The server supports the following configuration parameters:

Environment Variable	Config Object Property	Default	Description
`NPM_REGISTRY_URL`	`config.NPM_REGISTRY_URL`	`https://registry.npmjs.org`	URL of the NPM registry to use for all requests

MCP Server Capabilities (v2 API)

All tool responses conform to the MCP v2 dual output format, providing both human-readable text in content and parsed JSON objects in structuredContent:

{
  "content": [
    {
      "type": "text",
      "text": "{\n  \"queryPackages\": [\"express\"],\n  \"results\": [...]\n}"
    }
  ],
  "structuredContent": {
    "queryPackages": ["express"],
    "results": [...]
  }
}

Server Resources

Accessible via MCP readResource requests:

doc://server/readme
- Description: Main documentation file for NPM Sentinel MCP server.
- MIME Type: text/markdown
- Icon: Embedded Document SVG Data URI.
doc://mcp/specification
- Description: Complete Model Context Protocol specification file (llms-full.txt).
- MIME Type: text/plain
- Icon: Embedded Document SVG Data URI.

Server Prompts

Accessible via MCP getPrompt requests:

analyze-package
- Description: Generates a comprehensive prompt template for AI analysis of an NPM package including security, performance, dependencies, and health metrics.
- Arguments: package (string, required)
- Icon: Embedded Security SVG Data URI.

Tools Catalog (19 Tools)

All 19 tools define inputSchema, outputSchema, annotations (title, readOnlyHint), and icons:

1. `npmLatest`

Get latest version information, release dates, SRI integrity hashes, and dist-tags.
Input: packages (string[]), ignoreCache (boolean, optional)

2. `npmVersions`

Get full version history with release dates and deprecation statuses.
Input: packages (string[]), ignoreCache (boolean, optional)

3. `npmDeps`

Complete dependency tree analysis including direct dependencies and full transitive graph mapping via deps.dev.
Input: packages (string[]), ignoreCache (boolean, optional)

4. `npmTypes`

Verify TypeScript support (native index.d.ts declaration files vs @types/* DefinitelyTyped packages).
Input: packages (string[]), ignoreCache (boolean, optional)

5. `npmSize`

Package bundle size, minified size, and gzip impact analysis.
Input: packages (string[]), ignoreCache (boolean, optional)

6. `npmVulnerabilities`

Instant transitive vulnerability scanning powered by Google's deps.dev and OSV.dev advisories.
Input: packages (string[]), ignoreCache (boolean, optional)

7. `npmTrends`

Historical download statistics over customizable time ranges (last-week, last-month, last-year).
Input: packages (string[]), period ("last-week" | "last-month" | "last-year"), ignoreCache (boolean, optional)

8. `npmCompare`

Side-by-side metric comparison across multiple packages.
Input: packages (string[]), ignoreCache (boolean, optional)

9. `npmMaintainers`

List of package maintainers, public emails, and publishing activity.
Input: packages (string[]), ignoreCache (boolean, optional)

10. `npmScore`

Consolidated score combining quality, popularity, maintenance, and OpenSSF Scorecard.
Input: packages (string[]), ignoreCache (boolean, optional)

11. `npmPackageReadme`

Retrieve full formatted raw README markdown content from NPM registry / CDN.
Input: packages (string[]), ignoreCache (boolean, optional)

12. `npmSearch`

Search NPM registry packages by query with rich metadata (scores, publisher, keywords).
Input: query (string), limit (number, optional)

13. `npmLicenseCompatibility`

Analyze license compatibility across multiple packages (MIT, Apache-2.0, GPL, etc.).
Input: packages (string[]), ignoreCache (boolean, optional)

14. `npmRepoStats`

Repository statistics (GitHub stars, forks, open issues) combined with OpenSSF Scorecard checks.
Input: packages (string[]), ignoreCache (boolean, optional)

15. `npmDeprecated`

Detect deprecation status on package and recursive sub-dependencies.
Input: packages (string[]), ignoreCache (boolean, optional)

16. `npmChangelogAnalysis`

Extract release notes and GitHub release history.
Input: packages (string[]), ignoreCache (boolean, optional)

17. `npmAlternatives`

Smart functional alternative suggestions filtering out ecosystem plugins (e.g. excludes express-rate-limit for express).
Input: packages (string[]), ignoreCache (boolean, optional)

18. `npmQuality`

Package code quality score (0–1).
Input: packages (string[]), ignoreCache (boolean, optional)

19. `npmMaintenance`

Package maintenance activity score (0–1).
Input: packages (string[]), ignoreCache (boolean, optional)

License

This MCP server is licensed under the MIT License. See LICENSE for details.

MIT © nekzus

Available Tools

19 tools

npmAlternativesB

Read-only

Inspect

Find alternative packages with similar functionality

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to find alternatives for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true (safe read operation) and openWorldHint=true (potential for external lookups). The description does not add behavioral context beyond the schema parameter 'ignoreCache', which hints at caching but is not elaborated. No contradiction with annotations. The description is adequate but adds little extra transparency.

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

Conciseness4/5

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

One sentence, no wasted words. It is front-loaded with the core purpose. However, it might be too terse; a bit more detail could improve clarity without sacrificing conciseness. Still, it earns its place.

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

Completeness2/5

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

Given an output schema exists, the description does not need to detail return values, but it should at least mention that it returns alternative packages. The current description is vague ('similar functionality'). For a tool with two parameters and no nested objects, more context about the output or success criteria would be helpful.

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 schema itself documents both parameters (packages list and ignoreCache boolean). The description adds no additional meaning or usage tips for these parameters. Thus, baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the verb 'Find' and the resource 'alternative packages with similar functionality'. It distinguishes from sibling tools like npmVersions or npmLatest, which focus on different aspects. However, it could be more specific about the scope (e.g., NPM packages) and what 'similar functionality' entails.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like npmCompare or npmSearch. There is no mention of prerequisites, limitations, or when not to use it. The description solely states what it does, leaving the agent to infer usage context.

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

npmChangelogAnalysisC

Read-onlyIdempotent

Inspect

Analyze changelog and release history of packages

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to analyze changelogs for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

C2.9/5.0

Behavior2/5

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds no behavioral context. It doesn't mention that it fetches from GitHub, caching behavior (though ignoreCache param exists), or any rate limits. The description should expand on what 'analyze' entails.

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

Conciseness4/5

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

The description is a single concise sentence that gets the point across without fluff. It is appropriately front-loaded, though it could be slightly more structured with a brief note on usage.

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

Completeness3/5

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

Given the presence of a complete input and output schema, plus annotations, the description is minimally adequate. However, it misses context about the data source (GitHub) and the nature of the analysis, which would help an agent understand what to expect.

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 schema already documents both parameters. The description does not add additional meaning, but the baseline of 3 is appropriate as it does not repeat or contradict the schema.

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

Purpose4/5

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

The description clearly states the verb 'Analyze' and the resource 'changelog and release history of packages', effectively distinguishing it from siblings like npmVersions or npmLatest. However, it could be more specific about the source (GitHub) and output.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention that npmLatest is for single version queries or that this tool is for historical analysis.

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

npmCompareB

Read-onlyIdempotent

Inspect

Compare multiple NPM packages based on various metrics

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to compare
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`queryPackages`	No

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds minimal behavioral context beyond 'compare', which is adequate given the annotations.

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?

Single sentence with no wasted words. Highly concise and front-loaded, stating the core purpose immediately.

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

Completeness3/5

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

While the tool is simple and has an output schema, the description lacks detail on what exactly is compared (e.g., version, size, vulnerabilities). Given low complexity and presence of output schema, it is minimally complete but could be more informative.

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% for both parameters (packages and ignoreCache). The description does not add additional meaning beyond the schema, so baseline score of 3 applies.

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

Purpose4/5

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

The description clearly states the tool compares multiple NPM packages, which is a specific verb+resource. It distinguishes from sibling tools like npmSize or npmVersions that focus on single metrics, but 'various metrics' is somewhat vague.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. The description implies use for comparison but provides no scenarios or exclusions, leaving the agent to infer usage.

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

npmDeprecatedC

Read-onlyIdempotent

Inspect

Check if packages are deprecated

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to check for deprecation
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds no behavioral context beyond that. It does not explain caching behavior, network dependency, or any side effects, missing an opportunity to add value.

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

Conciseness4/5

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

The description is a single concise sentence that captures the core purpose without waste. Could include more context, but it is not overly terse.

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

Completeness3/5

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

Given the presence of an output schema and annotations, the description is adequate but minimal. It doesn't mention what the return value looks like or how results are structured, which would help with tool selection.

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?

Input schema covers 100% of parameters with descriptions, so the description does not need to compensate. However, it adds nothing beyond the schema, so score is at baseline 3.

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

Purpose4/5

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

The description 'Check if packages are deprecated' clearly states the action (check) and the resource (npm packages' deprecation status). It distinguishes from sibling tools like npmVersions and npmLatest, which focus on different attributes.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus the many sibling tools. There is no mention of prerequisites, context, or alternative tools, leaving the agent to infer usage.

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

npmDepsA

Read-onlyIdempotent

Inspect

Analyze dependencies and devDependencies of an NPM package

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to analyze dependencies for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it analyzes both dependencies and devDependencies, but does not disclose additional behavioral traits like caching behavior or data freshness. It does not contradict annotations.

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 a single sentence that is front-loaded with the action and resource. Every word is necessary, and there is no extraneous information.

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

Completeness4/5

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

Given the presence of a complete output schema, full parameter descriptions, and annotations, the tool definition is mostly complete. The description could mention that it returns a list of dependencies, but it is not essential due to the output schema.

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 coverage is 100% with descriptions for both 'packages' and 'ignoreCache'. The description does not add any meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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 tool name 'npmDeps' and description 'Analyze dependencies and devDependencies of an NPM package' clearly specify the action and resource. It distinguishes itself from sibling tools like npmVersions or npmLatest, which have different purposes.

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

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The context of sibling tools implies its unique purpose, but the description itself lacks usage instructions.

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

npmLatestB

Read-onlyIdempotent

Inspect

Get the latest version and changelog of an NPM package

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to get latest versions for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so description's burden is lower. It adds the return type (version and changelog) but doesn't elaborate on caching behavior or other traits beyond the schema's ignoreCache parameter.

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

Conciseness4/5

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

Single sentence, no fluff, front-loaded with key information. Could be slightly more structured but remains highly concise and readable.

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

Completeness3/5

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

Output schema exists so return values need not be detailed. However, with many sibling tools, a brief note on batch capability (up to 25 packages) would improve completeness. Still, given low complexity, it's minimally adequate.

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 coverage is 100% with both parameters documented in the schema. Description does not add any extra meaning or usage hints for the parameters beyond what the JSON schema provides.

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?

Description clearly states it gets the latest version and changelog of an NPM package, using specific verb and resource. This distinguishes it from siblings like npmVersions (which likely returns all versions) and npmChangelogAnalysis (analysis-focused).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like npmVersions or npmChangelogAnalysis. It doesn't mention limitations, prerequisites, or when to avoid using it.

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

npmLicenseCompatibilityB

Read-onlyIdempotent

Inspect

Check license compatibility between multiple packages

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to check for license compatibility
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`compatibility`	No
`licenseDetails`	No
`packagesAnalyzed`	No

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint=true. The description adds no behavioral insight beyond the purpose, such as whether it returns a simple pass/fail or detailed conflicts. With annotations present, the description could still add value (e.g., 'returns license issues'), but it does not.

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

Conciseness4/5

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

The description is a single sentence with no wasted words, but it is not significantly front-loaded with critical context. It is efficient but could be slightly more informative.

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

Completeness3/5

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

Given the tool's low complexity (2 parameters, one simple array) and the presence of an output schema (likely detailing return values), the description provides minimal but sufficient context. However, it lacks a hint about the output format, which the output schema may cover.

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 coverage is 100% with descriptive names and descriptions for both parameters. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 'Check license compatibility between multiple packages' clearly states the action (check), the resource (license compatibility), and the scope (multiple packages). It effectively distinguishes from sibling tools like npmVersions or npmVulnerabilities.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools cover different aspects, but the description does not mention scenarios or exclusions, leaving the agent without context for tool selection.

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

npmMaintainersB

Read-onlyIdempotent

Inspect

Get maintainers information for NPM packages

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to get maintainers for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

B3.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description only says 'Get maintainers information' and adds no additional behavioral context (e.g., cache behavior, error handling, or rate limits). With annotations present, the description should go beyond structured data but fails to do so.

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 a single sentence that states the core purpose without any fluff. It is appropriately concise and front-loaded.

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

Completeness4/5

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

Given the presence of an output schema and annotations, the description is largely adequate for a simple read-only tool. However, it lacks any mention of what the returned maintainers information includes, which might be useful for quick understanding without inspecting the output schema.

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 coverage is 100%, so both parameters (packages and ignoreCache) are fully described in the schema. The description adds no extra meaning beyond what's in the schema, resulting in baseline score of 3.

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 'Get maintainers information for NPM packages' clearly states the verb (Get) and resource (maintainers information for NPM packages). It is specific and distinguishes from sibling tools like npmVersions, npmLatest, etc., which focus on different aspects of NPM packages.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like npmQuality, npmMaintenance, or other sibling tools. There is no mention of prerequisites, exclusions, or context for usage.

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

npmMaintenanceB

Read-onlyIdempotent

Inspect

Analyze package maintenance metrics

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to analyze
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety and idempotency profile effectively. The description adds no further behavioral context (e.g., data freshness, rate limits, or scope of metrics), but it does not contradict the annotations.

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

Conciseness4/5

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

The description is a single, short sentence that conveys the tool's purpose without unnecessary words. While it is very concise, the brevity is acceptable given the annotations and output schema, but a slightly more descriptive phrase would improve clarity.

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

Completeness2/5

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

Given 18 sibling tools and likely complexity in npm analytics, the description is too minimal. It does not explain what 'maintenance metrics' entails, how results are presented (though output schema exists), or how it differs from closely related tools like npmScore or npmQuality. The annotations and output schema partially compensate, but the agent lacks essential decision-making info.

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 coverage is 100%, with both parameters (packages, ignoreCache) fully described in the schema. The description adds no extra meaning or usage context for these parameters, so it meets the baseline without adding value.

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

Purpose4/5

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

The description clearly states the verb 'analyze' and resource 'package maintenance metrics', making the core purpose immediately understandable. However, among 18 sibling tools covering npm quality, score, maintainers, etc., the description does not differentiate what unique metrics 'maintenance' covers, which slightly limits precision.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like npmScore, npmQuality, or npmMaintainers. The description offers no context about appropriate use cases or exclusions, leaving the agent to infer from the name alone.

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

npmPackageReadmeB

Read-onlyIdempotent

Inspect

Get the README content for NPM packages

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to get READMEs for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, so the bar is lowered. However, the description adds no additional behavioral context (e.g., caching behavior, multiple packages) beyond the schema.

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?

A single sentence that is concise and front-loaded. No wasted words.

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

Completeness2/5

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

Despite having an output schema and annotations, the description is too minimal. It does not mention key aspects like caching or multi-package retrieval, which are important for a tool with 18 siblings and a parameter indicating cache control.

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% with both parameters documented. The description adds no extra meaning to parameters, so baseline 3 is appropriate.

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 title 'Get NPM Package README' and description clearly state the action (get) and resource (NPM package README). It is specific and distinguishes from sibling tools like npmVersions and npmLatest.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. The description does not mention scenarios or when not to use it, leaving the agent without context for selection.

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

npmQualityC

Read-onlyIdempotent

Inspect

Analyze package quality metrics

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to analyze
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

C2.5/5.0

Behavior2/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds no extra behavioral context such as caching behavior, rate limits, or return value structure.

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

Conciseness3/5

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

Description is a single short sentence, making it concise but lacking structure. It does not front-load key details or earn its place fully.

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

Completeness2/5

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

Despite having an output schema and full schema coverage, the description does not explain what metrics are analyzed, how caching works, or how to interpret results. Incomplete for the tool's complexity.

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 coverage is 100%; both parameters are documented in the schema. Description adds no further meaning beyond the schema, meeting the baseline.

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

Purpose3/5

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

Description states 'Analyze package quality metrics' which is clear but vague. It does not specify which quality metrics are analyzed or distinguish from sibling tools like npmScore or npmMaintenance.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. No when-not-to-use or prerequisites mentioned.

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

npmRepoStatsB

Read-onlyIdempotent

Inspect

Get repository statistics for NPM packages

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to get repository stats for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the agent knows it's a safe, idempotent read operation. The description adds no behavioral context (e.g., caching behavior via ignoreCache, data freshness, rate limits). It meets the baseline but adds minimal value beyond annotations.

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

Conciseness4/5

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

The description is a single concise sentence that directly states the tool's purpose. It avoids fluff and is front-loaded. Slightly more detail would not harm conciseness, but it is already efficient.

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

Completeness3/5

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

The description is minimal but paired with a comprehensive input schema (100% coverage) and an output schema (as per context). The term 'repository statistics' is vague without the output schema, but the presence of the output schema fills the gap. Overall, it is adequate but relies heavily on structured fields.

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 coverage is 100% with clear descriptions for both parameters: 'packages' and 'ignoreCache'. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

Purpose4/5

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

The description 'Get repository statistics for NPM packages' clearly states the verb (Get) and resource (repository statistics). It distinguishes from siblings like npmVersions, npmLatest, and npmDeps, which focus on different aspects. However, it could be slightly more specific by mentioning that stats are from GitHub, as indicated in the annotations title.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With 18 sibling tools covering various npm queries, the description should hint at scenarios (e.g., when you need star counts, fork info, etc.) to help select this tool.

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

npmScoreA

Read-onlyIdempotent

Inspect

Get consolidated package score based on quality, maintenance, and popularity metrics

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to get scores for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds that the score is based on three metrics, but doesn't disclose caching behavior or rate limits. It does not contradict annotations.

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 a single, front-loaded sentence that conveys the core purpose efficiently. There is no redundant or extraneous information.

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

Completeness4/5

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

Given the simple read-only nature of the tool with annotations and a likely output schema, the description is sufficient. It could be slightly more complete by mentioning the output format, but the output schema presumably handles that.

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 coverage is 100% and both parameters are well-described in the schema. The description adds no additional meaning beyond what the schema already provides (e.g., 'packages' list and 'ignoreCache' flag). Baseline score of 3 applies.

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 clearly states it retrieves a consolidated package score based on quality, maintenance, and popularity metrics. It uses a specific verb 'get' and resource 'consolidated package score', distinguishing it from sibling tools like npmQuality and npmMaintenance.

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

Usage Guidelines3/5

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

The description implies when to use (for a quick overall score), but does not explicitly differentiate from alternatives like npmQuality or npmMaintenance for more granular analysis. No when-not-to-use guidance is provided.

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

npmSearchA

Read-only

Inspect

Search for NPM packages with optional limit

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results to return (default: 10)
`query`	Yes	Search query for packages
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	No
`message`	No
`results`	No
`limitUsed`	No
`resultsCount`	No
`totalResults`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and openWorldHint. The description adds context about the optional limit and implicitly caching via ignoreCache parameter, but does not elaborate on caching effects or data freshness beyond schema.

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?

Extremely concise single sentence, front-loaded with key information. No wasted words.

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

Completeness4/5

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

For a simple search tool with output schema, the description is almost complete. It might benefit from a brief note on search behavior (e.g., exact vs fuzzy), but not essential.

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?

With 100% schema coverage, each parameter has a description. The description only redundantly mentions 'optional limit' without adding new meaning beyond the schema.

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 clearly states the verb 'Search' and resource 'NPM packages' with the optional limit parameter. It distinguishes itself from sibling tools like npmVersions or npmLatest which target specific aspects.

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

Usage Guidelines3/5

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

The description does not explicitly advise when to use this tool versus siblings. It states the core function but lacks guidance on alternatives or when not to use it.

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

npmSizeA

Read-onlyIdempotent

Inspect

Get package size information including dependencies and bundle size

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to get size information for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

A3.8/5.0

Behavior4/5

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

The description adds value beyond annotations by specifying that size information includes dependencies and bundle size. It is consistent with the readOnlyHint and idempotentHint annotations, providing useful behavioral context without contradiction.

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 a single, efficient sentence that conveys the core purpose without unnecessary words. It is front-loaded and earns its place.

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

Completeness4/5

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

For a tool with a simple 2-parameter schema and an output schema available, the description is sufficient. It explains the main function. Minor omission: it does not mention the underlying service (Bundlephobia) which is only in annotations.

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?

Full schema coverage (100%) means the input schema already describes both parameters. The description does not add additional parameter-level details, so a baseline score of 3 is appropriate.

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 clearly states the tool's function: 'Get package size information including dependencies and bundle size.' It specifies the resource and scope, and is distinct from sibling tools like npmVersions or npmDeps.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description lacks context for appropriate usage or exclusions, leaving the agent to infer from the tool name and siblings alone.

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

npmTrendsA

Read-onlyIdempotent

Inspect

Get download trends and popularity metrics for packages

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Time period for trends. Options: "last-week", "last-month", "last-year"	last-month
`packages`	Yes	List of package names to get trends for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds no additional behavioral context (e.g., caching, data freshness). No contradiction with annotations.

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 a single, efficient sentence that is front-loaded with the core purpose. No unnecessary words.

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

Completeness3/5

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

Given the presence of an output schema and rich annotations, the description is minimally complete. It covers the basic what but could be more specific about the format of trends.

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?

The input schema provides full descriptions for all 3 parameters, so the description does not need to add much. Baseline 3 is appropriate as the description adds no extra semantics beyond the schema.

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 clearly states the tool retrieves download trends and popularity metrics for packages. It uses a specific verb and resource, and is distinct from sibling tools like npmVersions or npmSize.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It does not mention when not to use it or point to sibling tools for other use cases.

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

npmTypesA

Read-onlyIdempotent

Inspect

Check TypeScript types availability and version for a package

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to check types for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds minimal behavioral context; it doesn't mention caching behavior or the ability to check multiple packages (despite schema allowing array). No contradiction with annotations.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no wasted words. It is concise but could be slightly improved by clarifying plural packages.

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

Completeness3/5

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

Given the existence of an output schema, the description does not need to explain return values. However, it lacks contextual hints such as typical use cases or edge cases, making it adequate but not rich.

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 schema already documents both parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline score of 3.

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 clearly states the verb 'Check' and the resource 'TypeScript types availability and version for a package'. It distinguishes this tool from siblings like npmVersions and npmLatest by focusing specifically on type availability, not general version info.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives. Given the sibling tools, the name suggests its purpose, but no when-not-to-use or alternative guidance is provided.

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

npmVersionsA

Read-onlyIdempotent

Inspect

Get all available versions of an NPM package

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to get versions for
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description does not add behavioral details beyond these, but it does not contradict them. A score of 3 is appropriate as the description adds no additional behavioral context.

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?

Single, well-structured sentence that front-loads the key action and resource. Every word is essential; no fluff or redundancy.

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

Completeness4/5

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

Given the presence of an output schema and annotations covering safety and idempotency, the description is largely complete. It clearly states the tool's purpose and parameter usage, though it could briefly mention that versions are fetched from the npm registry. The high schema coverage compensates for the lack of explicit return value explanation.

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?

Input schema covers both parameters with descriptions (100% coverage). The description adds no extra meaning beyond what the schema already provides. Baseline 3 is correct.

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?

Description uses specific verb 'Get' and resource 'all available versions of an NPM package', clearly distinguishing it from sibling tools like npmLatest (single version) or npmDeps (dependencies). The statement directly conveys the tool's function without ambiguity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios where npmLatest or other sibling tools would be more appropriate, nor are there any prerequisites or preferences stated.

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

npmVulnerabilitiesC

Read-only

Inspect

Check for known vulnerabilities in packages

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to check for vulnerabilities
`ignoreCache`	No	Force a fresh lookup, ignoring the cache

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	No
`summary`	No

TDQS

C2.9/5.0

Behavior2/5

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

The description adds no behavioral details beyond what annotations provide (readOnlyHint, openWorldHint). Annotations already indicate it's a read-only, open-world operation, so the description's contribution is minimal.

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

Conciseness4/5

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

Single sentence, no wasted words. Could be slightly expanded to include more context without losing conciseness.

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

Completeness2/5

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

Missing important context such as the vulnerability source, scope (e.g., known vulnerabilities from npm advisories), or any limitations. With output schema present, return values are covered, but the description still feels incomplete for a security-checking tool.

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%, fully describing both parameters. The description does not add extra meaning for parameters, so baseline of 3 is appropriate.

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

Purpose4/5

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

The description 'Check for known vulnerabilities in packages' clearly states the action and resource. It distinguishes from sibling tools like npmVersions or npmLatest by focusing on security vulnerabilities. However, it could be more precise by mentioning the vulnerability database (e.g., OSV.dev from the annotation title).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus other npm tools. For example, when to prefer this over npmScore or npmQuality is not indicated. Lacks exclusions or alternative suggestions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

19 tool updatesv1.24.0Jul 28, 2026

AddednpmAlternatives
AddednpmChangelogAnalysis
AddednpmCompare
AddednpmDeprecated
AddednpmDeps
AddednpmLatest
AddednpmLicenseCompatibility
AddednpmMaintainers
AddednpmMaintenance
AddednpmPackageReadme
AddednpmQuality
AddednpmRepoStats
AddednpmScore
AddednpmSearch
AddednpmSize
AddednpmTrends

ChangednpmTypes2 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": {},
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "additionalProperties": {},
+          "propertyNames": {
+            "type": "string"
+          },
+          "type": "object"
+        }
+      ]
+    }
+  },
+  "type": "object"
+}

ChangednpmVersions2 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": {},
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "additionalProperties": {},
+          "propertyNames": {
+            "type": "string"
+          },
+          "type": "object"
+        }
+      ]
+    }
+  },
+  "type": "object"
+}

AddednpmVulnerabilities

19 tool updatesv1.23.0Jul 25, 2026
- RemovednpmAlternatives
- RemovednpmChangelogAnalysis
- RemovednpmCompare
- RemovednpmDeprecated
- RemovednpmDeps
- RemovednpmLatest
- RemovednpmLicenseCompatibility
- RemovednpmMaintainers
- RemovednpmMaintenance
- RemovednpmPackageReadme
- RemovednpmQuality
- RemovednpmRepoStats
- RemovednpmScore
- RemovednpmSearch
- RemovednpmSize
- RemovednpmTrends
- ChangednpmTypes2 fields changed
  - addedInput schema / properties / packages / maxItems
```
Added value: +25
```
  - addedInput schema / properties / packages / minItems
```
Added value: +1
```
- ChangednpmVersions2 fields changed
  - addedInput schema / properties / packages / maxItems
```
Added value: +25
```
  - addedInput schema / properties / packages / minItems
```
Added value: +1
```
- RemovednpmVulnerabilities

19 tool updatesv1.20.0Jul 13, 2026

ChangednpmAlternatives2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmChangelogAnalysis2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmCompare2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmDeprecated2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmDeps2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmLatest2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmLicenseCompatibility2 fields changed
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / ignoreCache
```
Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}
```

ChangednpmMaintainers2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmMaintenance2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmPackageReadme2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmQuality2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmRepoStats2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmScore2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmSearch2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmSize2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmTrends2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmTypes2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmVersions2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

ChangednpmVulnerabilities2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / ignoreCache

Added value: +{
+  "description": "Force a fresh lookup, ignoring the cache",
+  "type": "boolean"
+}

19 tool updatesv1.0.0Aug 14, 2025
- First observednpmAlternatives
- First observednpmChangelogAnalysis
- First observednpmCompare
- First observednpmDeprecated
- First observednpmDeps
- First observednpmLatest
- First observednpmLicenseCompatibility
- First observednpmMaintainers
- First observednpmMaintenance
- First observednpmPackageReadme
- First observednpmQuality
- First observednpmRepoStats
- First observednpmScore
- First observednpmSearch
- First observednpmSize
- First observednpmTrends
- First observednpmTypes
- First observednpmVersions
- First observednpmVulnerabilities

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-07-28 15:10 across 19 tools

Disambiguation5/5

Each tool targets a distinct aspect of NPM packages (e.g., versions, dependencies, vulnerabilities, trends). There is no overlap; even similar-sounding tools like npmQuality, npmMaintenance, and npmScore have clearly separated purposes.

Naming Consistency5/5

All tools follow a consistent camelCase pattern starting with 'npm' followed by a descriptive noun or noun phrase (e.g., npmVersions, npmChangelogAnalysis). The naming is predictable and uniform.

Tool Count4/5

With 19 tools, the set is slightly above the typical well-scoped range of 3-15, but each tool serves a specific and valuable function within the domain of NPM package analysis, making the count reasonable.

Completeness4/5

The tools cover a wide range of NPM package metrics and information (versions, dependencies, vulnerabilities, trends, license, etc.), leaving few gaps (e.g., dependents or reverse dependencies missing). The coverage is comprehensive for the server's purpose.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Npm Package Info Mcp
io.github.varvararatta
Dive into the world of npm with our NPM Package Info MCP. Access crucial metadata about any npm
Developer Tools Search
2
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Package Intel MCP A
io.github.selflabbs
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Developer Tools Code Analysis
2

Related MCP Servers

NPM MCP Server
Search Developer Tools
mateusribeirocampos
A
license
D
quality
D
maintenance
A Model Context Protocol server that allows AI models to fetch detailed information about npm packages and discover popular packages in the npm ecosystem.
Updated a year ago (2025-03-31 10:49 UTC)
1
8 npm
1
ISC
NPM Helper MCP
Developer Tools Code Execution Version Control
pinkpixel-dev
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides tools for NPM package management, including dependency searching, updates, conflict resolution, and version management to help AI assistants safely upgrade project dependencies.
Updated 6 months ago (2026-03-31 10:27 UTC)
54 npm
8
MIT
NPM MCP Server
Kpangaa
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables language models to interact with npm services securely, providing tools for package management, project initialization, script execution, and security auditing.
Updated a year ago (2025-07-18 00:46 UTC)
8 npm
MIT
npm-registry-mcp
Developer Tools Search Code Analysis
howmanysmall
A
license
Not graded
quality
C
maintenance
An MCP server for searching, inspecting, and evaluating NPM packages through health scoring and license risk assessments. It provides comprehensive package analysis including maintenance status, popularity trends, and security vulnerability reports to help users make informed dependency decisions.
Updated 7 months ago (2026-02-21 02:50 UTC)
3
MIT

NPM Sentinel MCP

Key Features

Security & OWASP LLM01 Compliance

Example Usage (JSON-RPC)

Installation & Transports

Dual-Era MCP Architecture (v1 2025-11-25 + v2 2026-07-28)

Install in VS Code / Cursor

Install in Claude Desktop

Smithery.ai Deployment

Docker Usage

Web Standard Streamable HTTP & Cloudflare Workers Integration

Configuration

MCP Server Capabilities (v2 API)

Server Resources

Server Prompts

Tools Catalog (19 Tools)

1. npmLatest

2. npmVersions

3. npmDeps

4. npmTypes

5. npmSize

6. npmVulnerabilities

7. npmTrends

8. npmCompare

9. npmMaintainers

10. npmScore

11. npmPackageReadme

12. npmSearch

13. npmLicenseCompatibility

14. npmRepoStats

15. npmDeprecated

16. npmChangelogAnalysis

17. npmAlternatives

18. npmQuality

19. npmMaintenance

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Dual-Era MCP Architecture (v1 `2025-11-25` + v2 `2026-07-28`)

1. `npmLatest`

2. `npmVersions`

3. `npmDeps`

4. `npmTypes`

5. `npmSize`

6. `npmVulnerabilities`

7. `npmTrends`

8. `npmCompare`

9. `npmMaintainers`

10. `npmScore`

11. `npmPackageReadme`

12. `npmSearch`

13. `npmLicenseCompatibility`

14. `npmRepoStats`

15. `npmDeprecated`

16. `npmChangelogAnalysis`

17. `npmAlternatives`

18. `npmQuality`

19. `npmMaintenance`