Trae-OpenSpec MCP
Generates OpenSpec specification files (spec.md) and task lists (tasks.md) in Markdown format to guide AI-driven development.
Supports the creation of Next.js projects and components through automated project scaffolding and specification generation.
Enables the generation and management of Node.js projects, including backend structure and package configurations based on OpenSpec standards.
Provides tools for creating and optimizing React-based projects by generating standardized specifications and boilerplate code.
Assists in scaffolding and optimizing TypeScript applications by providing structured specifications and AI-driven code improvement tools.
Click on "Install 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., "@Trae-OpenSpec MCPCreate a modern blog project named MyBlog using React and Node.js"
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.
Trae-OpenSpec MCP工具套件
🚀 零命令行的OpenSpec项目创建和管理工具,专为Trae AI设计。
🎯 功能特性
🎨 图形化操作:完全基于Trae的GUI界面,无需命令行
⚡ 一键创建:通过自然语言描述自动生成完整项目
📋 智能规范:AI驱动的规范文件生成
🔧 代码优化:基于OpenSpec规范的智能代码优化
🧪 实时测试:内置测试和验证功能
Related MCP server: Vibe Coder MCP
📦 快速开始
1. 环境要求
Node.js: v18.0.0 或更高版本
Trae AI: 最新版本
操作系统: Windows/macOS/Linux
2. 安装方式
方法1:快速安装(推荐)
# 1. 克隆MCP工具仓库
git clone https://github.com/leon30083/trae-openspec-mcp.git
cd trae-openspec-mcp
# 2. 安装依赖
npm install
# 3. 启动服务器
npm start方法2:全局安装
# 1. 全局安装MCP工具
npm install -g trae-openspec-mcp
# 2. 在任何目录启动服务器
trae-openspec-mcp方法3:开发模式安装
# 1. 克隆仓库
git clone https://github.com/leon30083/trae-openspec-mcp.git
cd trae-openspec-mcp
# 2. 安装开发依赖
npm install
# 3. 以开发模式启动(带调试信息)
npm run dev3. 启动MCP服务器
可按安装方式选择对应的启动命令:
# A) 本地仓库启动(推荐)
npm start
# 或直接使用 Node
node mcp-server.js
# B) 全局安装后启动(CLI)
trae-openspec-mcp
# C) 开发模式(自动重启)
npm run dev提示:本MCP服务器采用STDIO传输与Trae集成,无需HTTP端口配置。
4. 在Trae中配置
打开Trae AI设置
进入"MCP服务器"配置
添加新的MCP服务器 使用 JSON 方式添加 MCP 服务器,在 Trae 的配置中加入:
{
"mcpServers": {
"trae-openspec-mcp": {
"command": "node",
"args": [
"mcp-server.js"
],
"cwd": "<你的本地路径>/trae-openspec-mcp"
}
}
}说明:
将
cwd设置为仓库根目录(包含mcp-server.js)。若已发布到 npm,可改为:
{
"mcpServers": {
"trae-openspec-mcp": {
"command": "npx",
"args": ["-y", "trae-openspec-mcp"]
}
}
}路径说明(Windows)
本项目在你的环境中的本地路径为:
F:\\Cursor\\OpenSpec\\mcp-tools在 JSON 中使用 Windows 路径时,请使用双反斜杠
\\使用
npx配置时可以省略cwd,由 npm 解析安装目录
🛠️ 核心工具
1. 创建OpenSpec项目
功能:基于自然语言描述自动创建完整的OpenSpec项目
参数:
description(必需): 项目需求描述projectName(必需): 项目名称techStack(可选): 技术栈偏好
示例:
{
"description": "创建一个现代化的博客系统,支持用户注册、文章发布、评论功能",
"projectName": "MyBlog",
"techStack": "React + Node.js"
}返回:
项目结构
生成的规范文件
下一步操作指南
2. 生成OpenSpec规范
功能:根据需求描述生成OpenSpec规范文件
参数:
requirements(必需): 功能需求描述projectType(可选): 项目类型 (blog/ecommerce/social/enterprise/custom)
示例:
{
"requirements": "用户管理系统,包含注册、登录、个人资料管理功能",
"projectType": "user_management"
}返回:
完整的spec.md内容
对应的tasks.md内容
使用说明
3. 优化代码
功能:基于OpenSpec规范优化现有代码
参数:
code(必需): 需要优化的代码spec(必需): OpenSpec规范内容feedback(可选): 优化反馈和建议
示例:
{
"code": "function getUser(id) { return db.query('SELECT * FROM users WHERE id = ' + id); }",
"spec": "# API规范\n## 用户管理\n- 输入验证\n- 错误处理\n- SQL注入防护",
"feedback": "需要添加输入验证和错误处理"
}返回:
优化后的代码
优化报告
改进建议
📋 使用流程
场景1:创建新项目
描述需求:在Trae中描述你的项目需求
生成项目:使用
create_openspec_project工具查看结果:检查生成的项目结构和规范
开始开发:在Trae中打开项目进行开发
场景2:生成规范
提供需求:描述你的功能需求
选择类型:指定项目类型或保持默认
生成规范:使用
generate_openspec_spec工具应用规范:将生成的规范应用到项目中
场景3:优化代码
提供代码:粘贴需要优化的代码
提供规范:粘贴对应的OpenSpec规范
添加反馈:(可选)提供优化建议
获取优化:使用
optimize_code_by_spec工具
🎯 项目模板
MCP工具内置了多种项目模板:
博客系统 (blog)
用户注册/登录
文章CRUD操作
评论系统
富文本编辑器
电商平台 (ecommerce)
商品管理
购物车系统
订单处理
支付集成
用户管理 (user_management)
认证授权
用户资料管理
权限控制
JWT Token管理
自定义项目 (custom)
基于需求智能生成
灵活的功能组合
可定制的规范模板
🔧 配置选项
服务器配置
创建 mcp-config.json 文件来自定义服务器行为:
{
"server": {
"name": "trae-openspec-server",
"version": "0.1.0",
"timeout": 30000
},
"templates": {
"customTemplatesPath": "./custom-templates",
"enableCustomTemplates": true
},
"ai": {
"model": "gpt-4",
"temperature": 0.7,
"maxTokens": 2000
}
}自定义模板
在 custom-templates 目录中添加你的模板:
custom-templates/
├── blog/
│ ├── spec.md
│ └── tasks.md
├── ecommerce/
│ ├── spec.md
│ └── tasks.md
└── [your-template]/
├── spec.md
└── tasks.md🐛 故障排除
常见问题
Q: MCP服务器无法启动
检查Node.js版本是否符合要求
确认所有依赖已正确安装
查看控制台错误信息
Q: Trae无法连接MCP服务器
检查服务器配置是否正确
确认工作目录设置正确
验证网络连接状态
Q: 工具调用失败
检查参数格式是否正确
确认必需参数已提供
查看控制台输出获取详细信息
调试模式
开发模式会自动重启并输出详细日志:
npm run dev📚 示例项目
示例1:创建博客系统
// 请求
{
"name": "create_openspec_project",
"arguments": {
"description": "创建一个现代化的个人博客系统,支持Markdown编辑、标签分类、评论功能",
"projectName": "PersonalBlog",
"techStack": "Next.js + TypeScript"
}
}
// 响应
{
"content": [{
"type": "text",
"text": "✅ OpenSpec项目 \"PersonalBlog\" 创建成功!\n\n📁 生成的文件结构:\n 📁 PersonalBlog/\n 📁 openspec/\n 📁 specs/\n - spec.md: 博客系统API规范\n - tasks.md: 实现任务清单\n 📁 src/\n 📁 routes/\n - index.js: 路由配置\n 📁 models/\n - index.js: 数据模型\n 📄 package.json: 项目配置\n 📄 README.md: 项目说明\n\n🎯 下一步:\n1. 查看生成的规范文件\n2. 使用AI生成代码\n3. 运行和测试项目"
}]
}示例2:生成用户管理规范
// 请求
{
"name": "generate_openspec_spec",
"arguments": {
"requirements": "企业级用户管理系统,包含组织架构、角色权限、单点登录功能",
"projectType": "enterprise"
}
}
// 响应
{
"content": [{
"type": "text",
"text": "# OpenSpec规范文件\n\n基于您的需求生成的规范:\n\n## 需求分析\n企业级用户管理系统,包含组织架构、角色权限、单点登录功能\n\n## 生成的规范内容\n```markdown\n# API规范:企业用户管理系统\n\n## 项目信息\n- 名称:企业用户管理系统\n- 版本:v1.0.0\n- 描述:支持组织架构、角色权限、单点登录的企业级系统\n\n## 核心功能\n### 1. 组织架构管理\n- 部门管理\n- 员工信息管理\n- 组织层级结构\n\n### 2. 角色权限系统\n- 角色定义和管理\n- 权限分配\n- 资源访问控制\n\n### 3. 单点登录(SSO)\n- OAuth2集成\n- SAML支持\n- 统一身份认证\n```\n\n📋 使用说明:\n1. 复制上述规范内容到项目的spec.md文件\n2. 根据需要调整细节\n3. 使用AI生成代码实现"
}]
}🤝 贡献指南
欢迎贡献!请查看 CONTRIBUTING.md 了解详情。
📄 许可证
MIT License - 查看 LICENSE 文件了解详情。
🔗 相关链接
💡 提示:本工具完全兼容Trae AI的图形化界面,无需记忆任何命令行指令!
Available Tools
3 toolscreate_openspec_projectC
基于需求描述自动创建OpenSpec项目
| Name | Required | Description | Default |
|---|---|---|---|
| techStack | No | 技术栈偏好(可选) | |
| description | Yes | 项目需求描述 | |
| projectName | Yes | 项目名称 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'automatically create' without disclosing side effects, expected outcomes, permissions, or any behavioral traits beyond basic mutation.
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 is front-loaded with the core action, no unnecessary words. However, it could be slightly expanded to include more context without becoming verbose.
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 no output schema and no annotations, the description is too brief. It lacks information about return values, project structure, or what 'automatically' entails, leaving significant gaps 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?
Input schema has 100% coverage, but the description adds no extra meaning beyond the parameter names and descriptions. It does not explain how parameters interplay or provide examples.
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 action (automatically create OpenSpec project) and the input (requirement description). It is specific and directly maps to the tool name, but does not differentiate from sibling tools like generate_openspec_spec or optimize_code_by_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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_openspec_specC
根据需求生成OpenSpec规范文件
| Name | Required | Description | Default |
|---|---|---|---|
| projectType | No | 项目类型 | |
| requirements | Yes | 功能需求描述 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral details. It does not disclose side effects, permissions, read/write nature, or any constraints beyond the obvious generation action. This is insufficient for the agent to anticipate consequences.
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, clear sentence with no extraneous content. It front-loads the core action. However, it could benefit from slightly more detail without becoming verbose.
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 lack of output schema and the simplicity of parameters, the description is incomplete. It does not specify what the generated spec contains (e.g., file path, content), nor does it address potential errors or success conditions. For a generation tool, this omission is significant.
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%, so the base expectation is 3. The description mentions 'requirements' but adds no new information about the 'projectType' parameter or syntax expectations. It meets the minimum but adds little value beyond the schema.
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 indicates the tool generates an OpenSpec specification file from requirements, which is clear. However, it does not explicitly distinguish it from sibling tools like create_openspec_project or optimize_code_by_spec, but the name and context make the purpose understandable.
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 the siblings. It only states the basic function without any context about prerequisites, limitations, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
optimize_code_by_specB
根据OpenSpec规范优化现有代码
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | 需要优化的代码 | |
| spec | Yes | OpenSpec规范内容 | |
| feedback | No | 优化反馈和建议 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, return values, or operational requirements (e.g., file I/O). The agent is left without understanding what happens after the optimization.
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 conveys the core purpose without unnecessary words. It is well-structured and efficiently communicates the tool's function.
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?
Despite having no output schema and no annotations, the description fails to specify what the tool returns or any operational context. The agent lacks information needed to fully understand the tool's behavior in a workflow.
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?
All three parameters have descriptions in the schema (100% coverage), so the tool description adds minimal extra meaning. It reinforces the spec's role but does not provide deeper semantics beyond the schema.
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 optimizes existing code based on an OpenSpec specification. It distinguishes from sibling tools (create_openspec_project and generate_openspec_spec) by focusing on code optimization rather than project creation or spec generation.
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 the tool is for optimizing code with a spec but does not explicitly state when to use it versus alternatives or provide any usage exclusions. The sibling names offer context but not direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.1.0- First observed
create_openspec_project - First observed
generate_openspec_spec - First observed
optimize_code_by_spec
TDQS
Each tool has a distinct purpose: creating a project, generating a spec, and optimizing code. There is no overlap or ambiguity between them.
All tool names follow a consistent snake_case pattern with verb_noun structure (create_*, generate_*, optimize_*). The naming is predictable and clear.
3 tools is well-scoped for this server's focus on OpenSpec project creation and spec-driven optimization. Each tool serves a necessary role without redundancy.
The tools cover the core workflow (create project, generate spec, optimize code). Minor gaps might include updating or deleting projects/specs, but these are not essential for the primary use case.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for generating rough-draft project plans from natural-language prompts.
A MCP server built for developers enabling Git based project management with project and personal…
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
Related MCP Servers
- AlicenseAqualityBmaintenanceAn MCP server that implements Claude Code-like functionality, allowing the AI to analyze codebases, modify files, execute commands, and manage projects through direct file system interactions.15303MIT
- AlicenseBqualityCmaintenanceAn MCP server that supercharges AI assistants with powerful tools for software development, enabling research, planning, code generation, and project scaffolding through natural language interaction.1167101MIT
- AlicenseDqualityDmaintenanceAn AI-powered MCP server that enables natural language interaction with AO (Arweave Operating system) for creating, running, and testing code and handlers without manual coding.141,709,9593BSD 3-Clause
- AlicenseCqualityAmaintenanceAn MCP server implementing Spec-Driven Development workflows for AI-agent CLIs and IDEs like Claude Code and Cursor, enabling spec-first development with automated workflow guidance and quality checks.167851MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/leon30083/trae-openspec-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server