Codex 技能实战：通过 Rube MCP 自动化 Dictionary API 词典查询（awesome-codex-skills）

Codex 技能实战：通过 Rube MCP 自动化 Dictionary API 词典查询（awesome-codex-skills）

【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills

本篇基于 composio-skills/dictionary-api-automation/SKILL.md 讲解 awesome-codex-skills 仓库中 Dictionary API 自动化技能的完整落地方法：如何连接 Rube MCP、完成dictionary_api工具包的授权、执行“先发现工具、再查连接、后执行”的三步工作流。读完本文，你可以把词典查询类任务（查词义、查发音、拼写与词性信息）接入 Codex CLI，并理解每条“必须搜索后再执行”约束背后的原因。

技能在仓库中的定位

awesome-codex-skills 是一个 Codex 技能精选仓库：每个技能是一个独立目录，目录下的SKILL.md包含 YAML frontmatter（name+description）与执行步骤，Codex 依据description元数据决定是否触发该技能，触发后才加载正文，以保持上下文精简（见 README.md 中 “What Are Codex Skills?” 一节）。

本技能位于 composio-skills/dictionary-api-automation/SKILL.md，frontmatter 如下：

name: dictionary-api-automation description: "Automate Dictionary API tasks via Rube MCP (Composio). Always search tools first for current schemas." requires: mcp: [rube]

• description明确了两件事：技能通过 Rube MCP（Composio 出品）自动化 Dictionary API 任务；并且要求“始终先搜索工具以获取最新 schema”。这句话直接对应后文的 Known Pitfalls。
• requires: mcp: [rube]声明了该技能对 Rube MCP 服务的硬依赖。

从仓库结构看，composio-skills/ 目录下按字母序排列着 800 余个*-automation技能目录，每个目录只含一个SKILL.md。Dictionary API 技能与同目录下的其他 toolkit 技能（如 composio-automation/SKILL.md）采用同一套模板，两者逐节对应、仅 toolkit 标识（dictionary_api与composio）和use_case措辞不同。这提示读者：本文沉淀的工作流（工具发现 → 连接检查 → 工具执行 → 会话与分页处理）同样适用于仓库中其他 Composio toolkit 技能，而本文只深入 Dictionary API 这一具体场景。

前置条件（Prerequisites）

原文档列出的三条前置条件是后续所有步骤的验收标准：

1. Rube MCP 必须已连接，即RUBE_SEARCH_TOOLS工具可被调用；
2. 已通过RUBE_MANAGE_CONNECTIONS建立 toolkit 为dictionary_api的活跃连接；
3. 在执行任何工作流前，必须先调用RUBE_SEARCH_TOOLS获取当前工具 schema。

第三条值得强调：它不是可选建议，而是整个技能的核心纪律——工具 schema 会随服务端演进变化，硬编码 slug 或参数名随时可能失效。

Setup：接入 Rube MCP 并建立 dictionary_api 连接

接入步骤（SKILL.md “Setup” 一节，约 SKILL.md#L20-L27）：

Get Rube MCP：在客户端的 MCP 配置中加入服务端点https://rube.app/mcp。该端点无需 API key——添加后即可工作。

随后按顺序完成 4 个动作：

1. 确认RUBE_SEARCH_TOOLS有响应，以此验证 Rube MCP 可用；
2. 调用RUBE_MANAGE_CONNECTIONS，toolkit 参数传dictionary_api；
3. 若连接状态不是 ACTIVE，按返回的 auth 链接完成授权；
4. 在执行任何工作流之前，确认连接状态显示为 ACTIVE。

注意第 2 步 toolkit 标识的精确写法是dictionary_api（下划线），后续所有toolkits数组中都必须保持这一字面量，写成dictionary-api或dictionaryApi都不符合文档约定。

工具发现：RUBE_SEARCH_TOOLS 的标准调用

“Tool Discovery” 一节给出的标准调用形如下面这样：

RUBE_SEARCH_TOOLS queries: [{use_case: "Dictionary API operations", known_fields: ""}] session: {generate_id: true}

要点解析：

• queries[].use_case用自然语言描述本次要做什么（词典操作场景即 “Dictionary API operations”），known_fields可留空字符串；
• session: {generate_id: true}让服务端生成一个新的会话 ID，后续步骤会复用它；
• 返回内容包含四部分：可用工具 slug（tool slugs）、输入 schema、推荐执行计划（recommended execution plans）、已知陷阱（known pitfalls）。

“先搜索再执行”的意义就在这份返回里：工具的真实字段名、类型、枚举值都以本次返回为准，而不是以本文或任何旧文档为准。

核心工作流：三步完成一次词典自动化

原文档的 “Core Workflow Pattern” 定义了 3 个步骤，以下代码块与原文完全一致。

Step 1：发现可用工具

RUBE_SEARCH_TOOLS queries: [{use_case: "your specific Dictionary API task"}] session: {id: "existing_session_id"}

与“Tool Discovery”一节相比，这里把session从generate_id: true改为id: "existing_session_id"——同一工作流内的多轮调用应复用同一会话，而不是每步都开新会话（见下文的 Session reuse 陷阱说明）。

Step 2：检查连接

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

toolkits是一个数组参数，批量检查时可放入多个 toolkit；本场景固定为["dictionary_api"]。执行任何工具前必须确认状态为 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"

三个关键约束：

• tool_slug必须来自 Step 1 搜索结果中的 slug 字面量，占位符TOOL_SLUG_FROM_SEARCH不可凭记忆填写；
• arguments必须严格符合搜索结果给出的 schema（字段名与类型逐字匹配）；
• memory参数必须出现，即使无内容也要显式传空对象{}——这是RUBE_MULTI_EXECUTE_TOOL的硬性要求。

工作流之外的两个补充通道

Quick Reference 中还提到了两个不在三步主流程里的能力，适合在批量与深度 schema 场景使用：

从模板化结构看，这两个通道在仓库全部 800 余个 composio-skills 技能中写法一致（每个 SKILL.md 的 Quick Reference 表都包含这两行），属于 Rube MCP 的通用能力，而非 Dictionary API 专属。

Known Pitfalls：六条陷阱的逐条解读

原文档列出的 6 条陷阱（约 SKILL.md#L71-L78）与 Quick Reference 一并构成可复用的执行清单：

1. Always search first（始终先搜索）：工具 schema 会变化，未经RUBE_SEARCH_TOOLS不得硬编码工具 slug 或参数。这是本技能的第一纪律，也是descriptionfrontmatter 里那句 “Always search tools first for current schemas” 的展开。
2. Check connection（先查连接）：执行工具前用RUBE_MANAGE_CONNECTIONS确认 ACTIVE 状态，避免在授权过期/失效时盲目调用。
3. Schema compliance（schema 合规）：字段名与类型必须与搜索结果逐字一致，包括大小写和嵌套结构。
4. Memory parameter（memory 参数必传）：RUBE_MULTI_EXECUTE_TOOL每次调用都要带memory，空则传{}。遗漏该参数是模板里显式标注的易错点。
5. Session reuse（会话复用）：同一工作流内复用 session ID；开启新工作流时再生成新 ID。这与 Step 1 中session: {id: "existing_session_id"}的写法相互印证。
6. Pagination（分页）：检查响应中的分页 token，循环拉取直到取完。对词典场景而言，如果一个词存在多个义项条目或服务端分页返回时，这一点尤其容易遗漏。

Quick Reference 速查表

继承原文档的速查表（操作 → 手段）：

如何把这个技能装进 Codex

按 README.md 的 Quickstart，技能有两种安装方式，装完后重启 Codex 才会加载新元数据：

方式一：使用仓库自带的安装脚本（推荐）。该脚本位于 skill-installer/scripts/install-skill-from-github.py，会把指定路径的技能抓取并放到$CODEX_HOME/skills/<skill-name>（默认~/.codex/skills）：

git clone https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills cd awesome-codex-skills python skill-installer/scripts/install-skill-from-github.py --repo ComposioHQ/awesome-codex-skills --path composio-skills/dictionary-api-automation

方式二：手动安装，把技能目录（本例为composio-skills/dictionary-api-automation）复制到$CODEX_HOME/skills/，再重启 Codex。

安装后的日常使用方式：在会话中自然描述任务（例如“查一下这个词的定义和发音”），Codex 会依据description元数据自动匹配并触发本技能；也可以直接提及技能名dictionary-api-automation。验证安装可执行ls ~/.codex/skills并head ~/.codex/skills/dictionary-api-automation/SKILL.md查看 frontmatter。

需要说明的是：技能文件只是“说明书”，真正执行查询动作的是 Rube MCP 背后的 Composio 网关。因此除了 Codex 侧的安装，运行时还依赖 Setup 一节中https://rube.app/mcp端点可用，且dictionary_api连接处于 ACTIVE 状态；两者缺一不可。

适用前提与小结

• 本技能适用于任何支持 MCP 的 Codex 客户端环境，前提是网络可访问 Rube MCP 端点并完成dictionary_api工具包授权；
• 本技能不包含本地脚本与配置参数（目录内仅有SKILL.md），所有行为参数都由 Rube MCP 服务端实时提供——这正是“schema 以搜索结果为准”这一设计的根源；
• 同一套“发现 → 连接 → 执行”模式在 composio-skills/ 下的其他 800 余个 toolkit 技能中通用，本文以 Dictionary API 为样例完整走了一遍，读者可将其作为该类技能的通用参考实现。

【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills