The read-only path from "what does this account have" to "explain this scenario" — the entry point of almost every conversation, and the tool of choice for a non-technical question about an automation.
Ground rules. A 403 means the whole connection must be re-authorized with every permission — never one
tool. A content remark on a result is an instruction, not decoration. Say what you resolved an ambiguous
value to before the call that acts on it. The refusal contract and the rest: make-scenario-reference, when
something is refused or no tool seems to fit.
Start with environment_get
Always first, no arguments: every organization and team the connection reaches, including private spaces,
and the zone needed for https://<zone>.make.com/<teamId>/scenarios/<id> links. An organization-bound
connection sees one organization and a remark counts the rest — mention that only if the user expects
something that is not there.
Finding a scenario
scenario_list returns at most 25, most recently edited first. Omitting status returns every status — it
is not a hidden "active only" filter. Its trigger is coarse (instant/scheduled/on-demand); the
webhook-vs-polling distinction lives in scenario_get. Narrow by name, folder or status rather than paging.
scenario_folder_list only when the user refers to a folder. scenario_list_show only when they ask to see
the list rendered.
Explaining one scenario
scenario_get is enough by itself: every module in flow order, nesting via parent (router arms,
if-else branches, error handlers, agent tools), filters, trigger and schedule, connection health, declared
inputs and outputs. It omits each module's config on purpose — do not read that as incomplete, and do not
fan scenario_module_get across every module. Call scenario_module_get only when a specific value is the
question: which spreadsheet, what the message says, how a field is computed.
How to read a few fields for a non-technical user:
trigger.kinddecides what "make it run" means:webhook→ give a URL to post to;polling/scheduled→ it runs on its schedule;on-demand→ run it directly, the only kind that returns outputs.connections[].status: "missing"covers both deleted and broken — the fix is the same, reconnect the app in Make — and it is the most common reason a scenario "stopped working". No other tool surfaces it.isWaitingOnIncompleteExecutionsmeans the scenario runs sequentially and is frozen behind stored failed runs: no new data flows until those are resolved in Make (this surface cannot). Different from a non-zeroincompleteExecutionsalone, which is informational on a non-sequential scenario.status: "error"carries no reason — Make records none. The cause is in the run history (make-scenario-operations), never in a guess.modules[].issuesare Make's own complaints about a module ("not set up") — usually the direct answer to "why won't it activate".
Scenario ids come from scenario_list or from a create/patch response; scenario_get and
scenario_module_get take no teamId.
Account-wide health checks
scenario_list's status and incompleteExecutions are a cheap first pass, not the answer: status only
turns error after Make deactivates a scenario for repeated failures, so a scenario that started failing
yesterday still reads active. A structural read says nothing about whether recent runs succeeded. For a
real answer, call scenario_execution_list (narrowed to status: "error") for every scenario in scope, then
scenario_get on the ones that turn up failures for connection health and issues. With more scenarios than
the 25-row cap, narrow by folder or status and say the sweep is partial.
Not covered here
- Running, activating, or debugging —
make-scenario-operations. - Creating or editing —
make-scenario-building.