• AI 技能
• AI 插件
• 人工智能
• 工作流自动化

导读

Control D 是一个可编程的 DNS 防火墙 / 内容过滤平台，用于按设备管理网络流量过滤策略。在 awesome-claude-skills 仓库中，control-d-automation 是一份预置的 Claude Skill，它通过 Composio 提供的 Control D toolkit 与 Rube MCP 服务器，让 Claude 可以直接执行 DNS 配置、规则管理、过滤策略调整等真实操作，而不是只生成文字建议。读完本文，你将掌握这套 Skill 的完整使用流程：如何接入 Rube MCP、如何发现当前可用的工具 schema、如何建立并校验 Control D 连接，以及如何用标准三步工作流稳定地执行工具调用并规避常见踩坑点。

Skill 是什么：定位与元数据

control-d-automation是仓库中composio-skills/目录下的一个 Skill 目录，其入口文件为 SKILL.md。文件头部使用 YAML frontmatter 声明元数据：

--- name: control-d-automation description: "Automate Control D tasks via Rube MCP (Composio). Always search tools first for current schemas." requires: mcp: [rube] ---

三个字段各有明确含义：

• name：Skill 的唯一标识，用于在 Claude Code / Claude.ai 中按名称加载；
• description：Agent 在会话启动时最先看到的摘要（约百 token），它直接决定了 Agent 判断"何时激活该 Skill"——这里特意强调Always search tools first（始终先搜索工具 schema），这是整套 workflow 的第一原则；
• requires.mcp：声明该 Skill 依赖名为rube的 MCP 服务器。与 connect/SKILL.md 中通过 API key 直连 Composio Tool Router 的方式不同，本 Skill 走的是 Rube MCP 这一中间层：MCP 负责访问与认证，Skill 负责定义"先搜索、再连接、后执行"的行为流程，二者分工明确。

需要说明的是：Skill 本身不是 MCP 服务器，也不是工具。它是一份可复用的行为规范（instruction package），告诉 Agent 在拥有连接和工具之后"按什么顺序、以什么方式"做事。这正是 README.md 中阐述的"三层模型"：MCP 管访问、工具管动作、Skill 管行为。

前置条件：三条硬性要求

在运行任何 Control D 工作流之前，必须确认以下前提（原文完整列出，逐条展开）：

1. Rube MCP 已连接：RUBE_SEARCH_TOOLS可用。这是发现工具、读取 schema 的唯一入口；
2. Control D 连接处于 ACTIVE 状态：通过RUBE_MANAGE_CONNECTIONS建立，toolkit 参数固定为control_d；
3. 永远先调用RUBE_SEARCH_TOOLS：工具的 slug 与参数 schema 会随 Composio API 更新而变化，绝不能凭记忆硬编码。

这三条是"搜索优先（search-first）"哲学的具体化：连接解决"能否访问"，搜索解决"调什么、怎么调"，执行解决"真正干活"。

环境搭建：接入 Rube MCP

Setup 部分非常简单，原文给出核心步骤：

Get Rube MCP: Addhttps://rube.app/mcpas an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.

即在你的 MCP 客户端配置中，将https://rube.app/mcp添加为一个 MCP server 端点，无需任何 API key，添加即用。之后按序完成四步初始化：

1. 验证 Rube MCP 可用：确认RUBE_SEARCH_TOOLS有响应；
2. 调用RUBE_MANAGE_CONNECTIONS，toolkit 传control_d；
3. 若连接状态不是ACTIVE，跟随返回的 auth 链接完成 OAuth / 授权流程；
4. 在运行任何工作流之前，再次确认连接状态为ACTIVE。

第 3 步的"auth 链接"是首次使用某个 app 时的标准授权动作——这与 connect/SKILL.md 中描述的 Auth Flow 一致：Agent 弹出授权链接，用户完成授权后连接长期保持，后续无需重复认证。

工具发现：永远先搜 schema

执行任何工作流之前，先做工具发现。原文给出标准请求：

RUBE_SEARCH_TOOLS queries: [{use_case: "Control D operations", known_fields: ""}] session: {generate_id: true}

该调用会返回四类信息：

• 可用的工具 slug（tool slugs）；
• 输入 schema（input schemas）；
• 推荐执行计划（recommended execution plans）；
• 已知坑位（known pitfalls）。

其中session: {generate_id: true}表示新建一个会话 ID 供本次工作流复用；use_case用自然语言描述你要做的事，例如查询具体任务时写作"your specific Control D task"（如"add a DNS rule"、"list config profiles"），known_fields留空即可。

从源码结构看，composio-skills/目录下 80+ 个 SaaS 自动化 Skill（composio-automation、composio-search-automation 等）共享完全相同的"先搜索"骨架，可见这是一套标准化范式而非个别文档的偶然写法。

核心工作流：标准三步模式

这是整个 Skill 的灵魂部分，原文给出了完整的三步调用序列，下面逐段展开并补充参数说明。

Step 1：发现可用工具

RUBE_SEARCH_TOOLS queries: [{use_case: "your specific Control D task"}] session: {id: "existing_session_id"}

与初始化阶段的区别在于：这里复用已有会话（existing_session_id），而不是generate_id。会话复用保证同一工作流内的多次调用共享上下文，便于 Agent 记住已发现的结果。

Step 2：检查连接

RUBE_MANAGE_CONNECTIONS toolkits: ["control_d"] session_id: "your_session_id"

toolkits是数组类型，传入["control_d"]精确指定目标 toolkit。该调用返回连接状态；若显示非ACTIVE，须回到 Setup 第 3 步完成授权后再继续。这是防止"工具已发现、连接已过期"导致执行失败的关键防线。

Step 3：执行工具

RUBE_MULTI_EXECUTE_TOOL tools: [{ tool_slug: "TOOL_SLUG_FROM_SEARCH", arguments: {/* schema-compliant args from search results */} }] memory: {} session_id: "your_session_id"

三个字段逐一说明：

• tool_slug：必须是 Step 1 搜索结果中返回的真实 slug（如control_d_add_rule之类的实际值，以搜索返回为准），禁止硬编码；
• arguments：必须严格符合搜索结果返回的 schema——字段名、类型、必填项都要与 schema 一致，多一个字段或少一个必填项都可能导致调用失败；
• memory：必须始终包含，即使为空也要传{}，这是 Skill 明确要求的调用约定；
• session_id：继续复用同一会话 ID。

RUBE_MULTI_EXECUTE_TOOL支持一次调用批量执行多个工具（tools是数组），适合"查规则 + 改配置 + 验证结果"这类复合任务。如果你需要更深层的 schema（工具通过schemaRef引用外部 schema 定义），可以用RUBE_GET_TOOL_SCHEMAS拉取完整定义；如果需要批量/远端执行，则使用RUBE_REMOTE_WORKBENCH并调用run_composio_tool()——这两者都出现在文末的 Quick Reference 表中。

已知坑位（Known Pitfalls）：六条实战纪律

原文的坑位清单是长期实践沉淀，每一条都对应一次真实失败场景，逐条保留并补充因果说明：

1. 永远先搜索（Always search first）：工具 schema 会变化。不调用RUBE_SEARCH_TOOLS就硬编码 slug 或参数，是最大的失败来源。因为 Composio API 的工具定义会随上游更新，昨天的参数今天可能就是非法字段；
2. 检查连接（Check connection）：执行前必须通过RUBE_MANAGE_CONNECTIONS确认状态为ACTIVE。OAuth token 可能过期、用户可能撤销授权，未检查就执行会导致静默失败；
3. Schema 合规（Schema compliance）：使用搜索结果中的精确字段名和类型。多传、少传、类型不符都会触发校验错误；
4. Memory 参数：RUBE_MULTI_EXECUTE_TOOL调用中始终携带memory，即使内容为空也要传{}，缺失该字段可能导致请求被拒；
5. 会话复用（Session reuse）：同一工作流内复用 session ID（保持上下文连续），新工作流再生成新 ID（避免上下文串扰）；
6. 分页（Pagination）：检查响应中的分页 token，若结果未取完需继续翻页拉取，直到数据完整——尤其适用于"列出所有规则/配置"这类返回量大的操作。

这六条与"搜索优先 + 连接校验 + schema 合规"一脉相承，构成可复制的稳健执行范式。

快速参考表：四种操作的对应工具

使用建议：

• 日常单任务（增删一条规则、查询配置）：走前三行，即"搜索 → 连接 → 执行"三步；
• 批量任务（批量更新多设备策略）：切换到RUBE_REMOTE_WORKBENCH+run_composio_tool()，在远端工作台中循环执行；
• 深度集成（需要完整 JSON schema 做严格校验）：用RUBE_GET_TOOL_SCHEMAS展开schemaRef引用的完整定义。

生态定位：它不是一个孤立文档

control-d-automation是仓库中大规模"App Automation via Composio"体系的一员。README.md 明确说明：composio-skills/下预置了 78 个 SaaS 应用的 workflow skill，每个都包含工具序列、参数指引、已知坑位和快速参考表，并且"全部使用从 Composio API 实际发现（discovered）的真实工具 slug"——这解释了为什么本 Skill 反复强调搜索优先：slug 来自 API 运行时发现，而非静态文档。

横向对比可见同一骨架被反复复用：composio-automation 针对 Composio 自身 toolkit、composio-search-automation 针对 Composio Search toolkit，二者与本 Skill 结构完全一致，仅use_case、toolkits参数与表格措辞不同。这意味着你掌握本文的三步工作流后，可以零成本迁移到其他 77 个 Skill；反过来，这也印证了"先搜索 → 查连接 → 执行"是本仓库认可的通用自动化范式。

若你想把该 Skill 安装进 Claude Code，可遵循 README.md 的标准流程：将control-d-automation目录复制到~/.config/claude-code/skills/下，用head ~/.config/claude-code/skills/control-d-automation/SKILL.md校验元数据，再启动claude即可自动加载。Skill 采用渐进式加载，会话开始时只暴露名称与描述，正文在判定相关时才完整载入，因此同时挂载几十个此类 Skill 也不会撑爆上下文窗口。

小结

Control D 自动化 Skill 的价值在于把"搜索优先、连接校验、schema 合规、会话复用"这套纪律固化成可执行规范。接入时只需在 MCP 客户端配置中添加https://rube.app/mcp端点，无需 API key；使用时严格遵循RUBE_SEARCH_TOOLS（发现）→RUBE_MANAGE_CONNECTIONS（连接）→RUBE_MULTI_EXECUTE_TOOL（执行）三步，并守住六条坑位纪律，就能让 Claude 稳定、可复现地完成 Control D 的 DNS 过滤与配置管理任务。这套模式在仓库 78 个 composio Skills 中完全通用，掌握其一，即可触类旁通。

• AI 技能
• AI 插件
• 人工智能
• 工作流自动化