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. Never ask for another chat attachment or fabricate its bytes. No generation/debit; Canvas graph nodes must be attached separately.

Input Schema

Name	Required	Description	Default
`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
`destination`	No		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 changedOct 29, 2026

addedInput schema / properties / family

Added value: +{
+  "description": "Selected model family: the session then takes exactly that model's maximum reference files for media_family.",
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / properties / max_files / default
```
Previous value: -5New value: +10
```

addedInput schema / properties / values

Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

First observedOct 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the fallback condition, that the user chooses the file once, polling behavior, size limits, no generation/debit, and that Canvas graph nodes must be attached separately. It does not contradict the annotations and adds meaningful operational context.

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 fallback guidance is front-loaded and most clauses earn their place, including the size limits and no-fabrication warning. The text is dense but not bloated, though it could be structured more clearly for a multi-action tool.

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

Completeness3/5

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

For an 11-parameter, multi-action tool with no output schema and low schema coverage, the description covers the core workflow and mentions a completed managed_id. It still leaves gaps around destination behavior, ttl/expiry, project_id, max_files, and fuller return-value expectations.

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 only 36%, so the description must compensate. It explains action=create/status, token/upload_id usage, and size limits, but omits semantics for several parameters such as destination, project_id, ttl, values, max_files, and max_file_bytes.

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 states a specific purpose: a browser-based upload fallback for when the host cannot access file bytes or outbound HTTPS. It explicitly distinguishes this tool from aimixer_media_upload_prepare and aimixer_media_upload_open and identifies the create/status actions.

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?

It gives explicit routing: first try aimixer_media_upload_prepare, then fall back to aimixer_media_upload_open or action=create here, then poll action=status. It also names the token and upload_id inputs for polling, so an agent knows exactly when and how to use the 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.

Resources

Need Help?