Skip to main content
Glama
Sign In
elementor-live

elementor-live

by ArchiDoxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Mutate canvas

mutate_canvas
Destructive

Apply batch create, update, move, delete, duplicate, and custom-CSS operations to an open Elementor document as one labeled undo step, keeping live editor changes reversible and verifiable.

Instructions

Apply a batch of operations to the open document through Elementor's own command API, in the user's editor tab, as ONE undo step titled after label (the user can press Ctrl+Z). Ops: create {parentId?, at?, elType, widgetType?, settings?} (omit parentId to append at document root; elType "widget" needs widgetType), update_settings {id, settings} (merges keys), move {id, parentId, at?}, delete {id}, duplicate {id}, set_custom_css {id, css} (Elementor Pro custom_css; "selector" refers to the element). IDs must come from get_canvas_skeleton or from earlier create/duplicate results (returned per op as id) — never invent them. Within one batch, "$N" (e.g. "$0") as id/parentId refers to the element created by op N of the same batch, so a container and its children can be built in one undo step. Prefer elType "container" with flex settings (flex_direction, flex_gap, flex_justify_content, flex_align_items) over legacy section/column. Check keys with get_widget_controls first. Atomic V4 elements (elType/widgetType "e-*") can be created, but may reject classic settings (code unsupported_atomic). A failing op does not stop the others; inspect results[] and verify visually with capture_vision.

Input Schema

NameRequiredDescriptionDefault
opsYesOperations, applied in order.
labelNoShort undo-history label, e.g. "Hero section". Default "Edit".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations establish a destructive, non-idempotent mutation, and the description adds undo-step behavior, failure isolation, results inspection, ID provenance rules, same-batch $N references, and atomic V4 unsupported_atomic caveats. This is substantial behavioral context beyond what annotations alone provide.

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 most important action is front-loaded, and the remaining content is organized around operation semantics, ID rules, and caveats. It is dense but justified for a complex batch API; minor formatting improvements could make it easier to scan.

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?

For a multi-operation mutation tool with no output schema and destructive annotations, the description covers call prerequisites, operation semantics, failure behavior, and verification routes. Return-value detail is light but results[] and per-op id availability are explicitly referenced.

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

Parameters5/5

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

Despite 100% schema description coverage, the description defines each operation's semantics in detail: create parentId omission, settings key merging, move/delete/duplicate behavior, set_custom_css Pro behavior, and label as the undo title. This meaningfully supplements the anyOf schema.

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 opens with a specific verb and resource: batching operations against the open Elementor document via its command API in the user's editor tab. It is clearly distinguishable from read-only siblings such as get_canvas_skeleton and inspect_element.

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

Usage Guidelines4/5

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

It gives concrete prerequisites and alternatives: IDs must come from get_canvas_skeleton or prior create/duplicate results, widget settings should be checked with get_widget_controls, and results should be verified with capture_vision. It does not explicitly frame when not to use this tool versus siblings, but the operational context is strong.

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