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

本指南以 awesome-claude-skills 仓库中的 kraken-io-automation 技能包为核心，讲解如何通过 Composio 的 Rube MCP 让 Claude 直接调用 Kraken IO 工具包完成真实操作。读完本文，你将掌握 Rube MCP 的接入方式、工具发现（RUBE_SEARCH_TOOLS）、连接管理（RUBE_MANAGE_CONNECTIONS）与批量执行（RUBE_MULTI_EXECUTE_TOOL）的完整调用模式，并能避开 schema 漂移、连接状态校验等常见陷阱。

Skill 概览：一个围绕"先搜索、再执行"设计的自动化技能

该 Skill 位于仓库的composio-skills/kraken-io-automation/目录，其 SKILL.md 通过 YAML frontmatter 声明了三个关键字段：

--- name: kraken-io-automation description: "Automate Kraken IO tasks via Rube MCP (Composio). Always search tools first for current schemas." requires: mcp: [rube] ---

• name：Skill 的标识符，供 Agent 会话启动时识别；
• description：最重要的元数据。它除了概括功能（"通过 Rube MCP 自动化 Kraken IO 任务"），还强制约定了一条纪律——"Always search tools first for current schemas"（永远先搜索工具以获取最新 schema）。会话启动时 Agent 只读取这段描述来判断是否加载该 Skill（详见 README.md 对 Skills 渐进式加载机制的解释），因此这条纪律会被第一时间注入 Agent 的行为准则；
• requires：声明该 Skill 依赖名为rube的 MCP 服务器，也就是 Composio 提供的 Rube MCP 端点。

从仓库定位看，该 Skill 属于 README.md 中"App Automation via Composio"分类下的预置工作流技能之一。README 明确说明：这类技能包含工具序列、参数指引、已知陷阱与快速参考表，且全部使用从 Composio API 实际发现（discovered）的工具 slug，而非凭空编造——这正是本 Skill 反复强调"先搜索"的根本原因。

前置条件：接入前的三项检查

在执行任何 Kraken IO 工作流之前，必须满足以下条件（见原文档 Prerequisites 部分）：

1. Rube MCP 已连接：确认RUBE_SEARCH_TOOLS工具可用。它是整个自动化链路的第一环，也是验证 Rube MCP 是否就绪的探针；
2. Kraken IO 连接已激活：通过RUBE_MANAGE_CONNECTIONS以 toolkitkraken_io建立连接，且状态必须为 ACTIVE；
3. 每次执行前先调用RUBE_SEARCH_TOOLS：这是本 Skill 的强制性规范，因为工具 schema 会随服务端迭代而变化，硬编码工具 slug 或参数必然导致执行失败。

值得注意的是，条件 2 中的连接建立并不需要传统意义上的"应用内授权页面"之外的特殊处理——如果连接未激活，RUBE_MANAGE_CONNECTIONS会返回授权链接，完成授权后连接即持久化。这一机制与仓库中 connect/SKILL.md 描述的 Auth Flow 一致：首次使用某应用时由 Agent 引导用户完成授权，此后连接自动复用。

环境设置：三步接入 Rube MCP

Rube MCP 的接入极其轻量，原文档给出的方式是：

将https://rube.app/mcp添加为客户端配置中的 MCP 服务器端点即可，无需任何 API Key——添加端点后即可工作。

（这里的rube.app/mcp是客户端配置值，而非需跳转访问的文档链接。）

接入后按以下顺序完成验证（对应原文档 Setup 部分）：

1. 调用RUBE_SEARCH_TOOLS确认 Rube MCP 已就绪并正常响应；
2. 调用RUBE_MANAGE_CONNECTIONS，指定 toolkit 为kraken_io；
3. 若连接状态不是 ACTIVE，则跟随返回的授权链接完成设置；
4. 在运行任何工作流之前，确认连接状态显示为ACTIVE。

这套"先验证 MCP、再建立连接、最后确认状态"的次序，可以理解为 Rube MCP 内部沿用了 Composio Tool Router 的经典链路——用户提出诉求 → 路由器匹配 1000+ 工具 → 自动处理 OAuth → 执行动作并返回结果（对应 connect/SKILL.md 的 How It Works 说明）。对 Kraken IO 这类工具包而言，连接状态 ACTIVE 意味着工具包内所有工具已具备合法的调用凭证。

工具发现：为什么"永远先搜索"是最高优先级

原文档在 Tool Discovery 一节给出了标准的发现调用：

RUBE_SEARCH_TOOLS queries: [{use_case: "Kraken IO operations", known_fields: ""}] session: {generate_id: true}

一次成功调用会返回四类信息：

• 可用的工具 slug（tool slugs）：即后续执行阶段要填写的工具标识；
• 输入 schema：每个工具参数的字段名、类型与必填性；
• 推荐的执行计划：针对该 use case 的推荐调用序列；
• 已知陷阱（known pitfalls）：服务端维护的针对当前工具集的注意事项。

之所以把"搜索"置于所有流程之前，是因为工具 schema 是动态变化的：Composio 会根据上游 API 演进不断调整工具签名。原文档在 Known Pitfalls 中明确警告："Tool schemas change. Never hardcode tool slugs or arguments without callingRUBE_SEARCH_TOOLS"——任何不经过搜索而直接写死的工具 slug 或参数，都可能在下次执行时因 schema 变更而失败。这与仓库 README 中"使用从 Composio API 实际发现的工具 slug"的定位完全吻合。

核心工作流：发现 → 校验 → 执行的三阶段模式

原文档将 Kraken IO 自动化收敛为一个可复用的三阶段模式，适用于该 Skill 覆盖的任意具体任务。

Step 1：发现可用工具

RUBE_SEARCH_TOOLS queries: [{use_case: "your specific Kraken IO task"}] session: {id: "existing_session_id"}

把 use case 替换为你的具体任务描述（如"批量压缩图片"或你实际需要的 Kraken IO 操作），并复用工作流内已有的 session id。

Step 2：检查连接

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

在执行工具前，确认kraken_io工具包对应连接为 ACTIVE。若未激活，先完成授权再继续。

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"

RUBE_MULTI_EXECUTE_TOOL是本工作流的执行中枢，其参数要点：

• tools：数组，每个元素包含tool_slug（来自 Step 1 的搜索结果）与arguments（必须严格符合 Step 1 返回的 schema——字段名、类型、必填项逐一对齐）；
• memory：必须始终携带，即使为空也要传{}，它是多步任务状态传递的载体；
• session_id：贯穿工作流全程，用于串联发现、连接校验与执行各阶段。

已知陷阱：六个必须遵守的执行纪律

原文档的 Known Pitfalls 部分给出了六条实战纪律，逐条展开如下：

1. 永远先搜索：工具 schema 随时可能变化。未经RUBE_SEARCH_TOOLS就硬编码工具 slug 或参数，是这类自动化任务最常见的失败原因；
2. 检查连接：执行工具前必须通过RUBE_MANAGE_CONNECTIONS确认 ACTIVE 状态，避免因凭证失效产生鉴权类错误；
3. Schema 合规：arguments必须使用搜索结果中给出的精确字段名与类型，多字段、少字段、类型不符都会导致调用失败；
4. Memory 参数必带：RUBE_MULTI_EXECUTE_TOOL调用中始终包含memory，即使内容为空（{}）也不可省略；
5. 会话复用：同一工作流内复用 session ID（各步骤保持一致），新工作流再生成新 ID——这与 Step 1 中的session: {id: "existing_session_id"}相呼应；
6. 分页处理：检查响应中的分页 token，持续拉取直到数据取完，否则会遗漏后续页结果。

这六条纪律不仅适用于 Kraken IO，也适用于仓库内全部 78 个同类自动化 Skill——例如 composio-automation 的文档采用了完全一致的框架与措辞，说明这是 Composio 预置 Skill 的通用执行准则。

快速参考：五种操作的一句话索引

原文档以表格形式给出了五种核心操作的调用入口，整理如下：

其中"批量操作"与"获取完整 schema"是前三条主线之外的进阶能力：前者用于需要远程工作台编排的批量场景，后者用于搜索结果中仅含schemaRef引用、需要拉取完整 schema 定义的工具。

从 Skill 到能力的延伸：与仓库其他模块的关系

理解本 Skill 的定位，还可以对照仓库的两处上下文：

• 通用连接能力：connect/SKILL.md 提供了"让 Claude 真正执行操作"的通用方案（发送邮件、建 Issue、发 Slack 等），而kraken-io-automation是这一理念在单一应用（Kraken IO）上的深度定制——它不再依赖自然语言路由，而是给出确定性的工具序列与参数纪律；
• 同类模板：README 中"App Automation via Composio"分类下的 78 个预置 Skill（如 composio-automation）结构完全同构，理解本文的三阶段工作流，即可举一反三地使用该分类下的任意 Skill。

在 Claude 的三大分层（MCP 负责访问、工具负责动作、Skill 负责行为）中，本 Skill 属于典型的行为层：Rube MCP 已替你解决连接与发现，Skill 则把"先搜索 → 校验连接 → 按 schema 执行 → 处理分页"这套行为准则固化下来。按原文档的说明（Toolkit docs 指向 Composio 的 Kraken IO 工具包页面）可进一步查阅 Kraken IO 工具包支持的具体操作清单，具体工具能力以搜索返回的实时 schema 为准。

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