mcpField
M
make-scenario-operations

make-scenario-operations

github.com/integromat其他15639 次安装今天更新
代码仓库

关于 make-scenario-operations

make-scenario-operations 是用于运行和排查现有 Make 场景的技能,面向管理自动化流程的用户。它说明如何按触发器类型运行场景、检查执行历史、定位模块故障及调查 Webhook 投递。

主要功能

  1. 01按触发器类型运行场景
  2. 02启用或停用场景
  3. 03查看执行历史与输出
  4. 04追踪模块级故障
  5. 05检查 Webhook 投递与载荷

适用场景

  1. 01确认场景是否执行完成
  2. 02定位导致故障的模块
  3. 03排查 Webhook 数据未处理的原因
  4. 04捕获 Webhook 请求结构

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/integromat/make-skills --skill make-scenario-operations

安装后在 Claude Code 中输入/make-scenario-operations确认已加载。

详细介绍

Make 场景 — 运行与调试

场景创建完成后的所有操作:运行、启用或停用,以及失败时的「运行 → 检查 → 深入排查」流程。调用 scenario_run 前,先了解 trigger.kind(来自 scenario_get)——它完全决定了运行行为。

基本规则。 403 表示必须重新授权整个连接,并授予所有权限——绝不能只授权某个工具。结果中的 content 说明是指令,不是装饰。在执行操作的调用前,先说明你如何将有歧义的值解释为具体值。拒绝约定及其他内容:遇到操作被拒绝,或似乎没有合适工具时,请参阅 make-scenario-reference。

运行:scenario_run

  • 按需运行 — 使用以已声明的输入名称为键的 inputs 运行,并返回已声明的输出。
  • 轮询 / 计划运行 — 立即运行一次;不接受 inputs,也不会返回任何内容;运行记录会写入历史记录。
  • webhook — 不会运行任何内容。响应会返回 webhook URL(或指出应用事件)。不要声称场景已「运行」;请让用户发送真实请求,然后检查 scenario_execution_list。

非活动场景会拒绝运行,并提示调用 scenario_activate——新场景默认处于非活动状态。"pending" 状态表示运行耗时超过等待时间:请使用 executionId 检查 scenario_execution_get,不要假定运行失败。若某个 inputs 键被拒绝,返回内容会指出已声明的接口——请先阅读,不要再次猜测。传入没有接口的场景的输入会被静默忽略;说明会指出这一点——请转告用户。

启用与停用

这是两个独立工具;如果请求的状态已经满足,也算成功,不是错误。启用操作被拒绝,几乎总是因为某个模块仍存在配置错误——scenario_get 中每个模块的 issues 会指出具体问题。

历史记录:scenario_execution_list → scenario_execution_get

对于失败的运行,列表会直接包含 errorMessage——通常无需再次调用,就足以回答「是否成功、为什么失败」。刚刚启动的运行可能要过几秒才会出现在列表中(说明会提示这一点;并非数据丢失)。scenario_execution_get 用于查看单次运行的结果、输出和消耗量(点数与字节数——这是用量单位,不是金额);它不提供逐模块明细,因此可以回答「是否完成」,但不能回答「哪个模块出错」。只有当用户需要呈现为时间线或卡片时,才使用对应的 _show 工具。

调试失败的运行:scenario_execution_inspect → scenario_execution_module_get

  1. scenario_execution_inspect — 返回总体状态和错误,以及所有已运行模块的调用次数和错误次数。Make 每次运行只记录 一条 错误(导致运行终止的那条);其他故障只显示为 errorCycles 计数。警告状态的运行不会包含顶层 error——只有 modules[].errors 能表明存在问题,因此绝不要把「未发现错误」报告成「一切正常」。
  2. 对可疑模块和 inspect 报告的 cycle(通常为 1)调用 scenario_execution_module_get — 查看该模块实际收到的输入和产生的输出。绝不要自行选择 cycle;错误的 cycle 会返回无关数据,且不会发出警告。
  3. 使用 scenario_module_get 对照当前 config——但要先比较 scenario_get 的 lastEdit 和运行的 startedAt。如果场景是在运行后编辑的,你读取的配置不一定是运行时使用的配置;在将问题归因于配置前,请先说明这一点。

…[truncated] 表示载荷被截断——它是文本,不是要解析的 JSON。没有下游使用方(ReturnData、WebhookRespond、抛出错误)的模块,在此处始终会报告空输出,即使运行正确也是如此;场景自身的输出位于 scenario_execution_get 的 outputs 中。

“Webhook 没有收到数据”

  • 先使用 scenario_trigger_inspect:它会报告 queued 投递项,即因场景未激活、已暂停或受到速率限制而存储并等待处理的请求。queued.count 非零,比映射出错更常能解释“我发送了数据,却什么也没发生”。它还会显示检测到的结构和近期投递项;提供 deliveryId 后,还会显示一条原始请求。
  • scenario_trigger_learn 会让 Webhook 进入学习模式:捕获下一个请求作为结构,但不会运行场景(对已激活的场景也安全)。将 URL 提供给用户,并让他们发送一个真实请求。

对于被隐去的载荷(机密或共享 Webhook、大小超过 1 MB 的请求体、二进制内容),系统会用占位符替代,并在备注中说明,而不是显示“什么也没收到”。

此处不涉及

  • 编辑场景以修复发现的问题——make-scenario-building。
  • 不运行场景,只解释场景——make-scenario-explore。

评论

支持 Markdown