Mixer AI

Canvas Inspect Layout

aimixer_canvas_inspect_layout

Read-onlyIdempotent

Use when you need positions, collisions and warnings for long-strip frame arrangements (recommended grid: ceil(sqrt(N)) columns). Computed from saved graph coordinates (no rendering): per selected frame returns the frame rectangle, the cards whose center lies inside it with approximate bounds, overlapping pairs, cards sticking out of the frame and minimum gaps. Sizes are the editor defaults, not measured pixels. To see the real UI use the widget app tools or aimixer_canvas_view_session. Legacy renderer-only arguments are accepted for cached clients and return renderer_retired instead of fake DOM/screenshot data. Read-only: never changes the saved project.

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>",
      "frame_ids": "<frame_ids>"
    },
    "name": "aimixer_canvas_inspect_layout"
  }
}

Input Schema

Name	Required	Description	Default
`min_zoom`	No
`frame_ids`	Yes
`project_id`	Yes
`expected_rev`	No
`viewport_width`	No
`viewport_height`	No
`screenshot_frame_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, yet the description adds substantive context: results are computed from saved graph coordinates with no rendering, sizes are editor defaults rather than measured pixels, and legacy renderer arguments return renderer_retired instead of fake DOM/screenshot data. It also restates the read-only guarantee in domain terms ('never changes the saved project').

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?

Front-loaded with the "Use when" trigger, then the return shape, then the caveats and alternatives — a sensible order with no filler sentences. It is dense (five clauses in one sentence) but every clause carries information an agent needs.

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?

With no output schema, the description does the work of describing the return payload precisely, and annotations plus the text fully cover the safety profile. The residual gap is expected_rev and the legacy-argument list, which are referenced but not individually explained for a 7-parameter 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 description coverage is 0% across 7 parameters, so the description must carry the burden. It clarifies the frame-selection model and hints that viewport/min_zoom/screenshot-style arguments are legacy no-ops that return renderer_retired, which is genuinely useful, but it never names or explains expected_rev (a concurrency control) or the viewport fields explicitly.

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?

States a specific verb+resource (inspect layout) and enumerates exactly what it returns: frame rectangles, cards whose center lies inside with approximate bounds, overlapping pairs, protruding cards, minimum gaps. It also scopes the domain (long-strip frame arrangements) and distinguishes itself from rendering-view siblings like aimixer_canvas_view_session.

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?

"Use when you need positions, collisions and warnings for long-strip frame arrangements" gives an explicit trigger, and "To see the real UI use the widget app tools or aimixer_canvas_view_session" names the alternatives and the condition that selects them. An agent can route correctly without opening any schema.

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.