Skip to main content
Glama

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 dev

3. 启动MCP服务器

可按安装方式选择对应的启动命令:

# A) 本地仓库启动(推荐)
npm start
# 或直接使用 Node
node mcp-server.js

# B) 全局安装后启动(CLI)
trae-openspec-mcp

# C) 开发模式(自动重启)
npm run dev

提示:本MCP服务器采用STDIO传输与Trae集成,无需HTTP端口配置。

4. 在Trae中配置

  1. 打开Trae AI设置

  2. 进入"MCP服务器"配置

  3. 添加新的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:创建新项目

  1. 描述需求:在Trae中描述你的项目需求

  2. 生成项目:使用create_openspec_project工具

  3. 查看结果:检查生成的项目结构和规范

  4. 开始开发:在Trae中打开项目进行开发

场景2:生成规范

  1. 提供需求:描述你的功能需求

  2. 选择类型:指定项目类型或保持默认

  3. 生成规范:使用generate_openspec_spec工具

  4. 应用规范:将生成的规范应用到项目中

场景3:优化代码

  1. 提供代码:粘贴需要优化的代码

  2. 提供规范:粘贴对应的OpenSpec规范

  3. 添加反馈:(可选)提供优化建议

  4. 获取优化:使用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 tools
create_openspec_projectC

基于需求描述自动创建OpenSpec项目

ParametersJSON Schema
NameRequiredDescriptionDefault
techStackNo技术栈偏好(可选)
descriptionYes项目需求描述
projectNameYes项目名称

TDQS

C2.7/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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规范文件

ParametersJSON Schema
NameRequiredDescriptionDefault
projectTypeNo项目类型
requirementsYes功能需求描述

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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规范优化现有代码

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYes需要优化的代码
specYesOpenSpec规范内容
feedbackNo优化反馈和建议

TDQS

B3.4/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 3 tool updatesv0.1.0
    • First observedcreate_openspec_project
    • First observedgenerate_openspec_spec
    • First observedoptimize_code_by_spec

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a distinct purpose: creating a project, generating a spec, and optimizing code. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with verb_noun structure (create_*, generate_*, optimize_*). The naming is predictable and clear.

Tool Count5/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    An 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.
    15
    303
    MIT
  • A
    license
    D
    quality
    D
    maintenance
    An 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.
    14
    1,709,959
    3
    BSD 3-Clause

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/leon30083/trae-openspec-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server