Make

Reads the valid values for one module field whose options come from the connected account — a spreadsheet, a channel, a folder, a pipeline. Call it for any field `module_spec` lists under `dynamicFields` before setting that field: those values are usually opaque ids that cannot be guessed from what the user says. When a field's options depend on other fields, set those first and pass them as `context`. Returns at most 25 options — narrow with `search` rather than expecting the rest.

module_options_get

Returns how to configure specific modules before wiring them into a scenario: every input field with its type and constraints, what the module outputs, and which connection or webhook it needs — including existing connections that already satisfy it, with their ids. Accepts several modules at once; spec the whole planned scenario in one call. Module identifiers come from `app_find` as "app:moduleName".

module_spec

Returns how one scenario is built: every module in flow order, how they are wired together, the conditions that gate them, what triggers the scenario, the connections it uses and whether they still work, and the inputs and outputs it declares. Enough to explain what the scenario does. Requires a scenarioId — get one from `scenario_list`. It does not include how each module is configured: for a module's parameters and field mappings, call `scenario_module_get` with the ids from here.

scenario_get

Returns how specific modules in a scenario are configured: every static parameter with the human name of anything it references, and the full mapping of its input fields. Call it after `scenario_get` when the specifics matter — which spreadsheet a module writes to, what a message says, how a field is calculated. Requires module ids: get them from `scenario_get`. At most 10 modules per call.

scenario_module_get

Returns what happened in one run: overall status and error, plus every module that ran, in flow order, with how many times it ran and whether it failed. This is the map for debugging — find the failing module here, then fetch its actual input and output data with `scenario_execution_module_get`. For a quick look at a run's outcome and outputs without the module breakdown, `scenario_execution_get` is cheaper. Requires the scenarioId and an executionId from `scenario_execution_list` or `scenario_run`.

scenario_execution_inspect

Shows what a scenario's webhook has been receiving: the detected data structure, recent deliveries with their status, any deliveries queued up waiting (which happens while the scenario is inactive, paused, rate-limited, or — for a sequential scenario — blocked behind stored failed runs), and the raw content of a specific delivery on request. This is the debugging view for "I sent data to the webhook — what did Make actually get?". Payload content may be withheld for confidential or shared webhooks. Absent `deliveries` on a plan with no hook-log retention means "not recorded", not "nothing arrived".

scenario_trigger_inspect

Puts a scenario's webhook into learning mode: the next request that arrives is captured as the webhook's data structure — without running the scenario — and learning switches off by itself. Use it before building or debugging a webhook scenario: start learning, give the user the webhook URL to send a test request to, then read the detected structure with `scenario_trigger_inspect`. Only webhook-triggered scenarios have anything to learn.

scenario_trigger_learn

Lists a scenario's past runs, newest first, with status, duration and the error message where a run failed. Use it to find a run to review with `scenario_execution_get` or debug with `scenario_execution_inspect`. Returns at most 25 runs, with no paging — to reach older history, narrow with `from`/`to` or `status`. A run started moments ago can lag the list by a few seconds. Data only; prefer it while working through a task. When the user asks to *see* the run history, call `scenario_execution_list_show` instead — same arguments and data, but it also renders an interactive timeline.

scenario_execution_list

Lists the folders a team organizes its scenarios into, with how many scenarios each holds. Use it to resolve a folder id for `scenario_list`'s `folderId` filter, or to answer questions about how the team's scenarios are arranged.

scenario_folder_list

Lists or searches scenarios within a single team. Requires a teamId — call `environment_get` first if you do not have one. Hard limit of 25 scenarios, no paging — to reach others, narrow with `search`, `folderId` or `status`, or change the sorting. Data only; prefer it while working through a task. When the user asks to *see* the scenarios, call `scenario_list_show` instead — same arguments and data, but it also renders an interactive list.

scenario_list

Runs a scenario once and waits briefly for the result. What happens depends on the scenario's trigger (see `trigger.kind` from `scenario_get`): on-demand — runs with your `inputs` and returns its declared outputs; polling or scheduled — runs once right now, ahead of its schedule, takes no `inputs` and returns no outputs (the run reports to history); webhook — nothing is run, and the response instead gives the webhook URL to send a request to, or names the app event that starts the scenario. The scenario must be active; activate it first with `scenario_activate` if needed.

scenario_run

Renders one run's outcome — status, error, outputs and what it consumed — as a card in the conversation. Takes the same arguments and returns the same data as `scenario_execution_get`; the only difference is the rendered card. Call it only when the user explicitly asks to see the run; while working through a task, use `scenario_execution_get` instead so the conversation is not filled with UI.

scenario_execution_get_show

Renders a scenario's past runs as an interactive timeline in the conversation. Takes the same arguments and returns the same data as `scenario_execution_list`, including the 25-run cap — when more match, narrow with `from`/`to` or `status`. The only difference is the rendered timeline. Call it only when the user explicitly asks to see the run history; while working through a task, use `scenario_execution_list` instead so the conversation is not filled with UI.

scenario_execution_list_show

Renders an interactive, filterable list of a team's scenarios in the conversation. Takes the same arguments and returns the same data as `scenario_list`, including the 25-scenario cap — when more match, narrow the query with `search`, `folderId` or `status`. The only difference is the rendered list. Call it only when the user explicitly asks to see the scenarios; while working through a task, use `scenario_list` instead so the conversation is not filled with UI.

scenario_list_show