Mixer AI

Import media into MixerAI

aimixer_media_import

Idempotent

Import an accessible public media URL, a real host file object, or inline base64 of actual local image/video/audio bytes. Base64 is appropriate ONLY for tiny files (roughly 150 KiB or less): larger files must use aimixer_media_upload_prepare with the host sandbox/terminal and the returned HTTP command. In Claude with code execution first inspect /mnt/user-data/uploads for the original. Execute the command yourself if permitted to access mixerai.org; then check status by upload_id. If no HTTPS egress or no actual host bytes, open the inline aimixer_media_upload_open widget (MCP Apps hosts); only without MCP Apps provide aimixer_media_upload_session's upload page. Never re-request the chat attachment, reconstruct image pixels, guess a URL, or pass a local path to this remote tool. For Canvas uploads from any input source, pass project_id from Canvas create/read. For an existing library reference, use Canvas apply attach_media to link it to a project. One source only; return managed_id without generation or spending coins.

Input Schema

Name	Required	Description
`url`	No	Public HTTP(S) download URL only; local OS paths, file:// and sandbox paths cannot be read by this remote service.
`file`	No	Host-provided uploaded file object. The client first reads the local file with a real file picker/upload bridge, then passes file_id + HTTPS download_url. This is NOT an absolute local file path. A remote MCP server cannot read D:\... or file://.
`model`	No	Optional model the file is for. With it the import applies the site's own check and fitting for that model (limits, video frame fitting, audio conversion); without it the file is checked when the generation starts.
`values`	No	Optional settings of that model that change its input limits (for example quality or mode).
`file_name`	No	Filename with extension for data_base64 (for example picture.png).
`mime_type`	No	MIME type for data_base64, verified against file extension and content.
`project_id`	No	Owned Canvas project ID for inline, host-file or URL imports. Sets Canvas retention for newly uploaded bytes; attach returned media to a project node.
`data_base64`	No	Only for real file bytes, preferably <=150 KiB; use aimixer_media_upload_prepare + shell HTTP upload for larger files. Server bound by the 8 MiB MCP JSON request.
`media_family`	Yes
`reference_mode`	No	Optional input mode of that model, as in its options.
`idempotency_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 4, 2026

addedInput schema / properties / model

Added value: +{
+  "description": "Optional model the file is for. With it the import applies the site's own check and fitting for that model (limits, video frame fitting, audio conversion); without it the file is checked when the generation starts.",
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / reference_mode

Added value: +{
+  "description": "Optional input mode of that model, as in its options.",
+  "maxLength": 64,
+  "type": "string"
+}

addedInput schema / properties / values

Added value: +{
+  "description": "Optional settings of that model that change its input limits (for example quality or mode).",
+  "type": "object"
+}

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / project_id / description

Previous value: -"Optional owned Canvas project ID when importing local inline bytes."New value: +"Owned Canvas project ID for inline, host-file or URL imports. Sets Canvas retention for newly uploaded bytes; attach returned media to a project node."

First observedOct 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=false, idempotentHint=true and openWorldHint=true, and the description adds materially beyond them: no generation occurs and no coins are spent, only a managed_id is returned, model/values trigger server-side limit checks and fitting, and project_id controls Canvas retention. It does not explain idempotency-replay behavior (e.g., what a repeated key returns), which is the one behavioral gap given idempotentHint=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?

Purpose is front-loaded in the first sentence and the remaining clauses are largely load-bearing routing instructions. It is a dense run-on paragraph with overlapping directives (base64 limits restated in both prose and schema, local-path prohibition repeated twice), which costs some readability but not correctness.

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, nested-object, multi-source tool with no output schema, the definition covers source selection, environment fallbacks, safety constraints, cost implications and the returned managed_id. It leaves the return payload under-described beyond managed_id and does not address idempotency_key reuse semantics, but nothing needed to choose the correct source path is missing.

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 coverage is already 82%, so the baseline is 3; the description still adds real meaning, notably that project_id should come from Canvas create/read and sets retention for newly uploaded bytes, and that model/values cause the site's own limits and conversions to be applied at import time rather than at generation. Some echoed detail (the base64 size cap) duplicates the schema rather than extending it.

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 first sentence names a specific verb (import) and enumerates the exact accepted source types (public media URL, host file object, inline base64 of real bytes). It actively distinguishes itself from siblings by naming aimixer_media_upload_prepare, aimixer_media_upload_session, the inline upload widget, and Canvas apply attach_media, so an agent can route correctly without opening other schemas.

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 when/when-not coverage: base64 only for tiny files (~150 KiB), larger files must go through upload_prepare plus a shell HTTP command, inline widget when there is no HTTPS egress, session upload page only when MCP Apps is unavailable. It also states exclusions ('one source only', 'never pass a local path') and names the alternatives for each fallback branch.

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?