Skip to main content
Glama
yuli-tonkin-bg

Make MCP Server

by yuli-tonkin-bg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

make_update_blueprint

Update an existing Make.com scenario's structure (blueprint, connections, params), schedule, name, or folder. Requires explicit user confirmation and returns before/after snapshots to enable recovery.

Instructions

HIGH RISK: update a scenario's blueprint (module structure/params/filters/connections), scheduling, name, and/or folder via PATCH — modifies REAL scenario structure. MANDATORY workflow before calling: (1) call make_get_blueprint to see the current structure, (2) present the user the exact planned change/diff and get their explicit approval, (3) strongly prefer testing structural changes on a clone first (make_clone_scenario) before touching the live scenario. Requires confirmed:true as proof this workflow happened (this tool's own safety gate — Make's API does not require it; refuses otherwise). Before applying, takes a fresh snapshot of the current blueprint and returns it alongside the update result as 'before_blueprint', so the prior state can be manually restored (by calling this tool again with that blueprint) if the change turns out wrong — this is a recovery aid only, it does not block or compare against that snapshot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew name for the scenario (optional)
blueprintNoThe new blueprint (JSON object matching Make's blueprint structure). Omit to only change name/folder_id/scheduling.
confirmedYesMust be true — confirms the plan-approval(-clone) workflow was followed before this call
folder_idNoMove the scenario to this folder ID (optional)
schedulingNoNew scheduling configuration (optional)
scenario_idYesThe scenario ID to update

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses the mutating nature, high-risk implications, snapshot taken before applying, and the 'before_blueprint' recovery mechanism. It also reveals that the confirmed gate is this tool's own safety measure, not required by Make's API, and notes the snapshot does not block or compare.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single long paragraph but front-loaded with 'HIGH RISK' and a clear purpose. It is dense with critical information but could be better structured with bullet points. It is not excessively verbose given the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking output schema and annotations, the description covers purpose, mandatory workflow, safety requirements, mutability, and recovery options. It is complete enough for an agent to safely use this high-risk mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for all 6 parameters, each with descriptions. The description adds context for 'confirmed' as a safety gate and mentions 'blueprint' structure, but does not substantially add parameter-level meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates a scenario's blueprint (module structure/params/filters/connections), scheduling, name, and/or folder via PATCH, modifying REAL scenario structure. This specific verb+resource clearly distinguishes it from read-only siblings like make_get_blueprint and make_clone_scenario.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly provides mandatory workflow: call make_get_blueprint first, get user approval of the diff, prefer testing on a clone (make_clone_scenario), and requires confirmed:true as proof. This gives clear when-to-use and alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools