Mixer AI

Upload local files through a secure MixerAI page

aimixer_media_upload_session

Browser upload fallback when the host cannot access file bytes or outbound HTTPS. First try aimixer_media_upload_prepare and run its command for a real local file. If that is unavailable, use aimixer_media_upload_open in MCP Apps or action=create here and show its upload page; the user chooses the file once. Poll action=status with token, or with opaque upload_id from aimixer_media_upload_prepare (no secret needed), for a completed managed_id. Photo maximum 30 MiB; video/audio 100 MiB; format, duration and model-specific limits apply. For Canvas use destination=canvas with project_id from Canvas create/read; for unattached media use library. Never ask for another chat attachment or fabricate its bytes. No generation/debit; Canvas graph nodes must be attached separately.

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": {
      "action": "<action>"
    },
    "name": "aimixer_media_upload_session"
  }
}

Input Schema

Name	Required	Description
`ttl`	No
`token`	No	Upload-session token returned by action=create. Required for status.
`action`	Yes
`family`	No	Selected model family: the session then takes exactly that model's maximum reference files for media_family.
`values`	No
`max_files`	No
`upload_id`	No	Opaque owner-bound ID from prepare; check action=status without the upload key.
`project_id`	No	Owned Canvas project to upload into; implies destination=canvas when omitted.
`destination`	No	Canvas needs project_id; omitting destination selects canvas when project_id exists, otherwise library.
`media_family`	No	Optional typed session, strict media family and canonical per-kind size cap.
`max_file_bytes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 2, 2026

removedInput schema / properties / destination / default
```
Removed value: -"library"
```

addedInput schema / properties / destination / description

Added value: +"Canvas needs project_id; omitting destination selects canvas when project_id exists, otherwise library."

addedInput schema / properties / project_id / description

Added value: +"Owned Canvas project to upload into; implies destination=canvas when omitted."

First observedNov 1, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With annotations already covering safety flags, the description adds real operational context: no generation/debit is charged, the user picks the file only once, polling yields a completed managed_id, and Canvas nodes must be attached separately afterward. Gaps remain on side effects not covered by annotations — notably that create is non-idempotent (repeated calls spawn new sessions) and what happens to sessions after ttl expires.

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 fallback condition and the fallback chain before the limits and routing details, and nearly every clause carries actionable content. It is dense but not padded; the only slight overload is packing routing rules, size caps, billing behavior, and a guardrail into one paragraph.

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 an 11-parameter, two-action tool with no output schema, the description covers the end-to-end flow (create → show page → status → managed_id) and the destination routing that an agent most needs. It stops short of describing what action=create actually returns (the page to show) or the purpose of ttl/values, which are the remaining unknowns.

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?

At 55% schema coverage the description meaningfully compensates: it explains that status accepts either token or the opaque upload_id (and that no secret is needed with upload_id), that destination=canvas requires project_id, and that size caps vary by media kind (30 MiB photo vs 100 MiB video/audio), which clarifies the relationship between media_family and max_file_bytes. ttl, values, and max_files remain unexplained in both places.

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 ('Browser upload fallback'), names the exact precondition (host cannot access file bytes or outbound HTTPS), and explicitly positions itself against siblings aimixer_media_upload_prepare and aimixer_media_upload_open. An agent can tell this is the last-resort browser path rather than the normal prepare flow without opening any schema.

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?

Gives an ordered decision procedure: try prepare first, fall back to upload_open or action=create, then poll action=status. It also names the disambiguation conditions (Canvas → destination=canvas with project_id; unattached → library) and a prohibition ('Never ask for another chat attachment or fabricate its bytes'). Nothing is left to inference.

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.