io.github.mybolide/mcp-probe-kit
NPM · MCP-PROBE-KIT · SCANNED SEP 21
Spec-driven dev workflow MCP: start_* orchestration, memory, GitNexus, quality gates.
Available components
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. How we score → Why this is hard to score →
Supply Chain Security89
- No malware found by supply-chain analysis.Pass
- CVE check failed: a known medium-severity CVE affects csv-parse 6.2.1, a direct dependency. A fixed version is available. View diagnostics → Fail
- No install/post-install scripts declared.Pass
- 6 of 22 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to mybolide/mcp-probe-kit). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 31 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability75
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 6710 tokens (~258/item across 26 items; 24 tools + 2 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management90
- Stability observed for 27 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage96
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 89% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 24 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 25 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
How do I install the io.github.mybolide/mcp-probe-kit server?
io.github.mybolide/mcp-probe-kit runs locally as an npm package, launched with npx -y mcp-probe-kit. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · mcp-probe-kit
claude mcp add mybolide-mcp-probe-kit -- npx -y mcp-probe-kit
{
"mcpServers": {
"mybolide-mcp-probe-kit": {
"command": "npx",
"args": [
"-y",
"mcp-probe-kit"
]
}
}
} {
"servers": {
"mybolide-mcp-probe-kit": {
"command": "npx",
"args": [
"-y",
"mcp-probe-kit"
]
}
}
} codex mcp add mybolide-mcp-probe-kit -- npx -y mcp-probe-kit
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"mybolide-mcp-probe-kit": {
"type": "local",
"command": [
"npx",
"-y",
"mcp-probe-kit"
],
"enabled": true
}
}
} openclaw mcp add mybolide-mcp-probe-kit --command npx --arg -y --arg mcp-probe-kit
mcp_servers:
mybolide-mcp-probe-kit:
command: "npx"
args: ["-y", "mcp-probe-kit"] {
"McpServers": {
"mybolide-mcp-probe-kit": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"mcp-probe-kit"
]
}
}
} assistant mcp add mybolide-mcp-probe-kit -t stdio -c npx -a -y mcp-probe-kit
{
"mcpServers": {
"mybolide-mcp-probe-kit": {
"command": "npx",
"args": [
"-y",
"mcp-probe-kit"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 21 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Sept 26 −3
- Stability: pass → 0.80 functional
- 17 Sept 26 0
- Stability: 0.97 → pass security
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Sept 26 −3
- Stability: pass → 0.80 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed npm/mcp-probe-kit@4.0.0
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | npm |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | mybolide/mcp-probe-kit |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/mybolide/mcp-probe-kit/.github/workflows/release.yml@refs/tags/v4.0.0 |
| Rekor log index | 2418438283 |
| Predicate type | https://slsa.dev/provenance/v1 |
| Subject digest | sha512:a7c65ecbeefe07778cdfebf397da0fb6439d0828c0ea0730c98f75000f86e8f4d73a85d0cc41cfa5b75f02a1390041bc0277def7687de97d63fc9400b |
Background: How many MCP packages publish verified provenance →
Vulnerabilities 1 finding
| ID | CVE | Severity | Vector | Fix available |
|---|---|---|---|---|
| GHSA-8cw4-87c7-c6xx | CVE-2026-85063 | medium | yes |
Background: What a vulnerability scan can and cannot prove →
Dependencies 22 packages
| Packages resolved | 22 |
|---|---|
| Stale | 6 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
architecture ~431
独立架构领域能力，使用 ARC-8 完成架构评估、设计、校验和漂移检查。可直接调用，也可由功能、Bug 或重构流程按需组合；MCP 负责方法、门禁与结构化证据，不替 Agent 声称绝对最优架构。
| Name | Type | Req | Description |
|---|---|---|---|
| alternatives | array | – | – |
| baseline | – | – | 已有 assess 结果、ADR、ArchitectureCandidate、Plan 或设计证据；可传对象或 JSON/文本 |
| collect_evidence | boolean | – | 是否自动调用 code_insight 并召回 Memory 证据，默认 true；测试或已提供完整证据时可设 false |
| constraints | array | – | 已确认的业务与技术约束 |
| current_facts | array | – | 当前架构事实，需标记 fact/inference/unknown |
| decision | object | – | – |
| description | string | yes | 本次架构任务的完整目标，不能只传“继续”或“优化架构” |
| diff | string | – | validate/drift 使用的真实 Git diff、revision 摘要或实现证据 |
| mode | string | – | ARC-8 入口阶段：assess、design、validate 或 drift，默认 assess |
| non_goals | array | – | 本次明确不处理的内容 |
| observed_drift | array | – | Agent 已确认的架构偏移事实 |
| project_root | string | – | 目标项目根目录绝对路径 |
| protected_invariants | array | – | – |
| runtime_evidence | array | – | 运行结果、图谱摘要、日志、指标或验收证据 |
| save_to_docs | boolean | – | 是否返回架构文档 delegated 落盘计划；工具本身不直接重写项目文档 |
| scope | array | – | 涉及模块、目录、服务或数据域 |
| structural_causes | array | – | – |
| target_architecture | object | – | – |
| transition_plan | object | – | – |
No output schema declared.
No examples provided.
check_spec ~182
校验已落盘的功能规格（docs/specs/<feature_name>/requirements|design|tasks.md）是否完整：检测残留 [填写] 占位、缺失章节、缺 FR/验收标准、FR 未进覆盖矩阵。写完规格后、进入实现前调用；未通过按报告补全后重跑。
| Name | Type | Req | Description |
|---|---|---|---|
| docs_dir | string | – | 文档根目录，默认为 docs |
| feature_name | string | – | 要校验的规格目录名，对应 docs/specs/<feature_name>/ |
| project_root | string | – | 可选。项目根目录绝对路径；未传时自动从 MCP 客户端工作区解析（如 Cursor 注入 WORKSPACE_FOLDER_PATHS、OpenCode/客户端配置的 cwd 等）。仅边缘场景需手动传入。 |
No output schema declared.
No examples provided.
code_insight ~253
当用户需要基于代码图谱分析调用链、上下文和影响面时使用。默认桥接 GitNexus，支持 query/context/impact 模式；不可用时自动降级并返回原因
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | – | 任务上下文（可选） |
No output schema declared.
No examples provided.
code_review ~363
当用户需要审查代码、真实 Git diff 或托管 Plan 的交付一致性时使用。MCP 可确定性收集 changed files、Plan 声明范围、产物、测试、公共契约、架构和 revision 证据；代码语义问题仍由 Agent 审查，不伪装成静态扫描器
| Name | Type | Req | Description |
|---|---|---|---|
| base_ref | string | – | diff_mode=range 时的基线 Git ref |
| code | string | – | 要审查的代码。可以是代码片段、完整文件或 git diff 输出 |
| diff_mode | string | – | Git diff 范围。auto 默认审查相对 HEAD 的 staged+unstaged 变更；working 仅未暂存；staged 仅已暂存；range 使用 base_ref/head_ref |
| file_path | string | – | 要审查的文件路径（相对 project_root 或绝对路径）。未传 code 时从磁盘读取 |
| focus | string | – | 审查重点：security（安全）、performance（性能）、quality（质量）、all（全部）。可选，默认 all |
| head_ref | string | – | diff_mode=range 时的目标 Git ref |
| max_diff_chars | number | – | 最大 diff 字符数，1000-500000，默认 120000。超出时明确标记 truncated |
| plan_id | string | – | 可选托管 Plan ID。提供后读取 Plan 状态并比较 declaredScope、产物、测试、架构证据和 revision |
| project_root | string | – | 项目根目录绝对路径。未传 code/file_path 时，可从该 Git 仓库自动收集真实 diff |
No output schema declared.
No examples provided.
converge ~170
按 Delegated Plan 自己声明的证据和质量闸门关闭计划。任一未完成步骤、未决事项、必需证据或验收结果缺失都会拒绝收敛；除 requirements 外，证据只有摘要但没有 reference/revision 也不算可复核证据。调用参数只能增加证据要求，不能削弱 Plan。
| Name | Type | Req | Description |
|---|---|---|---|
| docs_dir | string | – | 规格目录，默认 docs |
| feature_name | string | – | 可选；提供后 converge 会真实调用 check_spec |
| plan_id | string | yes | – |
| project_root | string | – | – |
| required_evidence_kinds | array | – | 可选附加要求；与 Plan.requiredEvidenceKinds 合并，不能移除 Plan 已声明要求 |
No output schema declared.
No examples provided.
estimate ~163
当用户需要估算开发工作量、评估任务时间时使用。估算开发工作量，输出故事点、时间范围（乐观/正常/悲观）、风险点
| Name | Type | Req | Description |
|---|---|---|---|
| code_context | string | – | 相关代码或文件上下文。可选，有助于更准确的估算 |
| experience_level | string | – | 经验水平：junior（初级）、mid（中级）、senior（高级）。可选，默认为 mid |
| task_description | string | – | 任务描述。可以是简短的自然语言（如'估算开发工作量'）或详细的任务说明 |
| team_size | integer | – | 团队规模（人数）。可选，默认为 1 |
No output schema declared.
No examples provided.
gencommit ~187
当用户需要生成 Git commit 消息时使用。返回 Conventional Commits 规范说明、步骤、输出模板和示例，供 AI 根据变更内容生成最终 commit message。它不直接代写最终消息，也不应被判定为空结果
| Name | Type | Req | Description |
|---|---|---|---|
| changes | string | – | 代码变更内容。可以是 git diff 输出、变更描述或自然语言。如果不提供，工具会提示执行 git diff |
| project_root | string | – | 可选，目标 Git 仓库根目录或其子目录。未提供 changes 时用于确认当前项目确实是 Git 仓库 |
| type | string | – | Commit 类型：fixed（修复）、feat（新功能）、docs（文档）、style（样式）、chore（杂项）、refactor（重构）、test（测试）。可选，会自动识别 |
No output schema declared.
No examples provided.
gentest ~160
当用户需要为代码生成单元测试时使用。指南型工具：注入 code/file_path 与测试清单，由 Agent 生成完整测试代码；MCP 不自动生成或运行测试
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | – | 要生成测试的代码。可以是函数、类或模块 |
| file_path | string | – | 要生成测试的源文件路径（相对 project_root 或绝对路径）。未传 code 时从磁盘读取 |
| framework | string | – | 测试框架：jest、vitest、mocha。可选，会自动识别项目使用的框架 |
| project_root | string | – | 项目根目录绝对路径。配合 file_path 解析相对路径 |
No output schema declared.
No examples provided.
git_work_report ~294
基于 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
| Name | Type | Req | Description |
|---|---|---|---|
| date | string | – | 单个日期，格式 YYYY-MM-DD（日报模式） |
| end_date | string | – | 结束日期，格式 YYYY-MM-DD（周期报模式） |
| output_file | string | – | 可选，输出文件路径 |
| project_root | string | – | 目标 Git 仓库根目录或其子目录；省略时按当前 MCP 工作区解析 |
| start_date | string | – | 起始日期，格式 YYYY-MM-DD（周期报模式） |
No output schema declared.
No examples provided.
init_project ~241
当用户提供一句话需求时使用。基于 Spec-Driven Development 理念，分析需求并生成完整的项目规格文档（需求分析/技术设计/任务拆解）。适合项目初期的需求澄清和规划
| Name | Type | Req | Description |
|---|---|---|---|
| input | string | – | 项目需求描述。可以是一句话需求（如'创建电商网站'）或简短的功能描述，工具会自动分析并生成详细的规格文档 |
| project_name | string | – | 项目名称。可选，默认为'新项目' |
| project_root | string | – | 可选。项目根目录绝对路径；未传时自动从 MCP 客户端工作区解析（如 Cursor 注入 WORKSPACE_FOLDER_PATHS、OpenCode/客户端配置的 cwd 等）。仅边缘场景需手动传入。 init_project 是新项目初始化入口：显式传入尚不存在的绝对路径时，会创建该目录并仅写入 MCP 托管的 Skill、AGENTS.md 与 CLI fallback 文件；文件系统根… |
No output schema declared.
No examples provided.
init_project_context ~204
生成/更新项目上下文写作计划（delegated）：MCP 写入 AGENTS.md 与 layout.json；project-context 分类文档与 graph-insights 由 Agent 按返回的 plan 落盘。新功能请先 start_feature，修 bug 请先 start_bugfix。
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
No output schema declared.
No examples provided.
interview ~160
当用户需求不明确、需要澄清需求时使用。需求访谈工具，在开发前通过结构化提问澄清需求，避免理解偏差和返工；生成访谈记录文件供后续 start_feature/add_feature 使用；仅支持 feature 类型
| Name | Type | Req | Description |
|---|---|---|---|
| answers | object | – | 访谈问题的回答（JSON 对象，key 为问题 ID，value 为回答内容）。用于提交访谈结果 |
| description | string | – | 功能描述（如'实现用户登录功能'），用于开始访谈。可以是简短的自然语言描述 |
| feature_name | string | – | 功能名称（kebab-case 格式，如 user-login）。可选，会自动从描述中提取 |
No output schema declared.
No examples provided.
plan_heartbeat ~280
由 Agent 在 Delegated Plan 执行过程中记录轻量检查点。首次调用必须提供完整 plan；后续合并步骤、证据、产物、候选经验、验收结果、运行证据和 revision。除 requirements 外，每条用于收敛的 evidence 必须至少提供 reference 或 revision，否则 converge 会明确拒绝。只记录状态，不代替 Agent 执行。
| Name | Type | Req | Description |
|---|---|---|---|
| acceptance_results | array | – | – |
| architecture_candidates | array | – | – |
| artifacts | array | – | – |
| completed_step_ids | array | – | – |
| current_step_id | string | – | – |
| declared_scope | object | – | 本次 Plan 已确认的目录、模块、契约、排除项等作用域；省略时保留原值 |
| evidence | array | – | – |
| last_verified_revision | string | – | – |
| memory_candidates | array | – | – |
| plan | object | – | 首次 heartbeat 必填的完整 Delegated Plan Contract |
| plan_id | string | yes | Delegated Plan 的稳定 planId |
| project_root | string | – | 项目根目录；省略时按工作区解析 |
| runtime_evidence | array | – | – |
| skipped_steps | array | – | – |
| status | string | – | – |
| unresolved_items | array | – | – |
No output schema declared.
No examples provided.
refactor ~156
当用户需要重构代码、改善代码结构时使用。指南型工具：注入 code/file_path 与重构清单，由 Agent 分析后输出重构计划 JSON；MCP 不自动修改源文件
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | – | 要重构的代码 |
| file_path | string | – | 要重构的文件路径（相对 project_root 或绝对路径）。未传 code 时从磁盘读取 |
| goal | string | – | 重构目标：improve_readability（可读性）、reduce_complexity（复杂度）、performance（性能）。可选 |
| project_root | string | – | 项目根目录绝对路径。配合 file_path 解析相对路径 |
No output schema declared.
No examples provided.
resume_plan ~139
从 .mcp-probe-kit/plans/ 读取 Delegated Plan 检查点，按依赖计算下一可执行步骤、阻塞步骤和 resumeContext。plan_id 可选；省略时自动恢复当前项目最近更新的 active/blocked Plan。本工具只读取状态，不替 Agent 执行；返回 mustContinue=true 后 Agent 必须立即执行 nextStep/nextTool，逐步调用 plan_heartbeat，禁止只汇报恢复结果后停止。
| Name | Type | Req | Description |
|---|---|---|---|
| plan_id | string | – | 可选；省略时选择当前项目最近更新的 active/blocked Plan |
| project_root | string | – | – |
No output schema declared.
No examples provided.
start_bugfix ~390
当用户需要找问题、修 bug、排查异常时使用。默认按 SRC-8（TBP-inspired）编排：收敛边界→真因工作表→修复→测试→记忆沉淀。
| Name | Type | Req | Description |
|---|---|---|---|
| analysis_mode | string | – | 分析方法。默认 src8；tbp8 为兼容别名 |
| code_context | string | – | 相关代码。可选 |
| description | string | – | Bug 描述（与 error_message 同义；仅传 description 时自动作为错误信息） |
| docs_dir | string | – | 文档目录。可选，默认 docs |
| error_message | string | – | 错误信息（可与 description 二选一） |
| 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（结构更紧凑） |
No output schema declared.
No examples provided.
start_feature ~464
新功能、功能增强、大版本升级或跨模块研发的首选入口。Agent 必须把当前对话已确认的完整目标、范围、模块、阶段和约束汇总到 description；用户只说“继续/开始/往下做”时不得原样透传。默认 spec_layout=auto，复杂多模块或多阶段需求会先生成 parent-child 子规格拆分计划，再进入 add_feature→check_spec→实现。仅在规格布局和子规格已明确、且只需渲染规格模板时才直接用 add_feature。
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | – | 功能详细描述。应汇总当前对话已经确认的完整范围、模块、阶段和约束，不要只传最后一句简短确认；该字段也用于自动判断 flat / parent-child。 |
| 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（需求澄清与补全） |
| spec_layout | string | – | 规格布局：auto（默认，复杂多模块需求自动选择 parent-child）、flat 或 parent-child。显式值优先于自动判断。 |
| subspecs | array | – | parent-child 的子规格定义；每项包含 id、title、fr 和可选 dependsOn |
| template_profile | string | – | 模板档位：auto（默认，自动选择 guided/strict）、guided（普通模型友好）或 strict（结构更紧凑） |
No output schema declared.
No examples provided.
start_onboard ~86
当用户需要快速上手新项目时使用。编排���生成上下文文档。
| Name | Type | Req | Description |
|---|---|---|---|
| docs_dir | string | – | 文档目录。可选，默认 docs |
| project_path | string | – | 项目根目录绝对路径。建议显式传入；如果还传 docs_dir 等相对路径，应统一相对该项目根目录解析。 |
No output schema declared.
No examples provided.
start_product ~424
产品设计完整工作流入口。返回闭环 delegated plan：Agent 生成 PRD 与原型文档，调用 ui_design_system 和 start_ui 完成设计系统及可交互 HTML 原型，并更新项目上下文；不会引用不存在的 gen_prd/gen_prototype 工具。
| Name | Type | Req | Description |
|---|---|---|---|
| constraints | string | – | 核心约束（可选）。多个约束建议用分号分隔。未提供时会尝试从 description 的“核心约束：”或“约束：”段落提取。 |
| description | string | – | 产品描述。详细描述产品的目标、功能、用户需求等信息。这是整个工作流的基础输入。如果提供了 requirements_file，此参数可选。 |
| docs_dir | string | – | 文档输出目录（可选）。默认为 'docs'。所有文档将保存到此目录下的子目录中。 |
| product_name | string | – | 产品名称（可选）。如果不提供，将使用默认名称'新产品'。 |
| product_type | string | – | 产品类型（可选）。用于生成设计系统，如 'SaaS'、'E-commerce'、'Healthcare' 等。默认为 'SaaS'。 |
| project_root | string | – | 目标项目根目录绝对路径。建议显式传入，避免文档和 Skill 写入 MCP 包安装目录。 |
| requirements_file | string | – | 需求文档文件路径（可选）。如果提供，将读取该文件的完整内容作为产品需求。支持 Markdown、文本等格式。例如：'docs/requirements.md'、'project.md'。 |
| skip_design_system | boolean | – | 跳过设计系统生成（可选）。默认为 false。如果设置为 true，将不生成设计系统。 |
| target_users | string | – | 目标用户（可选）。例如：TypeScript 项目维护者、企业管理员、普通消费者。未提供时会尝试从 description 的“目标用户：”段落提取。 |
No output schema declared.
No examples provided.
start_ralph ~444
用于需要多轮小步实现、每轮真实验证和正式收敛的长任务。返回有界 Delegated Plan、每轮 Heartbeat 证据契约和可选前台辅助脚本；不自动运行循环、不创建后台进程。安全停止不等于成功
| Name | Type | Req | Description |
|---|---|---|---|
| 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_rounds | number | – | max_iterations 的兼容别名；建议新调用统一使用 max_iterations |
| max_same_output | number | – | 输出重复多少次停止（防卡死）。safe 模式默认：2 |
| mode | string | – | 运行模式：safe（安全模式，默认）、normal（普通模式）。安全模式包含多重保护机制 |
| project_root | string | – | 目标项目根目录绝对路径。省略时从当前已确认工作区解析 |
| test_command | string | – | 每轮执行的测试命令。默认：'npm test'（会在首轮由 agent 识别正确命令） |
No output schema declared.
No examples provided.
start_ui ~504
编排 UI 设计与实现：先锁定视觉方向和信息架构，再生成关键页面，后续通过真实截图评分与迭代完成验收。
| Name | Type | Req | Description |
|---|---|---|---|
| avoid | string | – | 项目特定禁用项，使用逗号分隔。 |
| brand_personality | string | – | 品牌气质，使用逗号分隔，如 精准、可信、克制。 |
| density | string | – | 内容密度。 |
| description | string | yes | 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。 |
| references | string | – | 参考产品或方法，使用逗号分隔，如 Linear、Apple。 |
| requirements_mode | string | – | 需求模式：steady（默认）或 loop（需求澄清与补全） |
| review_max_rounds | number | – | 截图评审未达标时的最大迭代轮次。每轮必须重新生成真实截图并评分。 |
| screen_type | string | – | 页面类型，如 professional-dashboard、workflow-console、marketing-page。未传时自动判断。 |
| target_audience | string | – | 目标用户及其专业程度、使用频率和主要压力。 |
| target_score | number | – | 截图视觉验收目标分数。 |
| template | string | – | 模板名称（可选，不提供则自动生成） |
| template_profile | string | – | 模板档位：auto（默认，自动选择 guided/strict）、guided（普通模型友好）或 strict（结构更紧凑） |
| visual_direction | string | – | 视觉方向名称。可使用内置方向或自定义方向。 |
No output schema declared.
No examples provided.
ui_design_system ~407
生成可执行的视觉方向，而不是风格标签拼盘。输出核心任务、信息架构、内容密度、排版与色彩策略、组件原则、明确禁用项和截图验收标准。
| Name | Type | Req | Description |
|---|---|---|---|
| avoid | – | – | 项目特定禁用项，如 卡片瀑布、大标题、装饰性图标、大面积空白。 |
| brand_personality | – | – | 品牌气质，如 精准、可信、克制。字符串可用逗号分隔。 |
| density | string | – | 内容密度。专业后台通常 compact，通用产品 comfortable，营销页 spacious。 |
| description | string | – | 页面或产品的核心任务、关键内容和使用场景。不要只写视觉形容词。 |
| keywords | string | – | 兼容旧调用方。等价于 brand_personality，后续应改用 brand_personality。 |
| product_type | string | yes | 产品类型，如 SaaS、交易系统、医疗应用、电商或品牌官网。 |
| references | – | – | 参考产品或设计方法，如 Linear、Apple、Vercel。只提取结构方法，不照抄视觉。 |
| screen_type | string | – | 页面类型，如 professional-dashboard、workflow-console、marketing-page、commerce-catalog、commerce-detail、content-workspace。未传时自动判断。 |
| stack | string | – | 技术栈，如 react、nextjs、vue、nuxt、html。仅影响实现建议，不决定审美。 |
| target_audience | string | – | 目标用户及其专业程度、使用频率和主要压力。 |
| target_score | number | – | 视觉验收目标分数。低于该分数不得交付。 |
| visual_direction | string | – | 指定视觉方向。内置方向包括 editorial-precision、operational-clarity、calm-trust、product-storytelling、commerce-focus，也支持自定义名称。 |
No output schema declared.
No examples provided.
ui_search ~265
搜索页面结构、组件、交互规范和实现参考。新 UI 流程优先使用 structure 模式按任务和页面类型选择信息架构；旧 search/catalog/template 模式继续兼容。
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | – | search 模式数据类别：colors、icons、charts、landing、products、typography、styles、ux-guidelines、shadcn-blocks、shadcn-components、ui-themes、ui-guidelines-vercel。 |
| density | string | – | structure 模式的目标内容密度。 |
| limit | number | – | 返回结果数量。structure 模式默认 3、最多 5；其他模式默认 10、最多 50。 |
| min_score | number | – | search 模式最小相关性得分。 |
| mode | string | – | structure（页面结构，推荐）、search（通用数据）、catalog（组件目录）、template（旧模板兼容）。 |
| query | string | – | 核心任务或搜索关键词。structure 模式应描述用户要完成的任务。 |
| screen_type | string | – | structure 模式的页面类型，如 professional-dashboard、workflow-console、marketing-page、commerce-catalog。 |
| stack | string | – | search 模式技术栈过滤。 |
No output schema declared.
No examples provided.
workflow ~294
仅当 Agent 阅读 Skill 和各工具 description 后仍不确定该调用哪个 MCP 时使用的兜底选择指南。workflow 不做自然语言意图识别：scenario=auto（默认）只返回工具选择规则与速查表，不从 intent 猜 firstTool；Agent 根据完整对话自行判断或澄清。若 Agent 已明确场景，可传显式 scenario 获取该场景的确定性 firstTool、phases 和参数提示。同时确保用户项目已存在 .agents/skills/mcp-probe-kit/SKILL.md 与 AGENTS.md 中的 Skill 引用（缺失则自动创建/更新）。
| Name | Type | Req | Description |
|---|---|---|---|
| intent | string | – | 可选上下文摘要。scenario=auto 时仅供指南展示，不参与自动分类；显式 scenario 时用于生成该场景的参数提示和阶段说明。 |
| project_root | string | – | 可选。项目根目录绝对路径；未传时自动从 MCP 客户端工作区解析（如 Cursor 注入 WORKSPACE_FOLDER_PATHS、OpenCode/客户端配置的 cwd 等）。仅边缘场景需手动传入。 |
| scenario | string | – | 可选：显式场景。默认 auto 只返回 Agent 工具选择指南，不从 intent 推断场景；Agent 已确定场景时传 feature/bugfix/ui/... 获取确定性流程说明 |
No output schema declared.
No examples provided.
What is the io.github.mybolide/mcp-probe-kit server?
io.github.mybolide/mcp-probe-kit is listed in the public MCP registry as io.github.mybolide/mcp-probe-kit. Spec-driven dev workflow MCP: start_* orchestration, memory, GitNexus, quality gates. This page covers its npm package (mcp-probe-kit).
Is the io.github.mybolide/mcp-probe-kit server safe to use?
io.github.mybolide/mcp-probe-kit scores 90 out of 100 on VerifyMCP. We recorded 1 known advisory against it as of 21 September 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.mybolide/mcp-probe-kit server expose?
io.github.mybolide/mcp-probe-kit exposes 24 tools: init_project, gencommit, git_work_report, code_review, code_insight, and 19 more. Their descriptions and schemas cost roughly 6,661 tokens of context every time the server is loaded.
Is the io.github.mybolide/mcp-probe-kit server still maintained?
io.github.mybolide/mcp-probe-kit is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the io.github.mybolide/mcp-probe-kit server under?
io.github.mybolide/mcp-probe-kit declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.