Mixer AI

Canvas Apply

aimixer_canvas_apply

DestructiveIdempotent

Use when the user asks to add or edit text, titles, frames, layout or nodes in a Canvas project. Applies semantic edits, including server-planned layout_composition with near-square group-frame grid (ceil(sqrt(N)) columns, row-major, no overlaps), atomically to your Canvas project at expected_rev. Read capabilities and the project first. Use exact node IDs; remove nodes only when requested. Reuse the SAME request_id after a lost response. A revision conflict requires rereading; never force overwrite. This edits the draft only; generation uses the existing quote/submit tools. AFTER apply: if layout_warnings are returned, fix them; then call aimixer_canvas_inspect_layout for the frame and fix any overflow/overlap before telling the user it is done. When placing an imported image/video/audio from aimixer_media_import or a library managed_id, attach it to a media node with attach_media/reference; this creates a durable project reference. For new direct uploads first create/read the project, then use aimixer_media_upload_prepare with destination=canvas and project_id, then attach the managed_id. Titles: one short line plus an optional short subtitle; for add_note set w to fit inside the frame and wrap=true. Frames must fit their children with padding.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "expected_rev": "<expected_rev>",
      "request_id": "<request_id>",
      "operations": "<operations>"
    },
    "name": "aimixer_canvas_apply"
  }
}

Input Schema

Name	Required	Description	Default
`operations`	Yes
`project_id`	Yes
`request_id`	Yes
`expected_rev`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations, it discloses atomic application at expected_rev, draft-only scope, revision-conflict handling, request_id reuse after lost responses, and the post-apply layout_warnings and inspect_layout workflow. It also warns to remove nodes only when requested, which is consistent with destructiveHint=true.

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 front-loaded with the usage trigger and every sentence carries operational value, including revision handling, media attachment, and post-apply layout checks. It is dense as a single paragraph and could be more scannable, but the length is justified by the tool's destructive, multi-step nature.

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

Completeness4/5

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

For a complex destructive edit tool with no output schema and bare parameter schemas, it covers prerequisites, atomicity, conflict handling, draft-only scope, media attachment, and post-apply validation. The main remaining gap is the internal structure of the operations array, which an agent must infer from examples rather than a formal schema.

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

Parameters4/5

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

With 0% schema description coverage, the description compensates by explaining expected_rev as a revision guard, request_id as an idempotency key, and operations as semantic edits including layout_composition, titles, add_note, and attach_media. It does not define the per-operation object structure, so the most complex parameter remains partially underspecified.

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

Purpose4/5

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

The description states a specific verb and resource: applying semantic edits to add or edit text, titles, frames, layout, or nodes in a Canvas project, atomically at expected_rev. It distinguishes itself from generation (quote/submit) and media import/upload siblings, but never mentions aimixer_canvas_update_node, which is the closest potentially confusable sibling.

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 a clear trigger (when the user asks to add or edit text, titles, frames, layout, or nodes) plus prerequisites to read capabilities and the project first. It also routes generation and media-import cases to other tools, but does not say when to prefer aimixer_canvas_update_node over this batch/semantic-apply tool.

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

All Mixer AI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.