Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Spec Kit UI MCP 我想做一个待办事项应用"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
交互式 MCP 服务器，通过可视化界面收集项目需求，自动生成 Spec Kit 7 条命令。专为 Cursor 编辑器优化。
🎯 智能需求收集 - 通过交互式网页表单收集项目需求
🤖 AI 驱动 - AI 根据描述自动生成针对性问题
📊 多回合对话 - 支持多轮问答，逐步完善需求
🎨 美观界面 - 现代化 UI 设计
📝 自动生成命令 - 基于需求自动生成 7 条 Spec Kit 命令
💾 会话管理 - 自动保存会话历史
Related MCP server: Awesome-MCP-Scaffold
在 Cursor 的设置中配置 MCP 服务器：
打开 Cursor 设置 → MCP → 添加服务器配置：
{
"mcpServers": {
"spec-kit-ui-mcp": {
"command": "npx",
"args": ["-y", "spec-kit-ui-mcp", "--work-dir", "工作目录地址"]
}
}
}配置完成后，重启 Cursor 使 MCP 服务器生效。
在 Cursor 的 AI 对话框中，直接描述你的项目需求：
我想做一个电商网站，包含商品列表、购物车、订单管理功能AI 会自动调用 MCP 工具，引导你完成需求收集并生成 Spec Kit 命令。
第一步：描述项目需求
我想做一个待办事项应用AI 自动执行：
调用 gather 工具收集需求
打开浏览器展示问题配置表单
你填写完成后提交
第二步：AI 分析需求
AI 调用 analyze 工具分析需求是否完整。
如果需求不够明确，AI 会继续问问题（多轮对话）
如果需求明确，AI 继续下一步
第三步：生成 Spec Kit 命令
AI 调用 build 工具生成 7 条命令：
/constitution - 项目原则和开发规范
/specify - 功能规格和用户故事
/clarify - 技术细节澄清
/plan - 技术实现方案
/tasks - 任务分解和评估
/analyze - 风险分析和缓解
/implement - 具体实现指导
第四步：预览命令
AI 调用 preview 工具在浏览器中展示生成的命令，你可以复制使用。
我想做一个在线教育平台，包含：
- 课程管理：老师可以创建、编辑课程
- 视频播放：支持视频进度记录
- 作业系统：学生提交作业，老师批改
- 讨论区：师生互动交流
- 数据分析：学习行为分析AI 会引导你逐步完善：
用户角色和权限
技术栈选择
部署方式
性能要求
安全考虑
最终生成完整的 Spec Kit 7 条命令。
如果你不熟悉 Spec Kit，可以在 Cursor 中说：
我想学习 Spec Kit 的命令AI 会调用 learn_speckit 工具，打开交互式学习页面，详细介绍每个命令的用途和使用方法。
gather - 收集需求信息作用： 收集用户的项目需求信息，AI 根据项目描述自动生成针对性问题配置。
参数：
projectIdea (必填): 项目想法描述，例如 "我想做一个待办事项应用"
userResponse (可选): 用户之前填写的回答文本（用于多轮对话）
previousFeedback (可选): 用户的修改意见（用于多轮对话）
sessionId (可选): 会话 ID，提供则继续现有会话，否则创建新会话
使用场景：
第一次描述项目需求
需要补充更多需求信息
修改之前的需求回答
工作流程：
检查 SpecKit 是否已初始化
创建或继续会话
AI 生成问题配置 JSON
自动调用 configure 工具打开可视化界面
输出： 返回 AI 提示词，指导 AI 生成需求配置 JSON 文件。
configure - 打开可视化配置界面作用： 接收需求配置文件路径，启动本地 Web 服务器，在浏览器中展示配置表单，等待用户填写并提交。
参数：
configFilePath (必填): 需求配置 JSON 文件的路径
使用场景：
gather 工具生成配置文件后自动调用
需要用户填写具体需求信息
工作流程：
读取配置文件验证有效性
启动 Web 服务器（端口 3456）
打开浏览器展示表单
等待用户填写并提交
保存用户回答到文件
输出： 返回格式化的用户回答文本和响应文件路径。
analyze - 分析需求完整性作用： 分析收集到的需求信息，判断是否足够完整和明确。如果需求明确，生成需求总结并指示构建命令；如果不明确，指示继续收集更多信息。
参数：
projectIdea (必填): 项目想法描述
userAnswers (必填): 用户当前回答的文本
userResponseFilePath (必填): 用户回答的响应文件路径（用于提取 sessionId）
使用场景：
configure 工具获取用户回答后自动调用
判断是否需要继续收集需求
工作流程：
从文件路径提取 sessionId
保存输入参数到文件
AI 分析需求完整性
如果需求明确，AI 生成需求总结 JSON
如果需求不明确，AI 指示继续 gather
输出： 返回 AI 提示词，指导 AI 分析需求并决定下一步操作。
build - 构建 Spec Kit 7 条命令作用：
基于完整的需求总结，生成 Spec Kit 7 条命令：/constitution、/specify、/clarify、/plan、/tasks、/analyze、/implement。使用 Vue 3 + TypeScript 技术栈，强调高可用、高性能、高可维护性。
参数：
requirementsSummaryFilePath (必填): 需求总结 JSON 文件路径
使用场景：
analyze 工具确认需求完整后自动调用
生成最终的 Spec Kit 命令
工作流程：
读取需求总结文件
提取项目想法和需求总结
AI 根据模板生成 7 条命令
保存命令到 JSON 文件
自动调用 preview 工具展示结果
输出： 返回 AI 提示词，指导 AI 生成 7 条 Spec Kit 命令的 JSON 文件。
生成的命令包括：
/constitution - 项目原则和开发规范
/specify - 功能规格和用户故事
/clarify - 技术细节澄清
/plan - 技术实现方案
/tasks - 任务分解和评估
/analyze - 风险分析和缓解
/implement - 具体实现指导
preview - 预览命令结果作用： 接收命令结果文件路径，在浏览器中以美观的方式展示生成的 7 条 Spec Kit 命令，方便用户查看和复制。
参数：
commandsFilePath (必填): 命令结果 JSON 文件路径
使用场景：
build 工具生成命令后自动调用
查看已生成的命令结果
工作流程：
读取命令结果文件
验证文件格式有效性
启动 Web 服务器（如果未启动）
打开浏览器展示命令
用户可以复制各个命令
输出： 返回命令列表摘要和浏览器展示页面。
learn_speckit - 学习 Spec Kit 命令作用： 打开一个交互式网页，详细介绍 Spec Kit 的所有命令、用途、使用方法和最佳实践。
参数：
无需参数（或 _ 占位参数）
使用场景：
不熟悉 Spec Kit 命令
想了解各个命令的详细用法
查看命令使用示例
工作流程：
启动 Web 服务器（如果未启动）
打开学习指南页面
展示所有命令的详细说明和示例
输出： 返回提示信息，告知已打开学习页面。
学习内容包括：
📚 所有 Spec Kit 命令的详细说明
💡 每个命令的中文示例
🎯 可视化的开发流程
💭 实用的使用技巧
这个 MCP 需要在你的项目目录中创建和管理文件：
检查 .specify/ 目录是否存在（SpecKit 初始化标志）
在 .specify/ui-cache/ 目录下保存会话数据
存储生成的配置文件和命令结果
因此，必须在配置中指定 --work-dir 参数，指向你要开发的项目目录。
如果你有多个项目需要使用 Spec Kit UI MCP，可以为每个项目配置不同的服务器：
{
"mcpServers": {
"spec-kit-project-a": {
"command": "npx",
"args": ["-y", "spec-kit-ui-mcp", "--work-dir", "E:/Projects/ProjectA"]
},
"spec-kit-project-b": {
"command": "npx",
"args": ["-y", "spec-kit-ui-mcp", "--work-dir", "E:/Projects/ProjectB"]
}
}
}这样你可以在不同的项目间切换使用。
所有会话数据自动保存在项目的 .specify/ui-cache/ 目录下：
.specify/
└── ui-cache/
└── session-20231204-123456/
├── 1-gather-request.json # gather 工具的输入参数
├── 1-gather-response.json # AI 生成的问题配置
├── 1-gather-prompt.md # gather 工具的提示词
├── 2-configure-response.json # 用户填写的回答
├── 2-configure-prompt.md # configure 工具的提示词
├── 3-analyze-request.json # analyze 工具的输入
├── 3-analyze-response.json # 需求总结
├── 3-analyze-prompt.md # analyze 工具的提示词
├── 4-build-request.json # build 工具的输入
├── 4-build-response.json # 生成的 7 条命令
└── 4-build-prompt.md # build 工具的提示词每个步骤都有完整的记录，方便追溯和调试。
✅ 好的描述：
我想做一个任务管理网站，包含看板视图、列表视图、
团队协作功能，界面简约现代，支持暗色模式，
使用 Vue 3 + TypeScript，部署到云服务器
❌ 不好的描述：
我想做一个网站详细的描述能让 AI 生成更准确的问题配置。
不用担心第一次说不清楚，AI 会通过多轮对话帮你完善需求：
第一轮：收集基本功能需求
第二轮：收集技术栈和部署方式
第三轮：收集性能和安全要求
所有会话数据都保存在 .specify/ui-cache/ 目录，你可以：
查看之前的需求配置
修改用户回答并重新生成
对比不同版本的命令
如果你是第一次使用，建议先调用 learn_speckit 工具学习各个命令的用途，这样能更好地理解生成的结果。
# 克隆仓库
git clone https://github.com/yourusername/spec-kit-ui-mcp.git
cd spec-kit-ui-mcp
# 安装依赖
npm install
# 构建
npm run build
# 开发模式
npm run devMIT © spec-kit-ui-mcp contributors
Model Context Protocol - MCP SDK
Spec Kit - 开发方法论
Vue.js - 前端框架
Tailwind CSS - 样式框架
如果有帮助，请给个 ⭐️ Star！
分析收集到的需求信息，判断是否足够完整和明确。如果需求明确，生成需求总结并指示构建命令；如果不明确，指示继续收集更多信息。
| Name | Required | Description | Default |
|---|---|---|---|
| projectIdea | Yes | 项目想法描述 | |
| userAnswers | Yes | 用户当前回答的文本 | |
| userResponseFilePath | Yes | 用户回答的响应文件路径（用于提取 sessionId） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full responsibility for behavioral disclosure. It does disclose the core decision logic (complete vs. incomplete) and the resulting actions (generate summary and instruct build, or instruct to continue gathering), which is useful context. However, it does not mention potential side effects such as whether it writes to files, whether it uses the provided file path beyond reading, or whether the analysis persists any state. Still, the described branching behavior is a significant transparency step beyond a generic 'analyze' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes the conditional behavior in an efficient second sentence. There is no redundancy or filler; every clause contributes meaningful guidance for using the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no output schema, and moderate complexity with branching logic, the description explains the decision outcomes and references sibling tools (gather, build) appropriately. It does not detail the exact output format or how the 'instruct build command' is delivered, but the description is reasonably complete for an analysis tool in a workflow context. The presence of sibling tools provides additional contextual signals, and the description aligns well with that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a clear description. The tool description does not add additional meaning to the parameters (projectIdea, userAnswers, userResponseFilePath) beyond what the schema already states. The baseline for high schema coverage is 3, and the description does not go beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyze collected requirements to judge completeness and clarity. It further specifies branching actions, distinguishing it from siblings like gather (collection), build (construction), and preview (viewing). The verb 'analyze' plus resource '需求信息' makes it specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: after requirements have been collected and before proceeding to build. It provides clear context by stating that if requirements are clear, it instructs building, otherwise it directs to continue collecting (referencing the gather sibling). However, it does not explicitly state scenarios where this tool should not be used or formalize when/where it fits in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
基于完整的需求总结构建 Spec Kit 7 条命令：/constitution、/specify、/clarify、/plan、/tasks、/analyze、/implement。使用 Vue 3 + TypeScript 技术栈，强调高可用、高性能、高可维护性。
| Name | Required | Description | Default |
|---|---|---|---|
| requirementsSummaryFilePath | Yes | 需求总结 JSON 文件路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must disclose behavior. It mentions the output (7 commands) and tech stack (Vue 3 + TypeScript) but omits side effects, file creation, permissions, return format, or reversibility. This is a significant gap for a build operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first states the core action and output; the second provides tech stack and quality attributes. It is concise and front-loaded without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema or annotations, the description gives a high-level purpose and input but lacks detail on return values, filesystem effects, or failure conditions. For a build tool, this incomplete context leaves the agent uncertain about post-invocation outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a single required parameter described as '需求总结 JSON 文件路径'. The description's reference to '完整的需求总结' aligns with the parameter but adds no additional semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds the Spec Kit 7 commands (listing them explicitly) based on a requirements summary. The verb 'build' and resource 'Spec Kit 7 commands' are specific, but it does not explicitly differentiate from sibling tools like analyze or preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '基于完整的需求总结' implies a prerequisite (a complete requirements summary), giving some usage context. However, there is no explicit mention of when not to use this tool or alternatives, and sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
接收需求配置文件路径，打开可视化界面让用户填写需求详情。该工具会启动本地 Web 服务器，在浏览器中展示配置表单，等待用户填写并提交。
| Name | Required | Description | Default |
|---|---|---|---|
| configFilePath | Yes | 需求配置 JSON 文件的路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: starting a local web server, displaying a form, and waiting for user submission. However, it omits what happens after submission (e.g., saving to the file or returning data) and potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and then provide supporting details, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately describes the interactive workflow, but because there's no output schema, it should explain post-submit behavior. The agent is left uncertain about the return value or file modification, and no annotation helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since configFilePath is described as a path to a JSON file. The description reinforces this by saying it receives the path, but adds no new semantic details beyond connecting it to the flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: receiving a config file path and launching a visual UI for the user to fill in requirement details. It distinguishes itself from siblings like 'gather' or 'preview' by describing a unique interactive workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage context: when you have a config file and want user input via a browser form. However, it doesn't explicitly mention when not to use it or compare to alternatives like 'gather' or 'analyze'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
收集用户的项目需求信息，生成结构化的需求问题配置。该工具会返回提示词，AI 根据提示词生成需求配置 JSON，然后调用 configure 工具让用户填写。支持多回合收集。
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | No | 会话ID（可选），如果提供则继续现有会话，否则创建新会话 | |
| projectIdea | Yes | 用户的项目想法描述，例如：我想做一个待办事项应用 | |
| userResponse | No | 用户之前填写的回答文本（可选），如果是第一次调用则不需要此参数 | |
| previousFeedback | No | 用户的修改意见（可选），如果是第一次调用则不需要此参数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns a prompt rather than final output, and that it supports multi-round collection. However, it has a slight internal ambiguity between 'generates configuration' and 'returns a prompt', and it doesn't mention side effects or statelessness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each providing distinct information: purpose, workflow, and multi-round capability. No redundant content, and the description is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's role in the workflow (gather -> configure) and the return type (prompt). The schema covers all parameters. It lacks an output schema, but the description is sufficient for a tool of this complexity within its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the input schema. The description adds no additional parameter semantics beyond mentioning multi-round support, which is already implied by the sessionId and userResponse parameter descriptions. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool collects user project requirements and generates structured question configuration. It explicitly mentions returning a prompt for AI to generate JSON and call the configure tool, which distinguishes it from sibling tools like configure, analyze, and build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the first step in a workflow where gather collects requirements, then configure is called for user input. It provides clear context for when to use gather (to collect requirements) but doesn't explicitly state exclusions or alternatives beyond the configure step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
快速了解 Spec Kit 的所有指令和开发流程。打开一个交互式网页，详细介绍每个命令的用途、使用方法和最佳实践。
| Name | Required | Description | Default |
|---|---|---|---|
| _ | No | 无需参数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavior. It mentions 'opens an interactive web page,' which is the primary side effect. However, it does not clarify whether this modifies any files, requires network access, or has other side effects. For a non-destructive tutorial tool, this is acceptable but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, front-loaded with the tool's core purpose and followed by the mechanism. Every word contributes value, with no redundant or vague phrasing. It is appropriately sized for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no output schema, and minimal annotations—the description provides all necessary context. It states what the tool does, how it does it, and the scope of content covered. The interaction with sibling tools is clear from the naming and purpose, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single placeholder parameter '_' with description '无需参数' (no parameters needed). Since the description does not address parameters, the schema fully covers parameter semantics. The tool effectively takes no parameters, so no additional context is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to quickly understand all Spec Kit commands and the development process. It specifies the action ('opens an interactive web page') and the resource (Spec Kit commands and best practices). This distinguishes it from sibling tools like gather, configure, analyze, build, and preview, which are operational rather than educational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when needing a quick overview of the entire Spec Kit command set and workflow. It does not explicitly mention alternatives or when not to use it, but the purpose is clearly differentiated from the operational sibling tools. For a simple learning tool, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
接收命令结果文件路径，在网页中预览构建好的 7 条 Spec Kit 命令。用于在 build 构建命令后，以美观的方式展示结果，方便用户查看和复制。
| Name | Required | Description | Default |
|---|---|---|---|
| commandsFilePath | Yes | 命令结果 JSON 文件路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It mentions the tool displays results in a webpage and is intended for viewing/copying, implying a non-destructive preview. However, it does not discuss any requirements, potential errors, or limitations beyond this basic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function and followed by usage context. Every sentence contributes meaning with no wasted words or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema, no annotations), the description adequately covers the tool's purpose and timing. It could mention prerequisites or error conditions, but the simple nature of a preview tool makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the only parameter (commandsFilePath), and the description essentially repeats the schema's description. It adds no additional meaning about the parameter's format or constraints, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool receives a command results file path and previews the built 7 Spec Kit commands in a webpage. This specific verb+resource+scope distinguishes it from sibling tools like build (which builds) and analyze, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states '用于在 build 构建命令后' (use after the build command), providing clear contextual guidance for when to invoke this tool. It does not name alternatives or exclusions, but the timing context is sufficiently clear for a simple preview tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.5analyzebuildconfiguregatherlearn_speckitpreviewScored across 6 tools
Each tool has a distinct role in the workflow: gather collects requirements, configure opens a UI for details, analyze assesses completeness, build generates commands, learn_speckit provides education, and preview displays results. There is no meaningful overlap between any two tools.
Tool names are all lowercase imperative verbs, mostly single-word (gather, configure, analyze, build, preview). learn_speckit deviates from the single-word convention but still follows the verb_noun pattern, making the set largely predictable.
Six tools is a well-scoped number for the workflow, covering each essential step without redundancy. The count comfortably falls within the ideal 3–15 range and each tool contributes meaningfully.
The tool set covers the full lifecycle from requirement gathering to configuration, analysis, building, and previewing. learn_speckit fills an educational gap, and there are no obvious missing operations for the stated purpose.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Build and publish Overskill apps from Cursor, Claude, ChatGPT, or any MCP client.
