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 "Install 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 Related Servers Score Discussions

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

npmAlternativesA

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

A3.8/5.0

Behavior3/5

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

Annotations provide readOnlyHint, openWorldHint, and idempotentHint. The description does not add behavioral details beyond these annotations. It does not mention caching behavior (though schema has ignoreCache param) or result variability, but also 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?

Single, clear sentence with no waste. Immediately conveys the core functionality without 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 low complexity (2 params, 1 required, no nested objects) and existence of output schema, the description is sufficient for an agent to understand the tool's purpose. Minor improvement could include example usage or result format hints.

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 covers 100% of parameters (packages, ignoreCache) with descriptions. The tool description adds no additional meaning beyond the schema, so baseline score 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?

Description clearly states 'Find alternative packages with similar functionality', which is a specific verb-resource pair. It distinguishes itself from sibling tools like npmVersions (versions), npmDeps (dependencies), npmSize (size), etc., each targeting a different aspect 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 Guidelines3/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 npmDeps or npmScore. The description implies usage for finding alternatives but lacks exclusions or comparison to siblings, leaving agents to infer 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?

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds no additional behavioral context beyond what is in the annotations, such as rate limits, caching behavior, or data sources.

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 is easy to read. However, it could be more informative 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?

Given the presence of an output schema and 2 parameters, the description is too brief. It does not describe the output format or the nature of the analysis, which would be helpful for an agent.

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 description is not required to add parameter meaning. The description does not elaborate on the parameters, nor does it compensate for any gaps.

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 states 'Analyze changelog and release history of packages' which clearly identifies the verb and resource. It distinguishes from sibling tools like 'npmVersions' by focusing on changelog analysis rather than version listing.

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 sibling tools are listed but not referenced, and there is no mention of prerequisites or when not to use the tool.

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.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. The description adds no additional behavioral context (e.g., caching behavior or error handling). It is adequate but does not exceed the information already provided by 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 effectively communicates the core purpose. It is front-loaded and contains no unnecessary words, earning a high score for conciseness.

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?

Despite the brevity, the presence of an output schema (not shown) and sibling tools provides sufficient context for an AI agent. The description is complete enough for the tool's simplicity, though it could mention the metrics compared.

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. The description does not add any extra meaning beyond the schema, so it meets the baseline for this dimension.

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 uses a specific verb 'Compare' and resource 'NPM packages', clearly indicating the tool's function. It distinguishes from siblings like npmScore or npmSize by focusing on multiple packages and 'various metrics', though the metrics are not enumerated.

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 or npmDeps. The description does not indicate scenarios, prerequisites, or when to prefer individual metric tools.

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=true, idempotentHint=true, and openWorldHint=true. The description adds no behavioral context beyond these, such as caching behavior or dependence on npm registry status.

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 of 5 words, making it very concise. It effectively communicates the core purpose without waste, though it could benefit from a bit more detail.

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?

For a simple read-only tool with a complete schema and output schema available, the description is minimally complete. However, missing usage guidance and behavioral context make it slightly inadequate for complex decision-making.

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 parameters ('packages' and 'ignoreCache'), so the description adds no extra meaning. Baseline 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 'Check' and resource 'packages' with the outcome 'deprecated', providing a specific purpose. However, it does not differentiate from sibling tools like npmVersions or npmLatest, which could be confused by an AI agent.

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 gives no guidance on when to use this tool versus alternatives such as npmVersions for version checks or npmVulnerabilities for security issues. The agent has no context for selection.

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

npmDepsB

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

B3.4/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint – description adds no behavioral context beyond stating 'dependencies and devDependencies'. Does not disclose caching details, rate limits, or error handling. With annotations, the description's contribution is minimal but not contradictory.

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, front-loaded with action ('Analyze'), immediate resource identification. No fluff. Could slightly expand without harming conciseness, but current is 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?

Output schema exists, so return details not needed. However, given many sibling tools, more context on scope (e.g., whether it deep-resolves transitive deps, version handling) would improve agent selection. Currently adequate but uninformative.

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 (packages, ignoreCache). Tool description adds no additional meaning to parameters – baseline 3 applies as schema does the heavy lifting.

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 explicitly states 'Analyze dependencies and devDependencies of an NPM package' – clear verb+resource. Differentiates from siblings like npmVersions (versions), npmLatest (latest version), npmVulnerabilities (security) by focusing specifically on dependency analysis.

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 (e.g., npmVulnerabilities for security, npmTypes for type definitions). No mention of prerequisites, input format (e.g., version suffixes), or conditions favoring this tool over other dependency-related tools.

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

npmLatestA

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

A3.6/5.0

Behavior3/5

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

Annotations already indicate readOnly, openWorld, and idempotent. The description adds the cache-related ignoreCache parameter but does not elaborate on caching behavior or rate limits. It is adequate but not enhanced 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.

Conciseness5/5

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

Single sentence, front-loaded, no wasted words. Efficiently conveys the tool's purpose.

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?

With an output schema present, the description is sufficient for a simple tool. It could mention handling of multiple packages, but that is implied by the schema. Overall, it meets needs without gaps.

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 parameters. The tool description does not add extra semantics beyond what is in the schema, 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?

Description clearly states the action 'Get' and the resource 'latest version and changelog of an NPM package'. It is specific and distinguishes from sibling tools like npmVersions (which likely returns all versions).

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 such as npmVersions or npmChangelogAnalysis. The description only states what it does without providing selection criteria.

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.3/5.0

Behavior2/5

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds no additional behavioral context such as how compatibility is determined, caching behavior, or potential network calls.

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 one sentence, front-loaded, and contains no redundant information. Every word serves a purpose.

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 simple parameters (2), output schema exists, and annotations cover safety, the description is adequate but could be improved by briefly explaining how compatibility is assessed (e.g., SPDX license comparison).

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 (packages, ignoreCache) with descriptions. The tool description does not add new semantic value beyond schema; baseline 3 is appropriate since schema coverage is 100%.

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 verb (check) and resource (license compatibility). It distinguishes from sibling tools like npmVersions, npmDeps, etc., which cover different aspects.

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 vs alternatives, prerequisites (e.g., whether packages need to exist), or exclusions. With many sibling tools, usage context is lacking.

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

npmMaintainersA

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

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's minimal statement is consistent but adds no additional behavioral context such as caching behavior, rate limits, or implications of the 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.

Conciseness5/5

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

The description is a single sentence with no wasted words. It is front-loaded and to the point.

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 output schema exists and the tool is simple, the description is minimally complete. However, with numerous sibling tools, additional context about typical use cases or limitations (e.g., package name format) could improve usability.

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 parameters. The description does not add further meaning; for example, it doesn't specify what 'maintainers information' includes in the response. Baseline 3 is appropriate as schema does the heavy lifting.

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 action (Get) and the resource (maintainers information for NPM packages). It distinguishes from siblings like npmVersions which retrieve version data, making selection unambiguous.

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 usage guidance is provided. The description does not indicate when to use this tool over its siblings, nor under what conditions (e.g., for checking package ownership vs. quality).

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, openWorldHint, and idempotentHint, covering safety and side effects. The description adds no behavioral details beyond what annotations provide, but does not contradict them.

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 with no redundancy. It is front-loaded but arguably under-specified, earning a 4 for efficiency without excess.

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 an output schema and well-documented params, the description omits what 'maintenance metrics' specifically includes, and lacks sibling differentiation. This leaves gaps in completeness for a tool with many siblings.

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 input schema fully documents both parameters. The description adds no additional meaning, meeting the baseline for this dimension.

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 uses clear verb 'Analyze' and resource 'package maintenance metrics', indicating the tool's purpose. However, it does not differentiate from siblings like npmScore or npmQuality, reducing distinctiveness.

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 over siblings or when not to. The description lacks context for usage, leaving the agent to infer without help.

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.1/5.0

Behavior3/5

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

Description adds minimal behavioral context beyond annotations (readOnlyHint, idempotentHint). It does not mention caching behavior or response format, but annotations cover safety and idempotency.

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?

Single concise sentence, but it is too minimal. Lacks structural elements like usage context or return value hints. Would benefit from slightly more detail without losing conciseness.

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?

For its simplicity, the description is adequate but not thorough. Missing details about caching behavior and the format of returned READMEs. Output schema may compensate, but description alone is incomplete.

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 baseline is 3. Description adds no extra meaning for parameters; it only names the overall action.

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?

Description clearly states it gets README content for NPM packages using a specific verb+resource. However, it does not differentiate from sibling tools that also operate on NPM packages, missing a chance to clarify uniqueness.

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 npmVersions or npmLatest. The description offers no contextual hints about appropriate use cases.

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.9/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to repeat. However, it adds no behavioral context beyond 'analyze quality metrics', such as data source (NPMS.io), caching behavior, or what metrics are included.

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, no wasted words. Highly concise.

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 the complexity of sibling tools and the presence of an output schema, the description should provide more context about what 'quality metrics' entails or when to use this tool. It is insufficient for informed 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?

Schema coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning or usage guidance for the parameters.

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 a clear verb+resource but does not differentiate from sibling tools like npmScore or npmMaintenance. The title in annotations adds context but the description itself is 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 guidance on when to use this tool versus alternatives. With many sibling tools, the absence of usage context makes it hard for an agent to select correctly.

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.3/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the description's main job is to add context. It does not contradict annotations, but it adds little behavioral detail beyond the high-level purpose, such as whether results are from live GitHub API or cached, or what 'statistics' entails.

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 concise sentence that front-loads the core action and resource. Every word is necessary, and there is no repetition or fluff.

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 the tool's relative simplicity, the description provides a minimal but adequate high-level context. However, for a tool with many siblings, it lacks specifics about what statistics are included (e.g., stars, forks, open issues) and how it differs from other stats tools.

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 fully documents both parameters. The description adds no extra meaning or context about the parameters beyond the tool's overall purpose, which meets the baseline.

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 'Get' and the resource 'repository statistics for NPM packages', which is specific enough to indicate the tool's main function. However, it does not differentiate from sibling tools like 'npmScore' or 'npmMaintenance' that might also return repository-related data.

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 over its many siblings (e.g., npmVersions, npmDeps). The description does not indicate typical use cases or when alternatives would be more appropriate.

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.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds that the score is from NPMS.io and based on three metrics, which is consistent. Does not contradict annotations, but adds only minor behavioral context beyond what annotations provide.

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?

One succinct sentence that includes all essential information. No unnecessary words, and the key verb, resource, and metrics are front-loaded.

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

Completeness5/5

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

Given the low complexity (two parameters, one required), presence of output schema, and annotations covering safety and idempotency, the description is complete enough for an agent to correctly select and invoke this 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 coverage is 100% for parameters. Description does not add additional meaning beyond the schema; it simply mentions the output type. Baseline score of 3 is appropriate as the schema already documents both parameters clearly.

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 the verb 'Get', the resource 'consolidated package score', and the dimensions it covers (quality, maintenance, popularity). It distinguishes from siblings like npmQuality and npmMaintenance by indicating this is a composite score.

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?

No explicit guidance on when to use this tool versus alternatives like npmQuality or npmMaintenance. The description implies it is for an overall score, but does not provide when-not scenarios or mention siblings.

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

npmSearchB

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

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds no extra behavioral context (e.g., caching behavior, rate limits, result format). With annotations, the bar is lower, but the description misses 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 short sentence with no wasted words. However, it could be slightly more informative while remaining concise.

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 the presence of an output schema (not shown) and many sibling tools, the description is too sparse. It does not mention what the search returns, sorting, or pagination, leaving the agent underinformed about the tool's full behavior.

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 has 100% description coverage, so parameters are already well-documented. The description adds no additional meaning beyond the schema's descriptions of query, limit, and ignoreCache.

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?

Description clearly states the tool searches for NPM packages with an optional limit, which is specific enough to distinguish from siblings like npmVersions or npmDeps. However, it could be more precise about the search type (e.g., full-text or by name).

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 (e.g., npmLatest, npmDeps). The description does not help the agent choose appropriately among alternatives.

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.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description adds limited behavioral context. It mentions that the result includes dependencies and bundle size, and the ignoreCache parameter implies caching, but does not discuss limits or external service (Bundlephobia) usage.

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, well-formed sentence that immediately conveys the tool's purpose. It could be slightly more structured with a bullet or line break, but it is 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 existence of an output schema, the description does not need to detail return values. It sufficiently explains the tool's function for a straightforward lookup. Minor missing context (e.g., external data source) prevents a higher score.

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 adequately. The description adds no additional parameter meaning beyond what the schema provides, earning the baseline score.

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 'Get package size information including dependencies and bundle size', which specifies the verb (Get), resource (package size information), and includes specifics (dependencies and bundle size). It distinguishes from siblings like npmDeps, which focuses on dependencies alone.

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 when-to-use or when-not-to-use guidance, nor does it reference any of the 18 sibling tools. The agent must infer the tool's purpose without explicit context about alternatives.

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

npmTrendsB

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

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description's statement 'Get download trends' is consistent. However, the description adds no behavioral context beyond what annotations provide, such as caching behavior (though the 'ignoreCache' parameter exists) or rate limits. With good annotations, a score of 3 is appropriate – the description is adequate but not informative.

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, clear sentence that efficiently conveys the tool's purpose. It is front-loaded and contains no unnecessary words. However, it could be slightly more structured (e.g., mentioning the primary parameter), but for a simple tool, it is highly concise.

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 (3 parameters, output schema exists, good annotations), the description is minimally complete – it states the purpose. However, it does not clarify that the tool fetches data from npm trends or mention constraints like the 25-package limit (covered in schema). It is adequate but not exemplary.

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 coverage is 100%, so the schema already describes all three parameters (packages, period, ignoreCache) with definitions and defaults. The description adds no additional meaning or context about parameters. Baseline 3 is correct when the schema bears the load.

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 download trends and popularity metrics for packages' clearly states the tool's function: retrieving download trend and popularity data for packages. It uses a specific verb ('Get') and resource ('download trends and popularity metrics'), and it distinguishes this tool from siblings like npmVersions, npmDeps, etc., by focusing solely on trends and popularity.

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 the many sibling tools (e.g., npmScore, npmQuality). There is no mention of prerequisites, typical use cases, or when not to use it. An agent would not know what distinguishes this from other npm analysis tools without further context.

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.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds no extra behavioral context beyond 'Check availability and version', which is consistent 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?

Single sentence, 8 words, no fluff. Front-loads key action. Could be slightly more informative, but very efficient.

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 simplicity of parameters (2, one required) and presence of output schema, the description is sufficient. It covers the main action without missing critical details.

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% (both parameters have descriptions). Tool description does not add any extra meaning beyond what the schema already provides, so 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?

Description clearly states the verb 'Check' and the specific resource 'TypeScript types availability and version for a package'. This distinguishes it from sibling tools like npmVersions (version only) and npmDeps (dependencies).

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 npmVersions or npmLatest. Does not specify context or exclusion criteria.

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

npmVersionsB

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

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, covering safety and caching. Description adds no further behavioral context (e.g., that results may be cached, response format). With annotations present, a 3 is appropriate.

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, direct sentence with no extraneous information. Highly efficient and front-loaded with the core action.

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 tool's simplicity (two params, no enums, no nested objects) and presence of output schema, the description is nearly sufficient. Lacks rate-limit or usage policy info, but annotations (openWorldHint) help. Adequate for routine use.

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 clear descriptions for both parameters. The tool's main description does not add meaning beyond what the schema already provides, so baseline 3 is correct.

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?

Description clearly states it retrieves all available versions of an NPM package. Verb 'Get' and resource 'all available versions' are specific. It distinguishes from sibling tools like npmLatest (single latest version) and npmDeps (dependencies). However, it mentions 'an NPM package' singular while input accepts multiple packages, causing slight mismatch.

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 siblings such as npmLatest or npmDeps. Agent is left to infer context from purpose alone, which is insufficient for correct selection among many NPM-related tools.

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

npmVulnerabilitiesA

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

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which cover safety and non-determinism. The description adds no further behavioral details (e.g., caching behavior, rate limits, or what happens on failure). 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, concise sentence that clearly communicates the purpose. There is no fluff or redundancy. Every word 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?

Given the tool's simplicity (2 params, no nested objects) and the presence of an output schema, the description is mostly complete. It could mention the data source (OSV.dev, shown in annotations) but that is not critical. The description suffices for an agent to understand the tool's basic function.

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%: both parameters ('packages' and 'ignoreCache') have descriptions in the schema. The tool description adds no additional meaning beyond what the schema provides, so the 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 purpose: 'Check for known vulnerabilities in packages'. It uses a specific verb ('check') and resource ('known vulnerabilities in packages'). The title annotation adds further specificity with 'Check Package Vulnerabilities (OSV.dev)', distinguishing it 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?

The description provides no guidance on when to use this tool versus its many siblings (e.g., npmQuality, npmMaintenance). There is no mention of prerequisites, exclusions, or alternative tools. Usage context is only implied by the tool's purpose.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

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

ActivityActive

ResponsivenessSyncing

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
237
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
12
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 5 months ago (2026-03-31 10:27 UTC)
67
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)
12
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 6 months ago (2026-02-21 02:50 UTC)
3
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nekzus/npm-sentinel-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

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

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

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`