招聘协作助手

要解决什么问题

招聘流程里散落着大量重复操作：筛选候选人、同步状态、整理面试反馈，每一步都要在 Recruitee 里手工点击。脚本类方案要先拿到 API key、处理鉴权和分页，接入成本不低。这个技能换一条路：不直连 Recruitee 的 REST 接口，而是通过 Rube MCP 使用 Composio 现成的 Recruitee 工具包，把鉴权、请求构造和错误处理都交给 Composio 层完成。

技能如何工作

整个流程依赖 Rube MCP 暴露的几个工具，调用顺序是固定的：

1. 发现工具：任何工作流开始前都要先调用 RUBE_SEARCH_TOOLS，拿回当前可用的 tool slug、输入 schema 和推荐执行计划。工具 schema 会变，所以不能硬编码参数。
2. 检查连接：用 RUBE_MANAGE_CONNECTIONS（指定 toolkit recruitee）确认 Recruitee 连接状态。如果不是 ACTIVE，按返回的授权链接完成配置，状态确认 ACTIVE 后才能跑后续操作。
3. 执行任务：用 RUBE_MULTI_EXECUTE_TOOL 按发现到的 slug 执行单个或多个操作；批量场景可以走 RUBE_REMOTE_WORKBENCH 里的 run_composio_tool()。需要完整 schema 时用 RUBE_GET_TOOL_SCHEMAS 兜底。

Rube MCP 本身不需要 API key，在客户端配置里加上 https://rube.app/mcp 这个 endpoint 就能用，连接 Recruitee 的授权步骤由工具包引导完成。

适用边界与注意点

几个容易踩的坑值得单独列出来：

• 永远先搜索：schema 会变，不调用 RUBE_SEARCH_TOOLS 就写参数等于埋雷。
• 先查连接再执行：跳过连接检查直接跑工具，失败时很难区分是授权问题还是参数问题。
• 严格按 schema 传参：字段名和类型以搜索结果为准，别自己猜。
• memory 参数不能省：即使为空也要传 {}，这是 RUBE_MULTI_EXECUTE_TOOL 的硬性要求。
• session 复用：同一个工作流内复用 session ID，新工作流才生成新的。
• 翻页要拉到底：响应里出现分页 token 就要继续请求，否则结果不完整。

适合的场景是可重复、有明确步骤的招聘操作自动化。如果需要跨多个系统做复杂编排，或者对延迟有严格要求，这个走 MCP 中转的链路未必合适。