de en es ja ko ru zh

NPM Sentinel MCP

Name: NPM Sentinel MCP
Author: Nekzus

by Nekzus

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

NPM Sentinel MCP

Github 工作流程 npm 版本 npm-month npm-total 铁匠徽章询问 DeepWiki

强大的模型上下文协议 (MCP) 服务器，通过 AI 革新 NPM 包分析。它与 Claude 和 Anthropic AI 集成，提供有关包安全性、依赖项和性能的实时情报。这款 MCP 服务器提供即时洞察和智能分析，以保护和优化您的 npm 生态系统，使现代开发工作流程中更快、更安全地进行包管理决策。

特征

版本分析与跟踪
依赖关系分析和映射
安全漏洞扫描
包装质量指标
下载趋势和统计数据
TypeScript 支持验证
封装尺寸分析
维护指标
实时套餐比较
标准化错误处理和 MCP 响应格式
高效缓存，提高性能和 API 速率限制管理
使用 Zod 进行严格的模式验证和类型安全

注意：服务器通过 MCP 集成提供 AI 辅助分析。

Related MCP server: NPM Helper MCP

安装

在 VS Code 中安装

将其添加到你的 VS Code MCP 配置文件中。更多信息请参阅VS Code MCP 文档。

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

Docker

建造

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

用法

您可以使用 Docker 运行 MCP 服务器并将目录挂载到/projects ：

{
  "mcpServers": {
    "npm-sentinel-mcp": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-w", "/projects",
        "--mount", "type=bind,src=${PWD},dst=/projects",
        "nekzus/npm-sentinel-mcp",
        "node",
        "dist/index.js"
      ]
    }
  }
}

对于多个目录：

{
  "mcpServers": {
    "npm-sentinel-mcp": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-w", "/projects",
        "--mount", "type=bind,src=/path/to/workspace,dst=/projects/workspace",
        "--mount", "type=bind,src=/path/to/other/dir,dst=/projects/other/dir,ro",
        "nekzus/npm-sentinel-mcp",
        "node",
        "dist/index.js"
      ]
    }
  }
}

注意：所有挂载的目录必须位于/projects下才能正确访问。

与 Claude Desktop 一起使用

将其添加到您的claude_desktop_config.json中：

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

配置文件位置：

Windows： %APPDATA%\Claude\claude_desktop_config.json
macOS： ~/Library/Application Support/Claude/claude_desktop_config.json
Linux：（Claude for Desktop 目前尚未正式支持 Linux）

NPX

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

API

服务器通过模型上下文协议 (MCP) 暴露其工具。所有工具均遵循标准化的响应格式：

{
  "content": [
    {
      "type": "text",
      "text": "string",
      "isError": boolean // Optional
    }
    // ... more content items if necessary
  ]
}

资源

npm://registry ：NPM 注册界面
npm://security ：安全分析接口
npm://metrics ：包指标接口

服务器资源

服务器还提供可通过 MCP GetResource请求访问的以下信息资源：

doc://server/readme ：
- 描述：检索此 NPM Sentinel MCP 服务器的主要README.md文件内容。
- MIME 类型： text/markdown
doc://mcp/specification ：
- 描述：检索llms-full.txt内容，提供全面的模型上下文协议规范。
- MIME 类型： text/plain

工具

npm版本

获取包的所有版本
输入： packages （string[]）
返回：带有发布日期的版本历史记录

npm最新

获取最新版本信息
输入： packages （string[]）
返回：最新版本详细信息和更新日志

npmDeps

分析包依赖关系
输入： packages （string[]）
返回：完整的依赖树分析

npm类型

检查 TypeScript 支持
输入： packages （string[]）
返回：TypeScript 兼容性状态

npm大小

分析包裹大小
输入： packages （string[]）
返回：捆绑包大小和导入成本分析

npm漏洞

扫描安全漏洞
输入： packages （string[]）
返回：安全公告和严重性评级

npm趋势

获取下载趋势
输入：
- packages （字符串[]）
- period （“上周” | “上个月” | “去年”）
返回：随时间推移的下载统计数据

npm比较

比较多个包
输入： packages （string[]）
返回：详细的比较指标

npm维护者

获取软件包维护者
输入： packages （string[]）
返回：维护者信息和活动

npm分数

获取包质量分数
输入： packages （string[]）
返回：综合质量指标

npmPackageReadme

获取软件包自述文件
输入： packages （string[]）
返回：格式化的 README 内容

npm搜索

搜索包
输入：
- query （字符串）
- limit （数字，可选）
返回：匹配带有元数据的包

npm许可证兼容性

检查许可证兼容性
输入： packages （string[]）
返回：许可证分析和兼容性信息

npmRepoStats

获取存储库统计信息
输入： packages （string[]）
返回：GitHub/存储库指标

npm已弃用

检查是否弃用
输入： packages （string[]）
返回：弃用状态和替代方案

npm变更日志分析

分析软件包变更日志
输入： packages （string[]）
返回：变更日志摘要和影响分析

npmAlternatives

查找软件包替代方案
输入： packages （string[]）
返回：类似的包装与比较

npm质量

评估包装质量
输入： packages （string[]）
返回：质量指标和分数

npm维护

检查维护状态
输入： packages （string[]）
返回：维护活动指标

建造

# Build with npm
npm install
npm run build

执照

此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。更多详情，请参阅项目仓库中的 LICENSE 文件。

麻省理工学院 © 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
com.datakoot
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Developer Tools Code Analysis
61

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

特征

安装

在 VS Code 中安装

Docker

建造

用法

与 Claude Desktop 一起使用

NPX

API

资源

服务器资源

工具

npm版本

npm最新

npmDeps

npm类型

npm大小

npm漏洞

npm趋势

npm比较

npm维护者

npm分数

npmPackageReadme

npm搜索

npm许可证兼容性

npmRepoStats

npm已弃用

npm变更日志分析

npmAlternatives

npm质量

npm维护

建造

执照

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