Rawa

Upload an image file

upload_image_file

Upload an image you hold as a file, with no action from the user: only for an agent that can run shell commands and has the file on its own filesystem (a coding agent such as Replit, Cursor or Claude Code working in a project). Pass the file's name as it is on disk; you get back a creativeId reserved for it and a curl command. Run the command: it posts the file to Rawa and answers {"creativeId": ...} once the image is in the brand's library. Use the creativeId the command prints, not the reserved one: when the library already holds the same image, it prints that creative's id with "alreadyInLibrary": true and adds no copy. Then pass that creativeId to resize_creative, edit_creative, remove_background, sharpen_creative or any other tool, in the same turn. Never use this for an image the user pasted or attached in a chat: you cannot read such an attachment and there is no file to post; call request_image_upload instead. For an image already at a public https URL, pass imageUrl to the tool directly and skip the upload. The file must be a JPEG, PNG, WebP, AVIF, HEIC or GIF of at most 25 MB. The command works for one hour and for one upload; if curl fails, call this tool again for a fresh command rather than retrying the same one. Free: nothing is charged for the upload.

Input Schema

Name	Required	Description
`brandId`	No	A brand id from get_workspace or list_brands, or the brand's name. Omit it when the organization has a single brand.
`purpose`	No	What the image is for, kept with the upload, e.g. 'Resize for Snapchat'.
`fileSize`	No	The file's size in bytes, when you know it.
`filename`	Yes	The file's path or name as curl will read it from disk, e.g. 'assets/hero.png'.
`mimeType`	No	The file's type, e.g. image/png. Read from the extension when omitted.

Output Schema

Name	Required	Description	Default
`curl`	Yes
`next`	Yes
`maxBytes`	Yes
`mimeType`	Yes
`uploadId`	Yes
`expiresAt`	Yes
`uploadUrl`	Yes
`creativeId`	Yes
`uploadToken`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedInput schema / properties / brandId / description

Previous value: -"A brand id from get_workspace or list_brands. Omit it when the organization has a single brand."New value: +"A brand id from get_workspace or list_brands, or the brand's name. Omit it when the organization has a single brand."

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover safety hints; the description adds the real behavior: a two-step reserve-then-curl flow, a one-hour single-use command, the dedupe behavior that prints alreadyInLibrary and adds no copy, the instruction to re-call on curl failure rather than retry, and that the upload is free. This is context an agent could not infer from annotations or 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 core action and the critical constraint (no user action, local filesystem only), then flows logically through reservation, execution, dedupe and downstream use. It is long and a few clauses (format list, free-upload note) could be trimmed, but nearly every sentence carries actionable information.

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?

Given the two-step upload mechanic and the existence of an output schema, the description covers everything needed: prerequisites, accepted formats and size cap, failure recovery, dedupe semantics, and which creativeId to use next. No material gap remains for correct invocation.

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 coverage is 100%, so parameters are already documented. The description reinforces that filename is the on-disk path and adds file-format and 25 MB constraints, but adds little about brandId, purpose, fileSize or mimeType beyond the schema, so baseline 3 applies.

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 (upload an image held as a file) and immediately scopes it to agents with shell access and a local file. It distinguishes itself from request_image_upload (pasted attachments) and from passing a public imageUrl directly, so an agent can route without opening 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-to-use (agent with file on its filesystem), explicit when-not-to-use (never for pasted/attached chat images; use request_image_upload), and an alternative path for public URLs. It also names the downstream tools that consume the resulting creativeId.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Rawa 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?