电话跟进助手

它解决什么问题

团队用 Callingly 做电话跟进时，典型流程是：查一下某个客户该打什么电话、确认 Callingly 连接是否正常、然后调用接口执行动作。麻烦在于，这些操作散落在不同的工具里，工具的输入参数（schema）会随版本变化，硬编码 tool slug 和参数名很容易在升级后直接失效；连接状态也可能中途断开，导致工作流跑到一半失败。

这个技能把这件事收敛成一个稳定入口：所有操作都通过 Rube MCP 进行，由它对接 Composio 的 Callingly toolkit，你不需要自己维护 API Key 或参数细节。

它如何工作

技能的核心能力是把 Callingly 的操作变成三步标准流程，并且每一步都有明确校验：

• 工具发现：任何执行前都先调用 RUBE_SEARCH_TOOLS，拿到当前可用的工具列表、输入 schema、推荐执行计划和已知坑点。这样参数永远来自实时查询，而不是写死的旧结构。
• 连接检查：通过 RUBE_MANAGE_CONNECTIONS 配合 toolkit callingly 确认连接是否为 ACTIVE；如果不是，先按返回的授权链接完成授权，再继续。
• 工具执行：拿到搜索结果后，再用 RUBE_MULTI_EXECUTE_TOOL 按返回的 slug 和字段执行操作。

需要批量操作时可以用 RUBE_REMOTE_WORKBENCH 配合 run_composio_tool()；遇到带 schemaRef 的工具时，用 RUBE_GET_TOOL_SCHEMAS 拉取完整 schema。

使用边界与注意点

这个技能本身不实现 Callingly 的业务逻辑，它只是把请求可靠地路由到 Callingly 工具集。几个必须遵守的约束：

• 永远先搜索：不要在没调用 RUBE_SEARCH_TOOLS 的情况下假设工具名或参数结构。
• 状态前置校验：执行前确认连接是 ACTIVE，避免半途失败。
• 严格按 schema 传参：字段名和类型以搜索结果为准。
• memory 参数必传：即使传空对象 {} 也要带上。
• 会话复用：同一工作流内复用 session ID，新工作流才生成新的。
• 翻页要做完：响应里出现分页 token 时继续拉取，直到结果完整。