# io.github.mybolide/mcp-probe-kit (npm · mcp-probe-kit)

Spec-driven dev workflow MCP: start_* orchestration, memory, GitNexus, quality gates.

- Trust score: 65/100 (medium)
- Change this week: +14
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- npm · `mcp-probe-kit`: 65/100 (this document), [markdown](https://verifymcp.io/servers/mybolide-mcp-probe-kit/mcp-probe-kit.md), [page](https://verifymcp.io/servers/mybolide-mcp-probe-kit/mcp-probe-kit)

## Channel facts

- Registry: `npm`
- Package: `mcp-probe-kit`
- Version: `3.6.3`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Supply Chain Security**: 87/100
  - No malware found by supply-chain analysis.
  - Only part of the dependency tree could be resolved (101 of 105), so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Only part of the dependency tree could be resolved (101 of 105), so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 55/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (poor).
  - Context-footprint check failed: tool/resource definitions use about 6078 tokens (~189/item across 32 items; 30 tools + 2 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add mybolide-mcp-probe-kit -- npx -y mcp-probe-kit
```

### Codex

```bash
codex mcp add mybolide-mcp-probe-kit -- npx -y mcp-probe-kit
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mybolide-mcp-probe-kit": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "mcp-probe-kit"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add mybolide-mcp-probe-kit --command npx --arg -y --arg mcp-probe-kit
```

### Hermes

```yaml
mcp_servers:
  mybolide-mcp-probe-kit:
    command: "npx"
    args: ["-y", "mcp-probe-kit"]
```

### Other

```json
{
  "mcpServers": {
    "mybolide-mcp-probe-kit": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-probe-kit"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-02 (score 64, +35)

- [security regression] Provenance: unverified → fail
- [security improvement] Install scripts: unverified → pass
- [security improvement] Known CVEs: unverified → partial
- [security improvement] Malware scan: unverified → pass
- [security] Stability: Stability not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.
- [functional regression] Security disclosure: fail → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Schema quality: 100 → unverified
- [functional improvement] Stability: unverified → 0.20
- [functional improvement] License: unverified → pass
- [functional improvement] Dependency health: unverified → partial
- [functional improvement] Schema quality: unverified → poor
- [functional improvement] Maintenance: unverified → pass
- [functional] Licence: MIT

### 2026-08-01 (score 29, +5)

- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [functional improvement] MCP protocol: unverified → pass

### 2026-07-31 (score 24, −27)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-27 (score 51)

First indexed and scored.

## MCP tools (30)

### `init_project` (~183 tokens)

当用户提供一句话需求时使用。基于 Spec-Driven Development 理念，分析需求并生成完整的项目规格文档（需求分析/技术设计/任务拆解）。适合项目初期的需求澄清和规划

Input parameters:

- `input` (string): 项目需求描述。可以是一句话需求（如'创建电商网站'）或简短的功能描述，工具会自动分析并生成详细的规格文档
- `project_name` (string): 项目名称。可选，默认为'新项目'
- `project_root` (string): 可选。项目根目录绝对路径；未传时自动从 MCP 客户端工作区解析（如 Cursor 注入 WORKSPACE_FOLDER_PATHS、OpenCode/客户端配置的 cwd 等）。仅边缘场景需手动传入。

### `gencommit` (~149 tokens)

当用户需要生成 Git commit 消息时使用。返回 Conventional Commits 规范说明、步骤、输出模板和示例，供 AI 根据变更内容生成最终 commit message。它不直接代写最终消息，也不应被判定为空结果

Input parameters:

- `changes` (string): 代码变更内容。可以是 git diff 输出、变更描述或自然语言。如果不提供，工具会提示执行 git diff
- `type` (string): Commit 类型：fixed（修复）、feat（新功能）、docs（文档）、style（样式）、chore（杂项）、refactor（重构）、test（测试）。可选，会自动识别

### `git_work_report` (~264 tokens)

基于 Git diff 分析生成工作报告（日报/周期报）

核心功能：
\- 支持日报模式（单个日期）和周期报模式（日期范围）
\- 自动读取指定日期的所有 Git 提交
\- 对每个提交执行 git show 获取完整 diff
\- 使用 AI 分析 diff 内容提取实际工作内容

输出格式：
\- 只输出「工作内容」部分
\- 每条以 - 开头，中文，简洁专业
\- 格式：做了什么 + 改了哪里/达到什么效果
\- 不输出：提交哈希、文件列表、统计数据、风险总结

使用示例：
\- 日报：git_work_report --date 2026-1-27
\- 周期报：git_work_report --start_date 2026-2-1 --end_date 2026-2-6

Input parameters:

- `date` (string): 单个日期，格式 YYYY-MM-DD（日报模式）
- `end_date` (string): 结束日期，格式 YYYY-MM-DD（周期报模式）
- `output_file` (string): 可选，输出文件路径
- `start_date` (string): 起始日期，格式 YYYY-MM-DD（周期报模式）

### `code_review` (~102 tokens)

当用户需要审查代码质量、检查代码问题时使用。审查代码的质量、安全性、性能，输出结构化问题清单（severity/category/suggestion）

Input parameters:

- `code` (string): 要审查的代码。可以是代码片段、完整文件或 git diff 输出
- `focus` (string): 审查重点：security（安全）、performance（性能）、quality（质量）、all（全部）。可选，默认 all

### `code_insight` (~253 tokens)

当用户需要基于代码图谱分析调用链、上下文和影响面时使用。默认桥接 GitNexus，支持 query/context/impact 模式；不可用时自动降级并返回原因

Input parameters:

- `direction` (string): impact 方向：upstream / downstream
- `goal` (string): 分析目标（可选）
- `include_tests` (boolean): impact 是否包含测试文件（可选，默认 false）
- `max_depth` (number): impact 最大深度（可选，默认 3）
- `mode` (string): 分析模式：auto（默认）、query、context、impact
- `project_root` (string): 项目根目录绝对路径。建议显式传入；当调用里还包含相对路径参数时，应统一相对该项目根目录解析，避免依赖客户端 cwd。
- `query` (string): 查询文本（query 模式推荐）
- `repo` (string): 仓库名称（多仓库场景可选）
- `target` (string): 目标符号（context/impact 模式推荐）
- `task_context` (string): 任务上下文（可选）

### `refactor` (~83 tokens)

当用户需要重构代码、改善代码结构时使用。分析代码结构，提供重构建议、重构步骤和风险评估

Input parameters:

- `code` (string): 要重构的代码
- `goal` (string): 重构目标：improve_readability（可读性）、reduce_complexity（复杂度）、performance（性能）。可选

### `fix_bug` (~133 tokens)

当用户需要找问题、修 bug、排查异常、定位回归、分析失败原因、分析为什么没生效、先分析再修时使用。默认采用 TBP 8 步法做真因分析，并输出修复方案与验证步骤

Input parameters:

- `analysis_mode` (string): 分析方法。默认 tbp8（丰田问题分析 8 步法）
- `code_context` (string): 相关代码。可选
- `error_message` (string): 错误信息
- `stack_trace` (string): 堆栈跟踪。可选

### `gentest` (~93 tokens)

当用户需要为代码生成单元测试时使用。生成单元测试代码（Jest/Vitest/Mocha），包含边界用例和 mock

Input parameters:

- `code` (string): 要生成测试的代码。可以是函数、类或模块
- `framework` (string): 测试框架：jest、vitest、mocha。可选，会自动识别项目使用的框架

### `workflow` (~107 tokens)

当不确定该用哪个 MCP 工具时使用。根据意图返回分阶段 MCP 指南（firstTool + phases）。同时确保用户项目已存在 .agents/skills/mcp-probe-kit/SKILL.md 与 AGENTS.md 中的 Skill 引用（缺失则自动创建/更新）。

Input parameters:

- `intent` (string): 用户目标或任务描述（自然语言）
- `scenario` (string): 可选：显式场景；默认 auto 从 intent 推断

### `init_project_context` (~199 tokens)

生成/更新项目上下文：默认写入 AGENTS.md（含 MCP 与 GitNexus 触发规则）及 docs/project-context/。新功能请先 start_feature，修 bug 请先 start_bugfix。完成后 Agent 应阅读 AGENTS.md。

Input parameters:

- `docs_dir` (string): 附属文档根目录（project-context、graph-insights）。默认 docs
- `filename` (string): 高级：与 output_dir 合用，默认 project-context.md
- `index_style` (string): 索引风格：auto（默认 AGENTS.md）、agents、legacy（docs/project-context.md）
- `locale` (string): AGENTS.md 语言；默认根据 README 探测
- `output` (string): 高级：索引文件相对路径，如 AGENTS.md
- `output_dir` (string): 高级：索引所在目录，如 .claude/rules

### `add_feature` (~163 tokens)

当用户需要添加新功能、生成功能规格文档时使用。生成新功能规格文档（需求/设计/任务清单），基于项目上下文

Input parameters:

- `description` (string): 功能详细描述。可以是简短的自然语言（如'添加用户认证功能'）或详细的需求说明
- `docs_dir` (string): 文档输出目录，默认为 docs
- `feature_name` (string): 功能名称（kebab-case 格式，如 user-auth）。可选，如果不提供会从 description 自动提取
- `template_profile` (string): 模板档位：auto（默认，自动选择 guided/strict）、guided（普通模型友好）或 strict（结构更紧凑）

### `estimate` (~163 tokens)

当用户需要估算开发工作量、评估任务时间时使用。估算开发工作量，输出故事点、时间范围（乐观/正常/悲观）、风险点

Input parameters:

- `code_context` (string): 相关代码或文件上下文。可选，有助于更准确的估算
- `experience_level` (string): 经验水平：junior（初级）、mid（中级）、senior（高级）。可选，默认为 mid
- `task_description` (string): 任务描述。可以是简短的自然语言（如'估算开发工作量'）或详细的任务说明
- `team_size` (number): 团队规模（人数）。可选，默认为 1

### `check_spec` (~182 tokens)

校验已落盘的功能规格（docs/specs/<feature_name>/requirements|design|tasks.md）是否完整：检测残留 [填写] 占位、缺失章节、缺 FR/验收标准、FR 未进覆盖矩阵。写完规格后、进入实现前调用；未通过按报告补全后重跑。

Input parameters:

- `docs_dir` (string): 文档根目录，默认为 docs
- `feature_name` (string): 要校验的规格目录名，对应 docs/specs/<feature_name>/
- `project_root` (string): 可选。项目根目录绝对路径；未传时自动从 MCP 客户端工作区解析（如 Cursor 注入 WORKSPACE_FOLDER_PATHS、OpenCode/客户端配置的 cwd 等）。仅边缘场景需手动传入。

### `start_feature` (~297 tokens)

当用户需要完整的新功能开发流程时使用。编排：检查上下文→生成规格→估算工作量。若只需规格文档请用 add_feature

Input parameters:

- `description` (string): 功能详细描述。可以是简短的自然语言（如'开发用户认证功能'）或详细的需求说明
- `docs_dir` (string): 文档输出目录，默认为 docs
- `feature_name` (string): 功能名称（kebab-case 格式，如 user-auth）。可选，如果不提供会从 description 自动提取
- `loop_assumption_cap` (number): 每轮假设上限（默认 3）
- `loop_max_rounds` (number): 需求 loop 最大轮次（默认 2）
- `loop_question_budget` (number): 每轮最多提问数量（默认 5）
- `project_root` (string): 项目根目录绝对路径。建议显式传入；docs_dir 等相对路径参数应统一相对该项目根目录解析，避免依赖客户端 cwd。
- `requirements_mode` (string): 需求模式：steady（默认，直接生成规格）或 loop（需求澄清与补全）
- `template_profile` (string): 模板档位：auto（默认，自动选择 guided/strict）、guided（普通模型友好）或 strict（结构更紧凑）

### `start_bugfix` (~372 tokens)

当用户需要找问题、修 bug、排查异常、定位回归、分析失败原因、分析为什么没生效、先分析再修时使用。默认按 TBP 8 步法编排：取证澄清→分析定位→修复方案→生成测试。

Input parameters:

- `analysis_mode` (string): 分析方法。默认 tbp8（丰田问题分析 8 步法）
- `code_context` (string): 相关代码。可选
- `docs_dir` (string): 文档目录。可选，默认 docs
- `error_message` (string): 错误信息
- `feature_name` (string): 关联功能规格名（对应 docs/specs/<feature_name>/）。提供后或能自动识别时，修复闭环会插入 check_spec 闸门
- `loop_assumption_cap` (number): 每轮假设上限（默认 3）
- `loop_max_rounds` (number): 需求 loop 最大轮次（默认 2）
- `loop_question_budget` (number): 每轮最多提问数量（默认 5）
- `project_root` (string): 项目根目录绝对路径。建议显式传入；docs_dir 等相对路径参数应统一相对该项目根目录解析，避免依赖客户端 cwd。
- `requirements_mode` (string): 需求模式：steady（默认，直接修复）或 loop（需求澄清与补全）
- `stack_trace` (string): 堆栈跟踪。可选
- `template_profile` (string): 模板档位：auto（默认，自动选择 guided/strict）、guided（普通模型友好）或 strict（结构更紧凑）

### `start_onboard` (~86 tokens)

当用户需要快速上手新项目时使用。编排：生成上下文文档。

Input parameters:

- `docs_dir` (string): 文档目录。可选，默认 docs
- `project_path` (string): 项目根目录绝对路径。建议显式传入；如果还传 docs_dir 等相对路径，应统一相对该项目根目录解析。

### `start_ralph` (~379 tokens)

当用户需要启动 Ralph Wiggum Loop 循环开发时使用。生成 .ralph/ 目录结构、安全模式脚本和执行指南。默认启用多重安全保护，防止无人值守时费用失控

Input parameters:

- `cli_command` (string): Claude Code CLI 命令名。默认：'claude-code'（可能需要改为 'claude'）
- `completion_promise` (string): 完成条件描述。默认：'tests passing + requirements met'
- `confirm_every` (number): 每几轮要求人工确认。safe 模式默认：1（每轮都确认）
- `confirm_timeout` (number): 确认等待秒数，超时自动停止。safe 模式默认：20
- `cooldown_seconds` (number): 每轮后冷却秒数。safe 模式默认：8
- `goal` (string): 本次要完成的目标/需求描述。例如：'实现用户认证功能'、'修复登录 bug'
- `max_diff_lines` (number): git diff 变更行数超过此值停止（防失控）。safe 模式默认：300
- `max_iterations` (number): 最大迭代轮数。safe 模式默认：8
- `max_minutes` (number): 最大运行分钟数。safe 模式默认：25
- `max_same_output` (number): 输出重复多少次停止（防卡死）。safe 模式默认：2
- `mode` (string): 运行模式：safe（安全模式，默认）、normal（普通模式）。安全模式包含多重保护机制
- `test_command` (string): 每轮执行的测试命令。默认：'npm test'（会在首轮由 agent 识别正确命令）

### `interview` (~160 tokens)

当用户需求不明确、需要澄清需求时使用。需求访谈工具，在开发前通过结构化提问澄清需求，避免理解偏差和返工；生成访谈记录文件供后续 start_feature/add_feature 使用；仅支持 feature 类型

Input parameters:

- `answers` (object): 访谈问题的回答（JSON 对象，key 为问题 ID，value 为回答内容）。用于提交访谈结果
- `description` (string): 功能描述（如'实现用户登录功能'），用于开始访谈。可以是简短的自然语言描述
- `feature_name` (string): 功能名称（kebab-case 格式，如 user-login）。可选，会自动从描述中提取

### `ask_user` (~137 tokens)

当 AI 需要更多信息、遇到不确定因素时使用。向用户提问工具，AI 可主动向用户提问；支持单个或多个问题、提供选项、标注重要性；可在任何时候使用

Input parameters:

- `context` (string): 问题的背景信息或上下文
- `question` (string): 单个问题（如'你希望支持哪些支付方式？'）
- `questions` (array): 多个问题列表，每个问题可包含 question、context、options、required 字段
- `reason` (string): 为什么要问这个问题（提问原因）

### `ui_design_system` (~352 tokens)

智能设计系统生成器 - 基于产品类型和需求，使用 AI 推理引擎生成完整的设计系统推荐。包括 UI 风格、配色方案、字体配对、落地页模式、效果建议、反模式警告和交付检查清单。输出 Markdown 文档、JSON 配置和完整设计规范文档集。

Input parameters:

- `description` (string): 系统说明（推荐）：详细描述产品功能、特点、使用场景。例如：'政府类网站，需要权威、可信、易用的设计风格，面向公众提供政务服务'。这将帮助推理引擎生成更准确的设计方案。
- `keywords` (string): 关键词（可选）：逗号分隔的关键词，如 'professional, modern, trustworthy, authoritative'（专业、现代、可信、权威）。用于辅助匹配设计风格。
- `product_type` (string, required): 产品类型（必填）：SaaS, E-commerce, Healthcare, Fintech, Government（政府）, Education（教育）, Portfolio, Agency 等。这是推理引擎的核心输入。
- `stack` (string): 技术栈（推荐）：react, vue, nextjs, nuxtjs, tailwind, html, svelte, astro 等。用于生成特定技术栈的实现建议和配置代码。
- `target_audience` (string): 目标用户（可选）：如 'B2B企业', 'C端消费者', '政府公务员', '普通市民', '开发者' 等。帮助推理引擎选择合适的设计风格。

### `ui_search` (~280 tokens)

搜索 UI/UX 数据库，包括颜色、图标、图表、组件、设计模式，以及 shadcn/ui blocks、UI 主题预设（CSS variables）、Vercel Web Interface Guidelines 等。支持 search / catalog / template 三种模式。

Input parameters:

- `category` (string): 数据类别（search 模式）：colors、icons、charts、landing、products、typography、styles、ux-guidelines、shadcn-blocks、shadcn-components、ui-themes、ui-guidelines-vercel 等
- `limit` (number): 返回结果数量（默认 10，范围 1-50）
- `min_score` (number): 最小相关性得分（默认 0，范围 0-100）
- `mode` (string): 搜索模式：search（搜索 UI/UX 数据，默认）、catalog（查看组件目录）、template（搜索 UI 模板）
- `query` (string): 搜索关键词（支持中英文，如 'button'、'按钮'、'primary color'、'主色调'）。catalog 模式不需要此参数。
- `stack` (string): 技术栈过滤（仅 search 模式）：react、vue、nextjs、nuxtjs、svelte、astro、flutter、react-native、swiftui、jetpack-compose 等

### `sync_ui_data` (~82 tokens)

同步 UI/UX 数据到本地缓存。来源：uipro-cli、shadcn/ui registry、内嵌 UI 主题预设、Vercel Web Interface Guidelines。

Input parameters:

- `force` (boolean): 是否强制同步（忽略版本检查，默认 false）
- `verbose` (boolean): 是否显示详细日志（默认 false）

### `start_ui` (~315 tokens)

统一 UI 开发编排工具 - 一键完成整个 UI 开发流程。自动检查设计系统、生成组件目录、搜索/生成模板、渲染最终代码。适合快速原型开发，保证整个项目样式统一。

Input parameters:

- `description` (string, required): UI 需求描述（如 '登录页面'、'用户列表'、'设置页面'）
- `framework` (string): 目标框架：react、vue、html（默认 react）
- `loop_assumption_cap` (number): 每轮假设上限（默认 3）
- `loop_max_rounds` (number): 需求 loop 最大轮次（默认 2）
- `loop_question_budget` (number): 每轮最多提问数量（默认 5）
- `mode` (string): 执行模式：auto（智能）/ manual（默认）
- `project_root` (string): 项目根目录绝对路径。建议显式传入；如果存在 docs 或模板等相对路径解析，应统一相对该项目根目录处理，避免依赖客户端 cwd。
- `requirements_mode` (string): 需求模式：steady（默认）或 loop（需求澄清与补全）
- `template` (string): 模板名称（可选，不提供则自动生成）
- `template_profile` (string): 模板档位：auto（默认，自动选择 guided/strict）、guided（普通模型友好）或 strict（结构更紧凑）

### `start_product` (~296 tokens)

产品设计完整工作流编排。一键完成从需求到 HTML 原型的全流程：生成 PRD → 生成原型文档 → 生成设计系统 → 生成 HTML 可交互原型 → 更新项目上下文。生成的 HTML 原型可以直接在浏览器中查看和演示。

Input parameters:

- `description` (string): 产品描述。详细描述产品的目标、功能、用户需求等信息。这是整个工作流的基础输入。如果提供了 requirements_file，此参数可选。
- `docs_dir` (string): 文档输出目录（可选）。默认为 'docs'。所有文档将保存到此目录下的子目录中。
- `product_name` (string): 产品名称（可选）。如果不提供，将使用默认名称'新产品'。
- `product_type` (string): 产品类型（可选）。用于生成设计系统，如 'SaaS'、'E-commerce'、'Healthcare' 等。默认为 'SaaS'。
- `requirements_file` (string): 需求文档文件路径（可选）。如果提供，将读取该文件的完整内容作为产品需求。支持 Markdown、文本等格式。例如：'docs/requirements.md'、'project.md'。
- `skip_design_system` (boolean): 跳过设计系统生成（可选）。默认为 false。如果设置为 true，将不生成设计系统。

### `search_memory` (~122 tokens)

按语义检索共享记忆库。适合在 start_* 之外主动查找历史 Bug 修复或可复用模式；命中后用 read_memory_asset 读取全文。

Input parameters:

- `limit` (number): 返回条数，默认 MEMORY_SEARCH_LIMIT
- `query` (string, required): 检索 query（现象、报错、关键词、功能描述等）
- `tags` (array): 优先匹配的标签
- `type` (string): 优先匹配的资产类型，如 bugfix、pattern、component

### `read_memory_asset` (~60 tokens)

当编排阶段已检索到记忆摘要，且 AI 需要查看完整沉淀代码或详细规范时使用。根据 asset_id 读取记忆资产详情。

Input parameters:

- `asset_id` (string, required): 记忆资产 ID

### `memorize_asset` (~281 tokens)

沉淀可检索资产到共享记忆库。Bug 修复后必须 type=bugfix，content 含【现象】【根因】【修复】【验证】。跨仓库共享时勿填 source_project/source_path，路径写入 content 即可。

Input parameters:

- `code_snippet` (string): 代码片段，content 的别名
- `confidence` (number): 置信度，0-1
- `content` (string): 完整内容（bugfix 建议结构化四段）
- `description` (string, required): 资产描述
- `file_path` (string): 已废弃：勿用于跨仓库沉淀，路径写入 content
- `name` (string, required): 资产名称
- `source_path` (string): 已废弃：仅同仓库追溯时可选
- `source_project` (string): 已废弃：仅同仓库追溯时可选
- `summary` (string, required): 检索用一句话摘要（关键词 + 根因/要点）
- `tags` (array): 标签列表，如 bugfix, root-cause
- `type` (string): 资产类型：bugfix / pattern / component / code 等
- `usage` (string): 适用场景/使用方式

### `delete_memory_asset` (~104 tokens)

按 asset_id 从共享记忆库删除一条资产。适用于过时、错误或重复沉淀的清理；删除前建议先用 read_memory_asset 确认内容。

Input parameters:

- `asset_id` (string, required): 要删除的记忆资产 ID（通常来自 search_memory 或 read_memory_asset）
- `confirm` (boolean): 为 true 时执行删除；省略或 false 时仅返回预览并要求确认（软确认）

### `update_memory_asset` (~264 tokens)

按 asset_id 更新共享记忆库中的已有资产（保留原 ID）。适用于修正摘要、正文或标签；content 变更会重新向量化。跨仓库共享时勿填 source_project/source_path。

Input parameters:

- `asset_id` (string, required): 要更新的记忆资产 ID
- `code_snippet` (string): 代码片段，content 的别名
- `confidence` (number): 置信度，0-1
- `content` (string): 完整内容
- `description` (string): 资产描述
- `file_path` (string): 已废弃：勿用于跨仓库沉淀，路径写入 content
- `name` (string): 资产名称
- `source_path` (string): 已废弃：仅同仓库追溯时可选
- `source_project` (string): 已废弃：仅同仓库追溯时可选
- `summary` (string): 检索用一句话摘要
- `tags` (array): 标签列表
- `type` (string): 资产类型：bugfix / pattern / component / code 等
- `usage` (string): 适用场景/使用方式

### `scan_and_extract_patterns` (~368 tokens)

当需要从单段代码、单文件或整个目录中抽取可复用模式，再决定是否沉淀到记忆系统时使用。目录扫描时，优先传 `project_root` 为项目根目录绝对路径，并让 `directory_path` 传相对项目根的路径，例如 `app/utils`；只有无法确定项目根时，才把 `directory_path` 直接设为绝对路径。不要传带项目名的半相对路径，例如 `font-miniapp-api/app/utils`。

Input parameters:

- `content` (string): 待分析的代码或文本内容。传入该字段时走单段分析模式
- `directory_path` (string): 要扫描的目录路径。最佳实践是传相对 `project_root` 的路径，例如 `app/utils`；如果拿不到 `project_root`，才传目录绝对路径。不要传带项目名的半相对路径，例如 `font-miniapp-api/app/utils`。
- `file_path` (string): 来源文件路径。单段分析时作为来源路径使用
- `include_extensions` (array): 允许扫描的文件扩展名列表，例如 [".ts", ".tsx", ".py"]
- `max_files` (number): 最多扫描多少个文件，默认 30，最大 200
- `max_patterns` (number): 最多返回多少个候选模式，默认 20，最大 100
- `project_name` (string): 已废弃，扫描结果不再写入 source_project
- `project_root` (string): 项目根目录绝对路径。目录扫描时建议始终传入；传入后，`directory_path` 应写成相对项目根的路径。

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/mybolide-mcp-probe-kit/mcp-probe-kit#diagnostics

## Score history

- 2026-08-03: 65
- 2026-08-02: 64
- 2026-08-01: 29
- 2026-07-31: 24
- 2026-07-30: 51
- 2026-07-28: 51
- 2026-07-27: 51

## Links

- npm package: https://www.npmjs.com/package/mcp-probe-kit
- Socket report: https://socket.dev/npm/package/mcp-probe-kit
- Repository: https://github.com/mybolide/mcp-probe-kit
- Changelog RSS feed: https://verifymcp.io/servers/mybolide-mcp-probe-kit/mcp-probe-kit/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/mybolide-mcp-probe-kit/mcp-probe-kit/changelog.json
- HTML version of this page: https://verifymcp.io/servers/mybolide-mcp-probe-kit/mcp-probe-kit