Provides Angular-specific development specifications, including component patterns, naming conventions, and best practices, to ensure consistency in Angular projects.
Provides React-specific development specifications, including component patterns, naming conventions, and state management practices, to ensure consistency in React projects.
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-flow-mcp get the frontend coding spec"
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.
🤖 AI Infra 开发规范治理工具
一个基于 MCP (Model Context Protocol) 的智能开发规范管理系统，通过 AI 驱动的规范治理，帮助团队降低返工成本，提高代码一致性，缩短新成员上手时间。
MCP-Powered Project Memory for AI Agents - 直接集成到 Cursor、Claude、Cline、CodeX 等 AI 开发工具中，为 AI 代理提供持久的项目记忆，确保一致的编码标准，防止代码偏移，并在大型项目中维护架构完整性。
自动化规范检查和提醒
预防不一致的代码风格和架构决策
减少代码评审中的重复性问题
统一的开发规范和最佳实践
标准化的组件开发模式
一致的项目结构和命名约定
新成员快速了解项目规范
交互式规范查询和学习
AI 辅助的规范应用指导
Related MCP server: flyto-indexer
🤖 MCP 协议集成: 与 AI 助手无缝对接，提供智能规范查询
📝 规范全生命周期管理: 创建、编辑、查询、版本控制
💾 本地文件存储: 在项目根目录自动创建 spec 目录，规范与项目同步
🔧 TypeScript 支持: 类型安全，开发体验优秀
📦 现代 Node.js 技术栈: 高性能、易维护
🔗 多工具兼容性: 可与 Cursor、Claude Desktop、Cline、CodeX 等任何 MCP 兼容的 AI 开发环境无缝协作
🏢 企业级项目支持: 专为百万行代码的企业级代码库设计，支持复杂的微服务架构和分布式团队
🚫 终结遗留项目中的 AI 代码混乱
终结 AI 代理在复杂项目中生成不一致代码的困扰
提供现有模式、技术债务和架构决策的上下文
📏 在所有 AI 工具中强制执行编码标准
无论使用 Cursor、Claude 还是 Cline，所有 AI 代理都遵循相同的项目约定
消除不一致的变量命名、文件结构或架构模式
⭐ 完美适配前端开发团队
专为 React、Vue、Angular 项目优化，确保一致性至关重要
确保组件模式、状态管理方法和样式约定在代码库中保持统一
🏗️ 企业级项目记忆
自信地处理大型代码库，从小团队扩展到数百名开发人员
在所有项目中保持一致的 AI 辅助开发实践
在支持 MCP 的 AI 编辑器（如 Cursor）的配置文件中添加：
{
"mcpServers": {
"spec-flow-mcp": {
"command": "npx",
"args": ["spec-flow-mcp@latest"]
}
}
}# 开发模式（实时重载）
pnpm dev
# 构建后运行
pnpm build && pnpm start# 使用 tsx 运行 TypeScript
npx tsx src/index.ts
# 或者构建后运行
pnpm build && node dist/index.js打开 VS Code
按 F5 或选择"运行和调试"
选择"调试 MCP 服务器"配置
# 启用详细日志
LOG_LEVEL=DEBUG pnpm dev
# 指定自定义端口（如果需要）
PORT=3000 LOG_LEVEL=DEBUG pnpm dev工具名称 | 功能描述 | 参数 |
| 获取指定的开发规范 |
|
| 列出所有可用的规范 | 无 |
| 创建新的开发规范 |
|
| 编辑已存在的规范 |
|
frontend: 前端开发规范（默认）
backend: 后端开发规范
mobile: 移动端开发规范
design: 设计规范
spec-flow-mcp/
├── src/
│ ├── core/ # 核心业务逻辑
│ │ ├── mcpServer.ts # MCP 服务器实现
│ │ └── specService.ts # 规范服务逻辑
│ ├── types/ # TypeScript 类型定义
│ ├── utils/ # 工具函数
│ │ ├── fileSystem.ts # 文件系统操作
│ │ └── logger.ts # 日志工具
│ └── index.ts # 应用入口点
├── spec/ # 自动创建的规范存储目录
└── dist/ # 构建输出目录在 Cursor、VS Code 等支持 MCP 的 AI 编辑器中：
用户: "获取表格组件的开发规范"
AI: 调用 get_development_spec("spttable") → 返回详细规范# 创建新的组件规范
create_development_spec("新组件名", "规范内容")
# 查看所有现有规范
list_specs()
# 更新规范内容
edit_development_spec("组件名", "更新后的内容")新团队成员可以通过 AI 助手快速查询：
项目的编码规范
组件开发模式
最佳实践指南
规范存储: 所有规范以 Markdown 格式存储在项目的 spec/ 目录
MCP 协议: 通过标准 MCP 协议与 AI 助手通信
智能检索: AI 助手可以根据上下文智能查询相关规范
实时同步: 规范更新即时生效，团队成员立即可用
该工具让开发规范从静态文档变成了可交互、可查询的知识库，真正实现了 AI 驱动的开发规范治理。
# 1. 确保已构建
pnpm build
# 2. 登录 npm（如果还没有登录）
npm login
# 3. 发布包
npm publish
# 4. 发布带标签的版本（可选）
npm publish --tag latest# 升级版本
npm version patch # 1.0.0 -> 1.0.1
npm version minor # 1.0.1 -> 1.1.0
npm version major # 1.1.0 -> 2.0.0
# 发布新版本
npm publish发布后，用户就可以通过 npx spec-flow-mcp@latest 直接使用你的工具了！
产品介绍: 查看完整的 SpecFlow AI 功能介绍和最新动态
社区: 加入我们的社区，与其他开发者分享经验和最佳实践
我们正在完善基于 MCP 的集成功能，这将彻底改变你的 AI 开发工具理解项目的方式。关注我们的官网获取最新进展，成为首批体验一致、上下文感知的 AI 编码辅助的用户。
让我们一起终结项目中的 AI 代码混乱！ 🎯
创建新的开发规范，不允许覆盖已存在的规范
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 规范的完整内容（Markdown格式） | |
| spec_name | Yes | 规范名称，如：newcomponent, newpattern | |
| projectRoot | Yes | 项目根目录路径，规范将存储在 {projectRoot}/.spec 目录下 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses key behavioral constraint (no overwriting), but lacks details on error handling, permissions, or return values. It adds some transparency but is incomplete for a creation tool.
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?
Single sentence, front-loaded with action and constraint. No redundant information. Highly concise and well-structured.
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?
No output schema, and description fails to explain return value or success/error behavior. For a creation tool with 3 required parameters, the description lacks completeness regarding what the agent can expect as a result.
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 clear descriptions for all three parameters. The description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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?
Description clearly states the action (create) and resource (development specification), with explicit constraint '不允许覆盖已存在的规范' (no overwriting existing specs). This distinguishes it from sibling tools like edit_development_spec or delete_development_spec.
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 usage when a new spec should be created without overwriting, but it does not explicitly state when to use this tool versus alternatives (e.g., edit for existing specs). No comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除已存在的开发规范
| Name | Required | Description | Default |
|---|---|---|---|
| spec_name | Yes | 规范名称，必须是已存在的规范 | |
| projectRoot | Yes | 项目根目录路径，规范将存储在 {projectRoot}/.spec 目录下 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the delete action but does not disclose irreversibility, side effects (e.g., deletion of underlying files), or any confirmation 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 a single concise sentence that communicates the core action with no wasted words. However, it lacks structure such as separate sections for usage or behavior.
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 nature (delete operation) and lack of output schema, the description should explain consequences (e.g., spec is permanently removed) and error conditions (e.g., spec not found). It does not.
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 description coverage is 100% (both parameters have descriptions). The description does not add extra meaning beyond the schema, achieving baseline adequacy.
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 '删除已存在的开发规范' (delete existing development specifications) clearly states the verb 'delete' and the resource 'development spec,' distinguishing it from sibling tools (get, list, create, edit).
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?
No guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites mentioned. The description is minimal and provides no context for proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
编辑已存在的开发规范，只能修改现有规范的内容
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 规范的新内容（Markdown格式） | |
| spec_name | Yes | 规范名称，必须是已存在的规范 | |
| projectRoot | Yes | 项目根目录路径，规范将存储在 {projectRoot}/.spec 目录下 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states modification of content without disclosing overwrite behavior, side effects, permissions, or response format. Minimal behavioral disclosure.
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?
Single concise sentence, no wasted words, though it is relatively short. Front-loaded with key purpose.
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?
Adequate for a simple edit tool in a CRUD context, but lacks information on return values or confirmation, and no output schema. Could be more complete with usage 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 clear descriptions for each parameter. Description adds no additional meaning beyond schema, so baseline score of 3 is appropriate.
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?
Description clearly states it edits existing specs and only modifies content, effectively distinguishing from create/delete siblings. However, no explicit mention of other siblings.
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?
Implies usage by stating 'only modify content of existing spec', but lacks explicit when-to-use or when-not-to guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取开发规范
| Name | Required | Description | Default |
|---|---|---|---|
| spec_name | Yes | 规范名称，如：spttable, sptdrawer | |
| projectRoot | Yes | 项目根目录路径，规范将存储在 {projectRoot}/.spec 目录下 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It does not state that the tool is read-only, what happens if the spec does not exist, or any other operational details.
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?
Extremely concise but at the cost of informativeness. The single phrase is under-specified and does not provide enough context for an AI agent.
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 existence of sibling tools and no output schema, the description is critically incomplete. It does not explain the relationship to 'list_specs' or the return format, leaving the agent without sufficient information.
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 descriptions for both parameters. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 '获取开发规范' is a tautology of the tool name, providing no additional specificity. It does not distinguish this 'get' operation from the sibling 'list_specs' tool.
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?
No guidance on when to use this tool vs alternatives. The tool name implies retrieval of a single spec by name, but the description fails to explicitly state this or mention sibling tools like 'list_specs' for listing all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出所有可用的开发规范
| Name | Required | Description | Default |
|---|---|---|---|
| projectRoot | Yes | 项目根目录路径，规范将存储在 {projectRoot}/.spec 目录下 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does not disclose any behavioral traits such as what happens if the directory doesn't exist, or if there are any side effects. The tool is read-only but that is implicitly assumed.
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 extremely concise—one sentence that states the purpose without any wasted words. It is front-loaded and easy to parse.
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 simplicity of the tool (list operation, one parameter), the description is minimally adequate. However, it lacks details about the return format or any filtering options, which would be helpful for an agent.
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 already fully describes the sole parameter 'projectRoot' with 100% coverage. The description adds no additional meaning beyond what the schema 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 'List all available development specifications' uses a specific verb ('list') and clearly identifies the resource ('development specifications'). This distinguishes it from sibling tools like create, get, edit, delete.
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 provides no guidance on when to use this tool versus its siblings. There is no mention of prerequisites, context, or exclusion criteria.
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.2create_development_specdelete_development_specedit_development_specget_development_speclist_specsScored across 5 tools
Each tool targets a distinct action (get, list, create, edit, delete) on the same resource, with no overlap in functionality. An agent can easily distinguish them.
Most tools follow a verb_noun pattern with 'development_spec', but 'list_specs' abbreviates the noun slightly. This minor inconsistency does not significantly hinder understanding.
Five tools cover all basic CRUD operations for a single resource, which is well-scoped and appropriate for the server's purpose.
The set includes create, read (both single and list), update, and delete operations, covering the full lifecycle for development specs. No obvious gaps.
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Jam MCP server provides AI tools with instant bug context without manual prompting, enabling a streamlined workflow from bug identification to ticket creation and pull request generation without switching between tools.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
