Rawa

Redo a design

adapt_design

Destructive

Redo a finished Rawa design for another purpose, keeping its editable layers: fix or translate its wording (copy), change its shapes, colours or positions (graphics), put another product or subject in it (subject), re-lay it out on another canvas (resize), or turn a still into a clip (animate). Cost: copy, graphics, subject and resize cost one design (50 credits); animate makes a 6 s motion design, 240 credits. A clip being redone keeps its length and is priced as one. Works on any finished design of the brand, from list_creatives or the gallery. Call with dryRun: true first and tell the user the cost. Once they agree, pass the quoted credits as expectedCredits; a call that would cost a different amount is refused. Give each new generation a new requestId, and repeat it unchanged only on a retry: a retry within 2 minutes returns the first result and is not charged again. Without a requestId, the same arguments within 2 minutes count as a retry. Needs generation allowed over MCP (see get_workspace); a dry run still quotes when it is not, and says why the call would be refused in wouldRefuse. Returns a jobId, creditsCharged and creditsRemaining; ready in 1 to 5 minutes, a clip longer. If a job panel shows, it tracks the work: do not poll, end your turn with one line saying it is under way, and later use show_creatives with the creativeIds you are told. Otherwise call wait_for_jobs with the jobIds until allFinal is true.

Input Schema

Name	Required	Description
`change`	Yes	What the redo changes.
`dryRun`	No	true: return the exact cost (credits, breakdown, balanceAfter) without charging or starting anything, and wouldRefuse when the organization's spending controls would refuse the real call.
`output`	No	Where the result lands: asset (the default) is a new creative beside the original; version adds it to the original's version history; replace deletes the original's current file and puts the result in its place. resize and animate cannot replace.
`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.
`entityId`	No	For change subject: the entity id from list_entities the design should now feature.
`requestId`	No	Your own unique id for this request. Use a new one for every new request, even with the same arguments. Repeat it unchanged only to retry this exact call within 2 minutes; the retry returns the first result.
`creativeId`	Yes	A creative id from list_creatives, search_library, get_job or get_upload.
`aspectRatio`	No	Required for change resize, and ignored otherwise: the new canvas shape, by name or ratio ("9:16"). It must differ from the design's own, or the redo is a charge for nothing.
`instructions`	Yes	What to change, in plain words. Anything you do not mention stays as it is.
`designSystemId`	No	A design system id from list_design_systems, the look to make it in. Omit for the design system the design was made in.
`expectedCredits`	No	The credits the dryRun quoted and the user agreed to. The call is refused if it would cost a different amount.

Output Schema

Name	Required	Description	Default
No arguments

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.5/5.0

Behavior5/5

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

Beyond the annotations it discloses the credit economics per mode (1 design / 50 credits vs. 240 for animate), the expectedCredits price-lock refusal, the 2-minute requestId retry window with no re-charge, the 1-5 minute latency, and exactly what the call returns (jobId, creditsCharged, creditsRemaining). The destructiveHint is given concrete substance, since 'replace' deletes the original's current file and that restriction (not for resize/animate) is stated.

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: the purpose and mode enumeration come first, then pricing, then the call protocol, so an agent can stop reading early for a quick call. It is dense and long, with several run-on clauses (cost, retry, permission, polling) stacked in single sentences, which costs a point on readability rather than on wasted content.

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?

Though it has an output schema, the description still covers what matters operationally: what comes back, how long it takes, that a job panel means do not poll, and the exact follow-up call in each branch. For an 11-parameter, credit-charging, asynchronous, potentially destructive tool, nothing an agent needs to call it safely 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 100%, so the bar for extra value is high, and the description clears it for the workflow parameters: it explains that dryRun is a quote-only call to run first, that expectedCredits must match the quoted amount or the call is refused, and that requestId must be new per request but repeated verbatim on a retry. Other parameters (aspectRatio must differ from the design's own; entityId for subject) are covered adequately by the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb-plus-resource statement ('Redo a finished Rawa design … keeping its editable layers') that immediately enumerates the five modes (copy, graphics, subject, resize, animate), so an agent knows exactly what capability this is. It loses the top mark because it never names the closely-related siblings (resize_creative, edit_creative) that an agent must choose between for the resize and copy cases.

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 states the preconditions ('Works on any finished design of the brand, from list_creatives or the gallery'), the mandatory dryRun-first protocol, and the follow-up branch: use show_creatives if a job panel appears, otherwise wait_for_jobs with jobIds until allFinal. It also names the permission gate and points to get_workspace to check it, so the agent knows the fallback when generation is not allowed.

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?