Workflows MCP v0.1.0

由 @tedx_ai 构建

Workflows MCP 是一个模型上下文协议 (MCP) 服务器，允许您编排/组合多个提示 + MCP 服务器，形成复合 MCP 提示工具。

可以将其视为一个动态提示库，您可以通过 yaml 文件轻松共享和版本控制，还可以定义如何最好地在多个 MCP 服务器上使用多个 MCP 工具来完成特定任务。

概述

有效使用 MCP 的关键在于了解何时/如何使用正确的工具。 Workflows MCP 可以极大地简化和加速此过程。 使用 Workflows MCP，您可以：

✅ 将提示与 MCP 服务器结合到可重用且易于编辑/共享/组织的 workflows 中

✅ 使用自定义命令触发 workflows，例如：“进入调试器模式”或“使用思考模式”

✅ 定义自定义策略，用于如何在 workflow 中使用多个工具（顺序或情境/动态）

✅ 轻松让您的团队使用最佳提示 + 通过版本控制使用多个 MCP 工具的方式。

我们还提供了一些有用的预设，以帮助您入门 🫡

那么为什么要使用它？

该项目的目标是将提示转化为 AI 的可编程工具和规则，在代码编辑器中更具确定性，同时减少所有请求中的总体 token 使用量。 由于为 AI 填充全局规则集会占用您的上下文窗口，因此使用 MCP 路由到提示和 workflows 可以帮助减少所有请求中使用的总体 token 数量。

用于 MCP 的 Workflows 也非常强大！ 例如，您可以创建一个 “生产事故 workflow” 工具，该工具具有一个特殊的系统提示，可以以特定的方式推理事故，然后按特定顺序使用一系列工具来分析 + 可能解决该事故。 这可能涉及以下事项：

• 从 Kubernetes、Cloudwatch、Splunk 等的多个 MCP 工具中收集日志
• 检查 Github 问题或向量数据库中过去是否有类似问题
• 在网上搜索有用的信息
• 使用从先前步骤收集的所有上下文分析您的代码
• 使用从先前步骤收集的所有上下文编写详细的事故报告
• 收集您的输入，以更好地了解问题空间
• 如果可能，实施问题的修复

并且由于这些 workflows 都在 YAML 中定义，并且可以从您机器上的任何位置引用，因此您可以轻松地让您的团队围绕何时/如何使用最佳提示和 MCP 工具序列来完成特定任务 🦾

功能

📝 自定义配置

• 从 .workflows 或 .mcp-workflows 目录中的多个 YAML 文件加载自定义配置
• 轻松将这些 yaml 文件保存到 git 存储库并与您的团队共享
• 由于 MCP 服务器可以为每个项目设置自定义配置，因此您可以轻松选择要用于每个项目的配置 - 为每个项目设置自定义 workflow 文件夹
• 工具配置中对类型化参数输入的支持使构建自定义 MCP 提示工具变得轻而易举

🚀 即用型预设

Workflows MCP 包含多个开箱即用的预设 workflow 模式，用于思考、编码和 github 使用：

思考: 用于提高任何任务推理能力的一般用途工具

• 思考模式: 反思想法并产生结构化分析（受 Anthropic 最新思考工具研究的启发）
• 深度思考模式: 具有详细反思的全面多角度分析

编码: 普遍适用于常见编码任务的工具 普遍适用于常见编码任务的工具

• 调试器模式: 通过假设创建、遥测收集和测试进行系统化的多步骤推理和调试
• 架构模式: 具有权衡分析和实施计划的系统设计提示
• 计划器模式: 具有代码库分析的系统化代码更改计划
• PRD 模式: 用于功能、用户故事和 spike 分析的结构化产品需求文档
• 保存笔记: 记录正在进行的工作，并进行全面的进度跟踪。 当您需要暂时离开并想保存您的想法以供以后使用时非常有用。

GitHub: 用于简化常见 GitHub 任务的工具。 非常适合任何使用 Git 和 Github CLI 进行源代码控制的初学者

• PR 审查模式: 具有安全考虑因素的全面 pull request 分析
• PR 创建模式: 使用 GitHub CLI 的结构化 PR 创建过程
• 创建分支: 具有上下文命名的智能分支创建
• 保存更改: 系统化的 git 提交和推送 workflow

安装

使用以下命令或 JSON 将 MCP 服务器安装到 MCP 客户端中：

npx -y @agentdesk/workflows-mcp@latest

如果在 Cursor 中使用 JSON 设置您的 MCP 服务器，您可以使用以下配置：

{
  "mcpServers": {
    "workflows-mcp": {
      "command": "npx",
      "args": ["-y", "@agentdesk/workflows-mcp@latest"]
    }
  }
}

要提供自定义配置，您可以使用 --config 标志指向包含 YAML 配置文件的目录。 该目录必须命名为 .workflows 或 .mcp-workflows，如下所示：

npx @agentdesk/workflows-mcp@latest --config /path/to/.workflows

如果要启用预设，可以使用 --preset 标志指定要加载的预设：

npx @agentdesk/workflows-mcp@latest --preset thinking,coding,github

以下是它在 Cursor 配置中的全部组合：

{
  "mcpServers": {
    "workflows-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@agentdesk/workflows-mcp@latest --config /path/to/.workflows --preset thinking,coding"
      ]
    }
  }
}

注意：

• 如果您更新了配置，则必须刷新 MCP 工具
• 如果刷新不起作用，请确保您的配置是有效的 YAML
• 如果仍然遇到问题，请尝试删除并重命名客户端中的 MCP 工具
• 如果未提供配置或预设，则默认使用 thinking 预设。
• 如果您仍然无法使其正常工作，请打开一个 issue ticket

自定义 Workflow 配置

在您的项目中创建一个 .workflows 或 .mcp-workflows 目录，并添加任何名称的 YAML 配置文件（必须以 .yaml 或 .yml 结尾）。 如果命名与预设工具相同，这些配置也将覆盖预设默认值。

示例配置文件

基本 Workflow 配置

workflow_name:
  description: "此 workflow 的作用的描述"
  prompt: |
    在此处输入您的多行
    提示，就像这样
  toolMode: "situational" # 可以省略，因为它是默认值
  tools: "analyzeLogs, generateReport, validateFindings"

工具配置样式

您可以通过多种方式定义工具。

这是一个工具的示例，该工具使用情境性/根据需要使用的工具来调试代码库中的问题：

web_debugger_mode:
  description: 使用浏览器日志和 BrowserTools MCP 调试我的代码库我的 Web 应用程序
  prompt: |
    深入反思所有这些，并思考为什么它不起作用。 推测 4-6 种不同的可能问题来源。

    然后，深入推理根本原因，并将您的理论提炼为 1-2 个最可能的问题来源，然后再提出后续步骤。
  tools: getConsoleLogs, getConsoleErrors, getNetworkLogs, getNetworkErrors, takeScreenshot

这将返回以下 MCP 响应：

深入反思所有这些，并思考为什么它不起作用。 推测 4-6 种不同的可能问题来源。

## 可用工具
根据需要使用这些工具来完成用户的请求：

- getConsoleLogs
- getConsoleErrors
- getNetworkLogs
- getNetworkErrors
- takeScreenshot

使用每个工具后，返回一个“后续步骤”部分，其中包含要采取的后续步骤/要调用的剩余工具的列表，以及每个工具的提示/描述和“可选”标志（如果存在）。

参数注入

一个强大的功能是能够使用 {{ parameter_name }} 语法将参数注入到您的提示中：

custom_mode:
  description: "具有参数注入的 Workflow"
  parameters:
    thought:
      type: "string"
      description: "要深入反思的想法"
      required: true
    idea:
      type: "string"
      description: "要考虑的附加想法"
  prompt: |
    深入反思所提供的想法。
    这是想法：{{ thought }}

    要考虑的附加想法：{{ idea }}

    反思它可能对我的当前目标产生的影响/权衡。

参数会根据其类型定义自动验证，并在运行时注入到您的提示中。

顺序工具配置

在顺序模式下，工具按特定顺序执行：

web_debugger_mode:
  description: 使用浏览器日志和 BrowserTools MCP 调试我的代码库我的 Web 应用程序
  prompt: |
    深入反思所有这些，并思考为什么它不起作用。 推测 4-6 种不同的可能问题来源。
  toolMode: sequential
  tools: getConsoleLogs, getConsoleErrors, getNetworkLogs, getNetworkErrors, takeScreenshot

这将返回以下 MCP 响应：

深入反思所有这些，并思考为什么它不起作用。 推测 4-6 种不同的可能问题来源。

## 可用工具
如果已获得所有必需的用户输入/反馈，或者如果不需要输入/反馈，请执行以下工具序列以完成此任务：

1. getConsoleLogs
2. getConsoleErrors
3. getNetworkLogs
4. getNetworkErrors
5. takeScreenshot

使用每个工具后，返回一个“后续步骤”部分，其中包含要采取的后续步骤/要调用的剩余工具的列表，以及每个工具的提示/描述和“可选”标志（如果存在）。

高级工具配置

包括为每个工具定义提示的能力，以及一个可选标志，用于指示该工具在序列中是否可选：

deep_thinking_mode:
  description: 反思一个想法并产生一个反思/一组新的想法
  parameters:
    thought:
      type: string
      description: 要深入反思的想法
      required: true
  prompt: |
    深入反思所提供的想法。
    反思它可能对我的当前目标、挑战和我们的对话产生的影响/权衡。
    不要更改我们系统中的任何内容，只需根据您对所提供想法的反思返回一些想法/考虑/分析。
  toolMode: "sequential"
  tools:
    analyze_thought: 分析先前产生的想法
    explore_perspectives: 考虑给定分析的其他角度
    apply_findings:
      propmt: 实施分析的结果
      optional: true

配置结构

每个 YAML 文件应包含工具名称到其配置的映射。 可以从两个来源加载配置：

1. 内部预设（位于 presets 目录中）
2. 用户定义的配置（在 .workflows 或 .mcp-workflows 目录中）

基本工具配置

对于每个工具，您可以指定：

• name: 注册工具的可选名称覆盖（默认为配置键）
• description: workflow/工具的作用的描述
• prompt: 自定义提示（如果 workflow 名称也是一个活动的预设，则完全替换默认提示）
• context: 要附加到提示的附加上下文（不替换预设的默认提示）
• tools: 此模式下可用的工具的数组或对象，具有灵活的定义样式
• toolMode: 工具执行模式，可以是“sequential”或“situational”（默认为“situational”）
• parameters: 作为工具输入的参数的对象映射 - 支持使用 {{ parameter_name }} 进行模板注入
• disabled: 用于禁用工具的布尔值

输入参数配置

工具可以接受类型化的参数，MCP 客户端/代理可以提供这些参数，以提高您的提示/workflow 的推理能力。 这些输入会自动转换为 Zod 模式，以进行验证和类型安全。 每个参数都使用以下属性定义：

属性	描述	必需
type	数据类型：“string”、“number”、“boolean”、“array”、“object”或“enum”	是
description	参数的人类可读描述	否
required	参数是否必需	否（默认为 false）
default	如果未提供，则为默认值	否
enum	有效值的数组（仅 enum 类型需要）	是（对于 enum 类型）
items	对于数组类型，定义数组中项目的类型	否
properties	对于对象类型，定义对象的属性	否

示例输入参数类型

# 字符串参数
name:
  type: "string"
  description: "用户的姓名"
  required: true

# 具有默认值的数字参数
limit:
  type: "number"
  description: "要返回的最大项目数"
  default: 10

# 具有默认值的布尔参数
includeArchived:
  type: "boolean"
  description: "包括已存档的项目"
  default: false

# 具有预定义选项的枚举参数
sortOrder:
  type: "enum"
  enum: ["asc", "desc"]
  description: "排序方向"
  default: "asc"

# 具有项目类型的数组参数
tags:
  type: "array"
  description: "要过滤的标签列表"
  items:
    type: "string"
    description: "标签值"

# 具有嵌套属性的对象参数
filters:
  type: "object"
  description: "复杂过滤器对象"
  properties:
    status:
      type: "enum"
      enum: ["active", "inactive", "pending"]
      description: "状态过滤器"
    dateRange:
      type: "object"
      properties:
        start:
          type: "string"
          description: "开始日期"
        end:
          type: "string"
          description: "结束日期"

配置加载

系统按以下顺序加载配置：

1. 来自 presets 目录的内部预设
2. 来自 .workflows 或 .mcp-workflows 目录的用户定义的配置
3. 合并配置，用户定义的设置优先

合并配置时：

• 工具数组是连接而不是替换
• 其他属性被用户定义的配置覆盖
• 参数被合并，用户定义的参数优先

工作原理

Workflows MCP 通过复杂的配置和工具注册系统运行：

1. 配置加载和合并

   • 从 presets 目录中的内部 YAML 文件加载预设配置
   • 可选地从 .workflows 或 .mcp-workflows 目录加载用户定义的配置
   • 合并配置，用户配置优先于预设
   • 支持顺序和情境工具执行模式

2. 工具注册和验证

   • 每个工具都根据合并的配置动态注册到 MCP 服务器
   • 可以使用以下方式自定义工具：
     • 自定义名称和描述
     • 具有验证的类型化参数
     • 自定义提示或预设提示的扩展
     • 顺序或情境执行策略
   • 在注册时验证工具配置和参数

3. 参数处理

   • 使用类型安全的配置系统定义参数
   • 支持多种参数类型：string、number、boolean、array、object 和 enum
   • 自动将参数定义转换为 Zod 模式以进行运行时验证
   • 在工具执行期间提供参数值的自动验证

4. 提示管理

   • 通过灵活的系统管理提示，该系统支持：
     • 来自预设的默认提示
     • 用户定义的自定义提示
     • 附加上下文注入
     • 基于模式的动态工具可用性
   • 支持基于配置的静态和动态提示生成

5. 错误处理和调试

   • 在配置加载和工具执行期间进行全面的错误处理
   • 用于调试和故障排除的详细日志记录
   • 当配置或工具丢失时，进行优雅的回退
   • 运行时验证工具输入和配置

这种架构允许工具和客户端之间进行强大、类型安全的交互，同时通过配置驱动的自定义保持灵活性。

许可证

MIT