Skip to main content
Glama
mybolide

MCP Probe Kit

by mybolide
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

start_feature

Read-only

Initiates new feature development by analyzing requirements and generating structured specifications with automatic flat or parent-child layout for complex multi-module projects.

Instructions

新功能、功能增强、大版本升级或跨模块研发的首选入口。Agent 必须把当前对话已确认的完整目标、范围、模块、阶段和约束汇总到 description；用户只说“继续/开始/往下做”时不得原样透传。默认 spec_layout=auto，复杂多模块或多阶段需求会先生成 parent-child 子规格拆分计划，再进入 add_feature→check_spec→实现。仅在规格布局和子规格已明确、且只需渲染规格模板时才直接用 add_feature。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docs_dirNo文档输出目录，默认为 docs
subspecsNoparent-child 的子规格定义；每项包含 id、title、fr 和可选 dependsOn
descriptionNo功能详细描述。应汇总当前对话已经确认的完整范围、模块、阶段和约束，不要只传最后一句简短确认；该字段也用于自动判断 flat / parent-child。
spec_layoutNo规格布局：auto（默认，复杂多模块需求自动选择 parent-child）、flat 或 parent-child。显式值优先于自动判断。
feature_nameNo功能名称（kebab-case 格式，如 user-auth）。可选，如果不提供会从 description 自动提取
project_rootNo项目根目录绝对路径。建议显式传入；docs_dir 等相对路径参数应统一相对该项目根目录解析，避免依赖客户端 cwd。
loop_max_roundsNo需求 loop 最大轮次（默认 2）
template_profileNo模板档位：auto（默认，自动选择 guided/strict）、guided（普通模型友好）或 strict（结构更紧凑）
requirements_modeNo需求模式：steady（默认，直接生成规格）或 loop（需求澄清与补全）
loop_assumption_capNo每轮假设上限（默认 3）
loop_question_budgetNo每轮最多提问数量（默认 5）

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv4.0.0
    • changedInput schema / properties / description / description
      Previous value: -"功能详细描述。可以是简短的自然语言（如'开发用户认证功能'）或详细的需求说明"New value: +"功能详细描述。应汇总当前对话已经确认的完整范围、模块、阶段和约束，不要只传最后一句简短确认；该字段也用于自动判断 flat / parent-child。"
    • changedInput schema / properties / spec_layout / description
      Previous value: -"规格布局：flat（默认）或 parent-child（由 Agent 落盘母/子规格）"New value: +"规格布局：auto（默认，复杂多模块需求自动选择 parent-child）、flat 或 parent-child。显式值优先于自动判断。"
    • changedInput schema / properties / spec_layout / enum
      Previous value: -[
-  "flat",
-  "parent-child"
-]New value: +[
+  "auto",
+  "flat",
+  "parent-child"
+]
  2. Changed5 schema fields changedv3.7.0
    • addedInput schema / properties / docs_dir / maxLength
      Added value: +240
    • addedInput schema / properties / feature_name / maxLength
      Added value: +120
    • addedInput schema / properties / feature_name / pattern
      Added value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"
    • addedInput schema / properties / spec_layout
      Added value: +{
+  "description": "规格布局：flat（默认）或 parent-child（由 Agent 落盘母/子规格）",
+  "enum": [
+    "flat",
+    "parent-child"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / subspecs
      Added value: +{
+  "description": "parent-child 的子规格定义；每项包含 id、title、fr 和可选 dependsOn",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "dependsOn": {
+        "description": "依赖的子规格 ID",
+        "items": {
+          "pattern": "^[a-z0-9]+(?:-[a-z0-9]+)*$",
+          "type": "string"
+        },
+        "maxItems": 50,
+        "type": "array"
+      },
+      "fr": {
+        "description": "负责的 FR-n 列表",
+        "items": {
+          "pattern": "^FR-\\d+$",
+          "type": "string"
+        },
+        "maxItems": 100,
+        "minItems": 1,
+        "type": "array"
+      },
+      "id": {
+        "description": "唯一的小写 kebab-case 子规格 ID",
+        "maxLength": 120,
+        "pattern": "^[a-z0-9]+(?:-[a-z0-9]+)*$",
+        "type": "string"
+      },
+      "title": {
+        "description": "子规格标题",
+        "maxLength": 120,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "title",
+      "fr"
+    ],
+    "type": "object"
+  },
+  "maxItems": 50,
+  "type": "array"
+}
  3. Changed1 schema field changedv3.6.3
    • changedInput schema / properties / project_root / description
      Previous value: -"项目根目录。当前客户端未把工作区作为进程 cwd 传进来时，建议显式指定"New value: +"项目根目录绝对路径。建议显式传入；docs_dir 等相对路径参数应统一相对该项目根目录解析，避免依赖客户端 cwd。"
  4. Addedv3.0.16

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint: true and openWorldHint: true, which might seem contradictory since the tool orchestrates feature creation. The description clarifies its orchestrative, non-destructive nature: it generates specs and plans but doesn't modify code. It adds behavioral detail beyond annotations (e.g., the auto detection of parent-child layout). However, it could be more transparent about exactly what side effects occur (e.g., file creation, project state changes).

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 moderately concise for a tool with many parameters and complex orchestration. It front-loads the essential purpose and usage guidelines. However, it's somewhat dense and could benefit from clear separation of concerns (e.g., bullet points for different behavioral aspects) to improve scannability.

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

Completeness4/5

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

Given the tool's complexity (11 parameters, conditional orchestration, sibling differentiation needs), the description covers core aspects: purpose, when-to-use, orchestration flow, and key parameter semantics. It lacks an output description, but there is no output schema to rely on. It could be more complete by explaining the overall workflow in more detail, but it's adequate for an agent to select and invoke the tool correctly.

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?

Schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining the semantics of description (must summarize confirmed scope, not just pass through user's last confirmation) and spec_layout's auto behavior (complex needs trigger parent-child planning). It also clarifies that feature_name is optional and auto-extracted. However, the description doesn't detail all 11 parameters individually.

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 this is the primary entry point for new features, enhancements, major version upgrades, and cross-module development. It distinguishes itself from siblings like start_bugfix (bug fixes) and start_onboard (onboarding) by its scope and purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: it's the first choice for complex multi-module or multi-phase requirements. It also explicitly states when NOT to use it and what to use instead: '仅在规格布局和子规格已明确、且只需渲染规格模板时才直接用 add_feature.' This is excellent usage guidance.

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