Mixer AI

Canvas View Session

aimixer_canvas_view_session

Read-onlyIdempotent

Use when the user asks to show or look at the Canvas, or you need to see its rendered UI/layout, and the app tools capture_view/navigate_view are not listed. Get a short-lived (default 10 minutes, ttl_sec 60-600) read-only viewing link for ONE owned Canvas project. The link opens the same read-only Canvas viewer used by public share links, but only for this project and only until expires_at; it never exposes or creates the owner's permanent share link, cannot edit anything and needs no login. Open view_url in a JavaScript-capable browser tool to look at the project (a fetch-only tool sees an empty page); call again for a fresh link after it expires.

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

Input Schema

Name	Required	Description	Default
`ttl_sec`	No
`project_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real context: link lifetime (default 10 min, ttl_sec 60-600), expiry via expires_at, that it never exposes or creates the owner's permanent share link, no login required, and that a fetch-only client sees an empty page. The only gap is what the viewer link/response looks like structurally, which is minor given there is no output schema.

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 and packed with zero filler; every clause carries operational information (TTL, browser requirement, expiry retry). It is slightly dense and run-on across a few long sentences, but nothing is redundant.

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 two-parameter read-only tool with no output schema, the description covers selection criteria, lifetime semantics, what the returned link grants and does not grant, the client capability required to use it, and the refresh path after expiry. An agent has everything needed to invoke it correctly and to interpret the result.

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?

Schema description coverage is 0%, so the description must carry the load. It does: ttl_sec is explained as a short-lived TTL with a stated default of 10 minutes and a 60-600 range, and project_id is constrained to 'ONE owned Canvas project' (ownership and single-project scoping). It does not give the accepted project_id format or how to obtain one, which keeps it below 5.

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 and resource: 'Get a short-lived ... read-only viewing link for ONE owned Canvas project.' It also scopes the result ('only for this project and only until expires_at') and names the sibling tools (capture_view/navigate_view) it substitutes for, so an agent can tell it apart from the many other canvas_* inspection tools.

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?

Explicit trigger ('when the user asks to show or look at the Canvas, or you need to see its rendered UI/layout') plus an explicit precondition ('and the app tools capture_view/navigate_view are not listed'). It also gives the follow-up procedure: open view_url in a JavaScript-capable browser, and call again for a fresh link after expiry.

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.