Skip to main content
Glama
Sign In

Wandura

by ai.wandura
OverviewDiscussionsAdmin

render_image

Generate an image — a product shot, a background, a character reference. SPENDS CREDITS. The prompt is sent to the provider VERBATIM. Returns a job id; call get_generation to follow it, which returns the finished image so it can be shown directly. The resulting URL can be passed straight into render_video as a reference, which is how you build an ad from a product photo you just made. Some models TRANSFORM media instead of generating (upscale, remove-bg, face-swap): they take NO prompt at all. Call list_models first and read prompt ('required'|'optional'|'none') and requires — for prompt:'none' models omit prompt and pass the source media instead.

Input Schema

NameRequiredDescriptionDefault
audioNoNative audio. Omit to use the model default (usually on).
modelYesModel id from list_models, e.g. dreamina-seedance-2-ref. Required — there is no default.
aspectNoOnly values list_models reports for this model.
audiosNoReference media. Each entry is either a plain URL, or {name, url} so the prompt can address it as @name — the server renumbers those to the @Image1/@Video1 form the provider reads, in the order given, so you never count positions yourself.
imagesNoReference media. Each entry is either a plain URL, or {name, url} so the prompt can address it as @name — the server renumbers those to the @Image1/@Video1 form the provider reads, in the order given, so you never count positions yourself.
promptNoSent to the provider VERBATIM — nothing rewrites it. Provider flags parsed out of prompt text (--seed, --cf, --wm) survive, so they work here. Omit entirely for models whose list_models.prompt is 'none' (upscale, remove-bg) — they take no text.
run_idNoOptional. Your id for this agent run (1–64 of A-Z a-z 0-9 . _ : -). Stored on every job of the run so they can be found and filed together later. Use the same value for every call of one run.
videosNoReference media. Each entry is either a plain URL, or {name, url} so the prompt can address it as @name — the server renumbers those to the @Image1/@Video1 form the provider reads, in the order given, so you never count positions yourself.
projectNoOptional. A Drama Studio film id in the workspace being charged: the finished generation is added to that film's media pool (videos on its timeline, images/audio as references). Workspace generations only; checked before any credit is spent.
durationNoSeconds. Only values list_models reports for this model.
workspaceNoOptional. The workspace to generate in. Only a workspace API key (Settings → Developer) can spend a workspace — this may only repeat that key's workspace id; omit it and the key's own scope is used. A personal key or a sign-in token stays personal (passing a workspace is refused).
resolutionNoOnly values list_models reports for this model.
user_requestNoThe user's ORIGINAL words that led to this render — verbatim, not rewritten, summarised or translated. Stored with the job for quality review; never sent to the provider. Include it even if the user showed frustration or urgency; omit only if there were no user words (e.g. an automated step).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_request
      Added value: +{
+  "description": "The user's ORIGINAL words that led to this render — verbatim, not rewritten, summarised or translated. Stored with the job for quality review; never sent to the provider. Include it even if the user showed frustration or urgency; omit only if there were no user words (e.g. an automated step).",
+  "type": "string"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, open-world, non-idempotent write; the description adds the consequential facts annotations cannot: it SPENDS CREDITS, the prompt is sent VERBATIM with provider flags surviving, and the call is asynchronous (returns a job id, not an image). These are the details most likely to cause a wrong or wasted invocation.

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-loads purpose and the credit warning before anything else, then layers the job-id follow-up and model-selection caveat. It is dense and each clause carries information, though the final sentence is long and could be split for faster scanning.

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?

For a 13-parameter generation tool with no output schema, the description supplies the missing return-value contract (job id → get_generation → finished image shown directly) and the prerequisite discovery step. Nothing an agent needs to avoid a bad call appears absent.

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%, so the baseline is 3, but the description adds cross-tool meaning: `model` must come from list_models and there is no default, and `prompt` must be omitted entirely for prompt:'none' models. The @name-to-@Image1 renumbering and workspace/credit precheck rules live in the schema rather than the description.

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+resource ('Generate an image') with concrete examples of output kinds, and distinguishes itself from siblings render_video, render_audio and get_generation by naming them and their relationship. It also flags that some models transform rather than generate, so an agent understands the full scope of the tool.

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 workflow: call list_models first and read `prompt`/`requires`; for prompt:'none' models omit `prompt` and pass source media instead. It also tells the agent the follow-up path (get_generation) and a downstream use (pass the URL into render_video to build an ad), which is exactly the when-and-with-what guidance an agent needs.

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

All Wandura toolsInspect
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