Rawa

Generate designs

generate_design

Generate designs for a brand, such as ads and social posts: finished, on-brand designs made by Rawa from the brief, one or more per concept. To put a headline, copy or a layout on the user's own photo and keep the photo exactly as it is, pass it as the concept's photoCreativeId: the type is set in the brand's fonts as editable layers, not painted into the picture. Cost: every design is charged, and a call makes concepts × designsPerConcept of them, priced by format. 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 jobs, one jobId per concept, 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
`brief`	Yes	What the campaign is for, in the user's own words: the offer, the occasion, the audience, the tone.
`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.
`format`	Yes	Per design: still is a still image, 50 credits. motion is an animated clip designed scene by scene, 3, 5, 6, 8, 10, 15, 20, 30 s long (default 6), 40 credits a second.
`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.
`concepts`	Yes	One entry per creative idea. Each becomes its own job.
`entityIds`	No	Ids from list_entities of the products, places, ambassadors or design elements the design must feature. The designer uses that entity's real images, so only name what the user asked for.
`placement`	No	Where the ads will run, so the designer keeps that platform's safe zones clear. instagram_feed: Instagram / Facebook feed (1:1 or 4:5); instagram_story: Instagram / Facebook Stories (9:16); instagram_story_ad: Instagram / Facebook Stories ad (9:16); instagram_reels: Instagram Reels (9:16); instagram_reels_ad: Instagram Reels ad (9:16); tiktok_organic: TikTok (organic) (9:16); tiktok_ad: TikTok in-feed ad (9:16); snapchat: Snapchat Story (9:16); snapchat_ad: Snapchat Snap Ad (9:16); linkedin_feed: LinkedIn feed / sponsored (static) (1:1, 4:5 or 1.91:1); linkedin_video: LinkedIn feed (video) (9:16); linkedin_video_ad: LinkedIn sponsored (video) (9:16); google_display: Google Display (responsive) (1:1 or 1.91:1); youtube_instream: YouTube in-stream (16:9); youtube_shorts: YouTube Shorts (9:16); youtube_shorts_ad: YouTube Shorts ad (9:16). Omit for a plain margin on every edge.
`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.
`audienceId`	No	An audience id from list_audiences; the designs then read that audience's age, gender, language, markets, voice and photography.
`aspectRatio`	Yes	The canvas shape of every design, by name or ratio ("9:16" is portrait_9_16).
`designSystemId`	No	A design system id from list_design_systems, the look to make it in. Omit for the audience's own design system when it has one, otherwise the brand's default.
`durationSeconds`	No	motion only: the clip length in seconds, one of the lengths motion lists.
`expectedCredits`	No	The credits the dryRun quoted and the user agreed to. The call is refused if it would cost a different amount.
`designsPerConcept`	No	How many different designs to make for each concept. Defaults to 1. The call makes concepts × designsPerConcept designs, each charged.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields 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."

addedInput schema / properties / concepts / items / properties / photoCreativeId

Added value: +{
+  "description": "Id of a finished image in the brand's library (from get_upload, list_creatives or search_library) to build this concept on, kept as it is: it is the design's image, only cropped, sized and placed, never filtered, tinted or redrawn, and the headline, copy and graphics are designed around it. Use it whenever the user wants text or a layout on their own photo. No other imagery is made for the concept. Only with format still. A photo the user pasted or attached in the chat goes through request_image_upload first.",
+  "type": "string"
+}

addedInput schema / properties / concepts / maxItems
```
Added value: +12
```

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / audienceId / description

Previous value: -"An audience id from list_audiences; the designs then read that audience's markets, voice and photography."New value: +"An audience id from list_audiences; the designs then read that audience's age, gender, language, markets, voice and photography."

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description discloses charging behavior (every design charged, cost = concepts × designsPerConcept, priced by format), dry-run quoting, expectedCredits refusal, retry deduplication within two minutes, permission requirements, and output timing. These are exactly the behavioral traits an agent needs for a costly, non-idempotent mutation with asynchronous completion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence carries a distinct operational rule for a complex, high-cost, asynchronous tool. Purpose, photo handling, cost, retry, permissions, outputs, and polling are front-loaded in a sensible sequence with no filler.

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 tool's complexity, 14 parameters, output schema, and asynchronous job model, the description covers the essential context: cost flow, dry-run requirement, retry behavior, permission checks, return shape at a high level, timing, and job-tracking alternatives. The output schema's existence means return values need not be fully restated, but the description still orients the agent adequately.

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 100% and the input schema already documents every parameter in detail. The description still adds cross-parameter meaning beyond the schema, especially the cost formula involving concepts and designsPerConcept, the expectedCredits refusal condition, requestId retry semantics, and photoCreativeId's exact preservation behavior.

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 opens with a precise verb and resource: generating finished, on-brand designs from a brief, one or more per concept. It implicitly distinguishes itself from generate_image by emphasizing full designs made by Rawa, and it explicitly distinguishes the photoCreativeId path where the user's photo is kept intact rather than generated.

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 operating instructions: call with dryRun first, tell the user the cost, then pass expectedCredits after agreement; use a new requestId per request and repeat only on retry. It also routes the agent correctly for job tracking: if a job panel shows, do not poll and use show_creatives later; otherwise call wait_for_jobs until allFinal is true.

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?