Enables reading and managing Git repositories, supporting features like reading project structures and managing code files.
Provides interaction with GitHub repositories, allowing for project management and code operations within GitHub projects.
Handles reading and generating rule files in Markdown format, supporting content parsing and creation for project documentation.
Enables installation and management of the MCP package through PyPI, supporting package distribution and updates.
Provides Python-based functionality for rule generation and management, supporting Python environments and modules.
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 Rules Generator MCP generate rules for a web project with authentication and database features"
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 AI 项目规则文件的 MCP (Model Context Protocol) 服务。
🔍 读取现有规则: 扫描和分析现有的规则文件结构
🎯 智能生成规则: 根据项目类型和功能特性生成定制化规则
💾 规则文件管理: 保存、更新和备份规则文件
🌐 多语言支持: 支持中文和英文规则生成
🔧 灵活配置: 支持自定义规则路径和文件名
Related MCP server: SkillMCP
pip3 install trae-rules-mcp在 Trae AI 的 MCP 配置中添加以下配置：
{
"mcpServers": {
"trae-rules-mcp": {
"command": "python3",
"args": ["-m", "trae_rules_mcp.main"],
"env": {
"PYTHONPATH": "."
}
}
}
}Python 3.8+
pip 或 uv 包管理器
git clone https://github.com/trae-ai/trae-rules-mcp.git
cd trae-rules-mcp# 使用 uv (推荐)
uv sync
# 或使用 pip
pip install -e .{
"mcpServers": {
"trae-rules-generator": {
"command": "uv",
"args": ["run", "python", "main.py"],
"cwd": "/path/to/trae-rules-mcp",
"env": {
"PYTHONPATH": "/path/to/trae-rules-mcp"
}
}
}
}💡 注意: 请将
/path/to/trae-rules-mcp替换为实际的项目路径。
配置完成后，重启 Trae AI 以加载新的 MCP 服务器。
读取现有的规则文件内容和结构信息。
参数:
rules_path (str, 可选): 规则文件目录路径，默认为 .trae/rules
返回:
规则文件的详细信息，包括文件列表、内容预览等
根据项目类型和功能特性生成新的项目规则文件。
参数:
project_type (str): 项目类型 (如: web, mobile, ai, backend, frontend)
features (List[str]): 项目功能特性列表 (如: ["authentication", "database", "api"])
language (str, 可选): 规则文件语言，默认为中文
返回:
生成的规则文件内容 (Markdown 格式)
保存规则文件到指定目录。
参数:
content (str): 规则文件内容
filename (str, 可选): 文件名，默认为 project_rules.md
rules_path (str, 可选): 规则文件目录路径，默认为 .trae/rules
返回:
保存操作的结果信息
更新现有的规则文件内容。
参数:
file_path (str): 要更新的规则文件路径
updates (Dict[str, Any]): 更新内容的字典
返回:
更新操作的结果信息
用户: 帮我生成一个包含用户认证和数据库功能的 Web 项目规则文件
AI 助手会调用:
generate_project_rules(
project_type="web",
features=["authentication", "database"],
language="中文"
)用户: 查看我当前项目的规则文件
AI 助手会调用:
read_existing_rules(rules_path=".trae/rules")用户: 将刚才生成的规则保存为 web_project_rules.md
AI 助手会调用:
save_rules_file(
content="生成的规则内容",
filename="web_project_rules.md",
rules_path=".trae/rules"
)---
description: web 项目规则
globs:
alwaysApply: true
---
### 📋 WEB 项目开发规则
#### 🔧 通用开发规则
1. **代码质量**
* 保持代码简洁、可读性强
* 添加必要的注释和文档
* 遵循项目的编码规范
#### 🎯 功能特性规则
1. **Authentication**
* 实现安全的用户认证
* 使用强密码策略
* 实现会话管理
2. **Database**
* 设计合理的数据库结构
* 实现数据备份策略
* 优化查询性能trae-rules-mcp/
├── trae_rules_mcp/ # 主要包目录
│ ├── __init__.py # 包初始化文件
│ └── main.py # MCP 服务主文件
├── main.py # 兼容性入口文件
├── pyproject.toml # 项目配置文件
├── README.md # 项目说明文档
├── example_rules.md # 示例规则文件
├── mcp_config_example.json # MCP 配置示例
├── CHANGELOG.md # 更新日志
├── LICENSE # 许可证文件
└── .gitignore # Git 忽略文件服务默认在 .trae/rules 目录下查找和保存规则文件。你可以通过工具参数自定义路径。
web / frontend: 前端 Web 项目
backend / api: 后端 API 项目
ai: AI/机器学习项目
mobile: 移动应用项目
其他自定义类型
authentication: 用户认证
database: 数据库操作
api: API 接口
ui: 用户界面
testing: 测试相关
deployment: 部署配置
security: 安全相关
performance: 性能优化
其他自定义特性
问题: 在 MCP 配置中遇到 "spawn python ENOENT" 错误。
解决方案:
使用完整的 Python 路径："command": "/usr/bin/python3"
或者确保 Python 在系统 PATH 中："command": "python3"
问题: "No module named 'trae_rules_mcp'" 错误。
解决方案:
# 重新安装包
pip3 uninstall trae-rules-mcp -y
pip3 install trae-rules-mcp
# 验证安装
python3 -c "import trae_rules_mcp; print('安装成功!')"问题: Trae AI 无法连接到 MCP 服务器。
解决方案:
检查配置文件格式是否正确
确认路径设置正确
重启 Trae AI
查看 Trae AI 的错误日志
问题: 无法创建或写入规则文件。
解决方案:
# 确保目录存在且有写入权限
mkdir -p .trae/rules
chmod 755 .trae/rules测试 MCP 连接:
# 手动启动服务器测试
python3 -m trae_rules_mcp.main检查包安装:
pip3 show trae-rules-mcp
pip3 list | grep trae验证配置:
确保 JSON 格式正确
检查路径是否存在
验证环境变量设置
Fork 本仓库
创建功能分支 (git checkout -b feature/AmazingFeature)
提交更改 (git commit -m 'Add some AmazingFeature')
推送到分支 (git push origin feature/AmazingFeature)
打开 Pull Request
本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。
📖 文档: 查看本 README 和项目 Wiki
🐛 问题报告: GitHub Issues
💡 功能建议: GitHub Discussions
📦 PyPI 包: trae-rules-mcp
当前版本: 1.0.1
Python 支持: 3.8+
MCP 协议: 兼容最新版本
查看 CHANGELOG.md 了解详细的版本更新信息。
🎉 感谢使用 Trae Rules Generator MCP！
如果这个项目对你有帮助，请考虑给我们一个 ⭐ Star！
根据项目类型和功能特性生成新的项目规则文件
Args: project_type: 项目类型 (如: web, mobile, ai, backend, frontend 等) features: 项目功能特性列表 (如: ["authentication", "database", "api"]) language: 规则文件语言，默认为中文
Returns: 生成的规则文件内容
| Name | Required | Description | Default |
|---|---|---|---|
| project_type | Yes | ||
| features | Yes | ||
| language | No | 中文 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It explains that the tool generates rules and returns content, but it doesn't disclose side effects (e.g., file creation) or limitations. It is adequate but not comprehensive.
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 concise with an Args/Returns structure, making it easy to scan. However, the format is slightly non-standard for MCP descriptions, and each sentence is earned.
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?
For a tool with 3 parameters and an output schema, the description covers the main function and parameters. Missing guidance on usage context and return format explanations (though output schema exists) leaves gaps.
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 description adds meaning beyond the schema by providing examples for project_type and features (e.g., 'web', 'mobile') and noting language defaults. Given 0% schema description coverage, this is valuable, though it lacks full constraints.
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 generates new project rules based on project type and features. However, it does not differentiate from sibling tools like update_existing_rules or read_existing_rules, which weakens clarity.
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 is provided on when to use this tool versus alternatives such as save_rules_file or update_existing_rules. The description only states its purpose without exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取现有的规则文件内容
Args: rules_path: 规则文件目录路径，默认为 .trae/rules
Returns: 现有规则文件的内容和结构信息
| Name | Required | Description | Default |
|---|---|---|---|
| rules_path | No | .trae/rules |
Does the description disclose side effects, auth requirements, rate limits, or destructive 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?
描述简短，先说明核心功能，后附参数和返回说明，结构清晰，无冗余。
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?
缺少输出模式，未详细说明返回内容的结构；无注解支持，描述过于简单，对于安全使用信息不足。
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?
参数rules_path在描述中解释了含义和默认值，弥补了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?
明确说明工具功能：'读取现有的规则文件内容'，动词+资源清晰，且与兄弟工具（generate_project_rules, save_rules_file, update_existing_rules）明显区分。
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?
未提供任何使用场景或替代工具的指导，没有说明何时使用或避免使用该工具，缺少上下文。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
保存规则文件到指定目录
Args: content: 规则文件内容 filename: 文件名，默认为 project_rules.md rules_path: 规则文件目录路径，默认为 .trae/rules
Returns: 保存操作的结果信息
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| filename | No | project_rules.md | |
| rules_path | No | .trae/rules |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should compensate. It mentions saving a file with defaults but does not disclose key behaviors like overwrite policy, directory creation, or error handling. The return description is vague ('保存操作的结果信息').
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 concise, using a brief title and structured 'Args' and 'Returns' sections. It avoids unnecessary words, though the structure could be slightly improved with bullet points for readability.
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 parameters, an output schema, and siblings, the description covers basic purpose but lacks behavioral details (e.g., overwriting) and usage guidance. It is adequate but incomplete for an agent to fully understand implications.
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 no parameter descriptions (0% coverage), but the tool description's 'Args' section provides clear explanations for each parameter: 'content' (file content), 'filename' (with default), 'rules_path' (with default). This adds meaningful 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 clearly states the action '保存' (save) and the resource '规则文件' (rules file) to a specified directory. It is distinguishable from siblings 'generate_project_rules' (creation) and 'read_existing_rules' (reading).
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, such as 'generate_project_rules' or 'update_existing_rules'. It lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
更新现有的规则文件内容
Args: file_path: 要更新的规则文件路径 updates: 更新内容的字典，支持以下键: - append_content: 要追加的内容 - replace_section: 要替换的章节 {"section_name": "new_content"} - insert_after: 在指定内容后插入 {"after": "content", "insert": "new_content"}
Returns: 更新操作的结果信息
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| updates | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It describes the updates parameter with specific keys (append, replace, insert) and indicates mutation. However, it omits error handling, permission requirements, atomicity, and what happens if the file does not exist. Returns are mentioned but not detailed. Adequate but incomplete.
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 concise with a clear 'Args' and 'Returns' structure. Front-loaded with the purpose. Could be slightly more compact by omitting the Returns line since output schema exists, but it is generally well-organized.
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 complexity (nested object, no schema description) and missing output schema content, the description provides key details but lacks usage context, error scenarios, and precise behavior of the updates parameter (e.g., combining multiple keys). The absence of guidelines and limited operational context makes it incomplete for seamless agent invocation.
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 0%, so the description compensates by explaining the structure of the updates parameter with three supported operations. It also clarifies file_path. This adds significant meaning beyond the raw schema. However, the description could define allowed keys more precisely and note that additional properties might be accepted.
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: 'update existing rules file content' with a specific verb and resource. It distinguishes from siblings by implying modification rather than creation (generate_project_rules), reading (read_existing_rules), or saving (save_rules_file).
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 mention of prerequisites, conditions for update, or when not to use. The description assumes the agent knows context but offers no explicit direction.
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. Dates show when Glama detected each change.
v1.0.1generate_project_rulesread_existing_rulessave_rules_fileupdate_existing_rulesEach tool has a distinct purpose: generating, reading, saving, and updating rules files. No overlapping functionality.
All tool names use consistent snake_case and verb_noun pattern (generate_project_rules, read_existing_rules, etc.).
Four tools are appropriate for a rules generation MCP, covering basic CRUD-like operations without being excessive.
Covers create, read, update, and save operations. Missing a delete tool, but save and update cover most workflows. Minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaochenwin/trae-rules-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
