技能介绍

解决什么问题

团队在做外联或客户调研时，常需要根据域名批量找出公司邮箱、验证某个地址是否真实可达，或者在不切换多个工具的情况下拿到一家公司的技术栈和联系人属性。过去的做法是打开 Tomba 网页手动搜索，再复制粘贴到 CRM 或邮件工具里，数据流转断裂，也没法沉淀成自动化流程。

这个技能通过 OOMOL 连接器把 Tomba 的 10 个查询动作（domain_search、email_finder、email_verifier、enrich、search_companies、technology 等）暴露给 oo CLI，让 Agent 在对话里就能完成「搜索域名邮箱 → 验证可达性 → 富集联系人属性」这类链条式操作，无需离开当前环境。

如何工作

核心思路是凭据服务端托管。OOMOL 在服务端注入 Tomba 的 API 密钥，本地不会拿到原始 token，也就没有密钥存储、轮换和泄漏的维护成本。

每次调用遵循固定流程：

先用 oo connector schema 拉取目标 action 的输入输出契约，确认必填字段再构造 payload；
用 oo action run --data 传入 JSON，参数可内联或走 @path/to/file.json；
响应统一为 { "data": ..., "meta": { "executionId": "..." } }，执行 ID 在 meta.executionId 里；
只有命令真正报认证或连接错误时，才回退到一次性初始化（登录 OOMOL、用 API key 方式连接 Tomba），而不是每次调用都走一遍配置。

各 action 的详细说明在各自的参考文件里：email_finder 按域名和姓名推测最可能的职业邮箱，email_sources 返回 Tomba 发现该邮箱的公开来源 URL，get_account 用来确认当前账号状态。

适用边界

动作分两类风险：get / list / search 类只读动作可直接执行；create / update / send / post 类会改变 Tomba 侧状态，必须与用户确认 payload 和影响后再运行；delete / remove 类破坏性操作需要明确的二次确认。
数据质量依赖 Tomba 的覆盖面：邮箱验证和公司情报来自其公开数据积累，冷门域名可能返回稀疏或空结果。
托管带来便利也带来依赖：凭据由 OOMOL 服务端注入，调用链路依赖 OOMOL 服务可用性；遇到 OOMOL_INSUFFICIENT_CREDIT 时需要先充值才能继续。