Make

Create a new endpoint or update an existing endpoint and its sections in a single operation. For CREATE mode: appName, appVersion, endpointName, and label are required. The 'endpointName' sets the endpoint identifier. For UPDATE mode: endpointName is required; all metadata fields are optional — only provided fields are updated. Connections are managed via the 'attachedAccounts' array (it replaces the existing list) and can be set on both CREATE and UPDATE. Available sections: api, scope, inputParameters, outputParameters

custom_app_endpoint_configure

Create new modules or update existing modules and their sections in a single operation. Use explicit mode parameter to specify whether to create or update the module. Module typeId values: - Trigger (polling) [TypeId: 1] - Watch for changes via polling - Action [TypeId: 4] - Single response endpoint - Search [TypeId: 9] - Multiple item result - Universal [TypeId: 12] - Arbitrary API calls - Instant Trigger (webhook) [TypeId: 10] - Watch for changes via webhook - Responder [TypeId: 11] - Send processed data back to webhook For CREATE mode: typeId and label are required. For UPDATE mode: all metadata fields are optional - only provided fields will be updated.

custom_app_module_configure

Create organization (organizations): Create a new organization.

organization_create

Creates a new scenario from a list of modules, how they are wired, and a schedule — validates the whole design first and refuses with every problem at once rather than creating something broken. Modules are described the same way `scenario_get` reports them. Find the modules with `app_find` and read each one's fields and connection with `module_spec` before calling this — module names and field names must be exact, never guessed. The new scenario starts inactive unless you pass `autoActivate` — otherwise switch it on with `scenario_activate` when the user is ready. If the trigger is a generic webhook, the webhook is created automatically and its URL is returned; nothing is known about the data it will send, so when later modules need to map its fields, create the scenario with the trigger alone first, have the user post one real request to that URL, and add the rest with `scenario_patch` once the fields are known. For a design past a straight line — routers, if-else arms, iterators and aggregators, error handlers, agent tools, on-demand scenarios — follow the `make-scenario-building` skill when it is available; it carries the flow patterns this schema cannot.

scenario_create

Creates a folder to organize a team's scenarios into, optionally nested under an existing one. Folders nest up to 3 levels deep. A duplicate name under the same parent is allowed.

scenario_folder_create

Creates a scenario label in a team. The label starts out assigned to nothing — use `scenario_label_assign` to put it on a scenario. Check `scenario_label_list` first: labels are team-wide and nothing prevents two with the same name.

scenario_label_create

Adds a note to a scenario — a short piece of documentation for whoever opens it next. Anchor it to the modules it describes with `moduleIds`, or leave those out for a note that floats on the canvas.

scenario_note_create

Create team (teams): Create a new team.

team_create

Switches a scenario off: it stops running on its trigger and its schedule. Stored data, configuration and run history are untouched, and the scenario can be switched back on at any time with `scenario_activate`.

scenario_deactivate

Delete a custom app by name and version

custom_app_delete

Delete an RPC

custom_app_rpc_delete

Delete a connection

custom_app_connection_delete

Delete an endpoint. Only allowed while the app is not public — use archive on public apps instead.

custom_app_endpoint_delete

Delete a function

custom_app_function_delete

Delete a module

custom_app_module_delete

Delete a webhook

custom_app_webhook_delete

Delete custom role (custom-roles): Delete an existing custom role. Only custom-managed roles can be deleted. The role must not be currently assigned to any users.

custom_role_delete

Deletes a data store. If it is still referenced by a non-deleted scenario, this reports that instead of deleting — call again with `confirmed: true` to delete it anyway. If it is referenced by an incomplete execution, deletion is refused outright; that execution has to be resolved or deleted first.

data_store_delete

Permanently deletes records from a data store by key.

data_store_record_delete

Deletes a data structure. If it is still referenced by a non-deleted scenario, this reports that instead of deleting — call again with `confirmed: true` to delete it anyway. If it is used by a data store, deletion is refused outright; that link has to be removed in the Make editor first.

data_structure_delete

Delete organization (organizations): Delete an organization.

organization_delete

Permanently deletes a scenario. This cannot be undone: the scenario's configuration, its module wiring, its schedule and its whole run history go with it. The connections it used are not deleted and stay available to other scenarios. If the user only wants the scenario to stop running, use `scenario_deactivate` instead — that is reversible and keeps everything. Only call this when the user has clearly asked for the scenario to be deleted.

scenario_delete

Deletes a scenario folder and all of its subfolders (its whole subtree). Scenarios anywhere in that subtree are not deleted — they move up to the folder's own parent (or to the top level). Cannot be undone.

scenario_folder_delete

Deletes a scenario label from the team. This also removes it from every scenario currently carrying it — those assignments are gone with the label and recreating it does not bring them back. Call `scenario_label_list` first to see how many scenarios are affected.

scenario_label_delete

Deletes a note from a scenario. The note's text is gone for good — nothing in Make restores it, so check what it says with `scenario_note_get` before removing it.

scenario_note_delete

Delete team (teams): Delete a team.

team_delete

Edits an existing scenario by describing the changes — add or remove modules, change how they are wired, reconfigure a module's parameters or field mapping, change filters, the schedule, the name, which app event a trigger listens for, or the inputs and outputs the scenario declares — without resending the whole design. Nothing you do not mention is touched. The server fetches the current blueprint, applies the operations in order, validates the result and saves it in one step: either every operation takes effect or none does, and a scenario is never left half-edited. Put everything one change needs in a single call. If the scenario was edited by someone else since it was last read, the edit is refused: fetch fresh state with `scenario_get` and retry. Multi-step edits — learning a webhook payload before mapping it, adding a module and then wiring onto it, adding an error handler — are covered by the `make-scenario-building` skill when it is available.

scenario_patch

Finds the Make apps and modules that fit a described goal ("save email attachments", "post to Slack", "split into two paths"). Takes plain language — call it with the user's own words rather than guessing app names. Returns candidate apps with their usable modules, each with a `kind`: trigger, instant_trigger (webhook), action, search, responder, flow_control, or other. The built-in flow-control modules (router, if-else, merge, iterator, aggregator, error-handler directives), the generic webhook modules, and the on-demand scenario modules (`scenario-service`) are always included, whatever the query. Module names returned here are exact — use them verbatim; never invent module names. It does not say what a module needs to run: for input fields, and for which connection it needs and whether one already exists, call `module_spec` with the names from here.

app_find

Returns Make's documentation page for an app: how to create its connection (custom OAuth clients, API keys, scopes to grant in the vendor's console), how to register webhooks Make cannot set up itself, and app-specific limits and caveats. Not a required build step — call it when the user has to set something up by hand (a webhook `module_spec` reports as not `autoCreatable`, credentials they ask how to obtain), or when a module fails for an app-specific reason. Pages are maintained separately from the apps and can lag them: for module names and fields, `app_find` and `module_spec` are authoritative.

app_docs_get

Reports progress on an authorization link from `connection_create`: the overall status, each credential's state, and — once authorized — the connection ids that scenario modules reference. Call it when the user says they have finished authorizing, or to check why a connection is still missing.

connection_get

Get function code

custom_app_function_code_get

Get function test code

custom_app_function_test_get

Gets one data structure's full field spec by id. Use after `data_structure_list` has narrowed to a candidate worth inspecting.

data_structure_get

Lists the Make zone, organizations, and teams reachable through this connection, including private spaces. Most Make resources belong to a team; other tools require the organizationId and teamId returned here. Call this first when you need ids. A private space id is valid wherever a teamId is accepted.

environment_get

Returns one run's outcome: live status, the failure if it errored, the scenario's declared outputs, and what the run consumed. Use it to check on a run started with `scenario_run` or to look closer at a run from `scenario_execution_list`. To debug a failed run module by module, use `scenario_execution_inspect` instead. Requires the scenarioId and an executionId from `scenario_execution_list` or `scenario_run`. Data only; prefer it while working through a task. When the user asks to *see* the run, call `scenario_execution_get_show` instead — same arguments and data, but it also renders the outcome as a card.

scenario_execution_get

Returns the actual data one module received and produced in one run — request and response, one record per operation. This is the drill-down after `scenario_execution_inspect` points at a suspect module: take `moduleId` and `cycle` from it. Large data is shortened and marked; page through operations with `fromOperation` if the module ran many times within the cycle. A module with no downstream consumer (e.g. `ReturnData`) always reports an empty output record — expected, not a broken mapper; see `scenario_run`/`scenario_execution_get`'s `outputs` field for the scenario's actual declared output.

scenario_execution_module_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

Get organization (organizations): Get details of a specific organization.

organization_get

Fetch a single pending change by id, including the previous and proposed values. Use `custom_app_change_list` first to discover change ids, then call this tool with one of those ids to inspect what was changed. The default `format: "diff"` returns `{ id, group, code, label, diff }` where `diff` is a unified diff string suitable for displaying directly to the user. Pass `format: "raw"` to get the API payload (`{ id, group, code, oldValue, newValue }`) augmented with the same UI-friendly `label` field.

custom_app_change_get

Get private space (private-spaces): Get details of a specific private space, including usage totals (operations, transfer, centicredits). Callers who are not members of the space receive a 404 even when the space exists.

private_space_get