Skip to main content
Glama

check_deps

Analyze project dependencies for version health, security vulnerabilities, and size to identify potential issues and maintain code quality.

Instructions

【依赖检查】分析项目依赖的健康度(版本、安全漏洞、体积)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function `checkDeps` that implements the core logic of the 'check_deps' tool. It returns a detailed prompt message instructing on how to analyze project dependencies for health, security, size, and optimization opportunities.
    export async function checkDeps(args: any) {
      try {
        const message = `请分析项目依赖的健康状况:
    
    ---
    
    ## 依赖分析步骤
    
    ### 第一步:获取依赖信息
    
    执行以下命令:
    \`\`\`bash
    # 查看 package.json
    cat package.json
    
    # 检查过期依赖
    npm outdated
    
    # 检查安全漏洞
    npm audit
    
    # 查看依赖树
    npm list --depth=0
    
    # 分析包大小
    npm ls --prod --parseable | xargs du -sh
    \`\`\`
    
    ### 第二步:依赖健康度检查
    
    **1️⃣ 版本检查**
    
    检查项:
    - [ ] 依赖版本是否过旧(> 1 年未更新)
    - [ ] 是否有 Major 版本更新可用
    - [ ] 是否使用了废弃的包
    - [ ] 版本锁定策略(^、~、固定版本)
    
    **2️⃣ 安全漏洞检查**
    
    分析 \`npm audit\` 结果:
    - 🔴 Critical:立即修复
    - 🟠 High:尽快修复
    - 🟡 Moderate:计划修复
    - 🟢 Low:可选修复
    
    **3️⃣ 依赖体积分析**
    
    检查项:
    - [ ] 单个依赖是否过大(> 10MB)
    - [ ] 是否有轻量级替代方案
    - [ ] Tree-shaking 优化机会
    - [ ] 是否可以按需导入
    
    **4️⃣ 依赖健康度评估**
    
    评估指标:
    - 维护状态(活跃/停止维护)
    - 社区活跃度(GitHub Stars/Issues)
    - 发布频率
    - 文档质量
    - TypeScript 支持
    
    **5️⃣ 未使用依赖检查**
    
    查找方法:
    \`\`\`bash
    # 使用 depcheck
    npx depcheck
    
    # 手动检查
    grep -r "from 'package-name'" src/
    \`\`\`
    
    ---
    
    ## 依赖分析报告
    
    ### 📊 依赖统计
    
    **总体情况**:
    - Dependencies: X 个
    - DevDependencies: Y 个
    - 总大小: Z MB
    
    **版本分布**:
    - 最新版本: X 个
    - 需要更新: Y 个
    - 已废弃: Z 个
    
    ### 🔴 严重问题
    
    **安全漏洞**:
    1. **package-name@version**
       - 漏洞等级:Critical
       - CVE 编号:CVE-2024-XXXX
       - 影响:...
       - 修复方案:升级到 version X.X.X
       - 命令:\`npm install package-name@X.X.X\`
    
    **废弃包**:
    1. **package-name**
       - 状态:已停止维护
       - 最后更新:2020-01-01
       - 替代方案:alternative-package
       - 迁移指南:...
    
    ### 🟡 建议更新
    
    **可用更新**:
    | 包名 | 当前版本 | 最新版本 | 类型 | 优先级 |
    |------|---------|---------|------|--------|
    | pkg1 | 1.0.0 | 2.0.0 | Major | 中 |
    | pkg2 | 1.5.0 | 1.8.0 | Minor | 低 |
    
    **更新建议**:
    1. **Major 更新**(需要测试):
       - \`npm install pkg1@2.0.0\`
       - 查看 Breaking Changes
    
    2. **Minor/Patch 更新**(风险较低):
       - \`npm update\`
    
    ### 🟢 优化建议
    
    **体积优化**:
    1. **large-package (15MB)**
       - 建议:使用 tree-shaking
       - 或替换为:lighter-alternative (2MB)
       - 预计减少:13MB
    
    **未使用依赖**:
    1. unused-package
       - 建议:移除
       - 命令:\`npm uninstall unused-package\`
    
    **重复依赖**:
    1. package-name 存在多个版本
       - 建议:统一版本
       - 使用:\`npm dedupe\`
    
    ---
    
    ## 升级计划
    
    ### 立即处理(本周)
    1. 修复 Critical/High 安全漏洞
    2. 移除未使用的依赖
    3. 更新 Patch 版本
    
    ### 短期计划(本月)
    1. 更新 Minor 版本
    2. 替换废弃的包
    3. 优化依赖体积
    
    ### 长期计划(本季度)
    1. 评估 Major 版本更新
    2. 重构依赖架构
    3. 定期审查依赖健康度
    
    ---
    
    ## 预防措施
    
    **最佳实践**:
    1. 使用 \`package-lock.json\` 锁定版本
    2. 定期运行 \`npm audit\`
    3. 使用 Dependabot 自动更新
    4. 评估新依赖前检查健康度
    5. 优先选择活跃维护的包
    
    **CI/CD 集成**:
    \`\`\`yaml
    # GitHub Actions 示例
    - name: Audit dependencies
      run: npm audit --audit-level=moderate
    \`\`\`
    
    ---
    
    现在请开始依赖分析,生成详细的分析报告和升级计划。`;
    
        return {
          content: [
            {
              type: "text",
              text: message,
            },
          ],
        };
      } catch (error) {
        const errorMessage =
          error instanceof Error ? error.message : String(error);
        return {
          content: [
            {
              type: "text",
              text: `❌ 依赖分析失败: ${errorMessage}`,
            },
          ],
          isError: true,
        };
      }
    }
  • The schema definition for the 'check_deps' tool, registered in the ListToolsRequestHandler. It specifies the tool name, description, and empty input schema (no required parameters).
    {
      name: "check_deps",
      description: "【依赖检查】分析项目依赖的健康度(版本、安全漏洞、体积)",
      inputSchema: {
        type: "object",
        properties: {},
        required: [],
      },
    },
  • src/index.ts:486-487 (registration)
    The switch case in the CallToolRequestHandler that registers and dispatches calls to the 'check_deps' tool by invoking the checkDeps handler function.
    case "check_deps":
      return await checkDeps(args);
  • src/index.ts:13-13 (registration)
    The import statement in src/index.ts that brings in the checkDeps function from src/tools/index.js for use in tool registration.
    codeReview, gentest, genpr, checkDeps, gendoc, genchangelog, refactor, perf,
  • The re-export of checkDeps from its implementation file in src/tools/index.ts, allowing it to be imported in src/index.ts.
    export { checkDeps } from "./check_deps.js";
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing health metrics but doesn't specify whether this is a read-only operation, if it requires specific permissions, how results are returned, or any performance implications. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 extremely concise—a single sentence in Chinese that efficiently conveys the core functionality without any redundant information. It's front-loaded with the key action and resource, making it easy for an agent to parse quickly.

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 has no parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, output format, or usage context. For a simple analysis tool, this might suffice, but the absence of output information is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying what aspects of dependencies are analyzed (version, security, size), which provides context beyond the empty schema. This compensates appropriately for the lack of parameters.

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's purpose: analyzing project dependencies for health metrics including version status, security vulnerabilities, and size. It uses specific verbs ('分析' meaning analyze) and identifies the resource ('项目依赖' meaning project dependencies). However, it doesn't explicitly differentiate from sibling tools like 'analyze_project' or 'perf', which might have overlapping functionality.

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. It doesn't mention prerequisites, context for usage, or exclusions. Given sibling tools like 'analyze_project' and 'perf' that might handle related analyses, the lack of differentiation leaves the agent without clear selection criteria.

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

Install Server

Other Tools

Latest Blog Posts

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/mybolide/mcp-probe-kit'

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