Skip to main content
Glama
Sign In

Wandura

by ai.wandura
OverviewDiscussionsAdmin

clone_template

Clone a template into a real video generation. SPENDS CREDITS. Returns a job id immediately; call get_generation to follow it. The job completes even if nothing polls it.

Input Schema

NameRequiredDescriptionDefault
avatarNoPresenter. Omit to keep the template's own.
intentNoShort description of what the user wants, max 200 chars. NOT a prompt — the server assembles the final prompt.
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.
productNoProduct to advertise. Omit to keep the template's own product.
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.
qualityNoQuality tier. Model ids are server-owned and never accepted here.
overridesNoOnly set these to DELIBERATELY deviate from the template. Leaving them out is what makes it a faithful clone — the template decides aspect and duration.
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).
templateIdYes
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/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: it is a credit-spending operation, it is asynchronous ("Returns a job id immediately"), and the job completes even if unobserved. That last point is critical for an agent deciding whether it must poll, and none of it is derivable from readOnlyHint=false / idempotentHint=false.

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?

Four short sentences, all front-loaded with the most consequential fact (credit spend) second. Nothing is redundant or padded.

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 a 10-param, nested-object, async mutation tool with no output schema, the description covers the essentials: cost, immediate return value, follow-up tool, and guaranteed completion. It does not state that repeated calls spend credits again, nor where a templateId comes from, but the schema fills most remaining gaps.

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 description coverage is 90%, so the schema already carries nearly all parameter meaning (overrides, intent, workspace scoping, user_request verbatim rules). The description contributes nothing parameter-specific, so the baseline 3 applies.

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?

"Clone a template into a real video generation" states a specific verb (clone) and resource (template → video generation), which separates it from preview/apply-style siblings. It never explicitly names which sibling to use instead (e.g. cinematic_ads_apply_template or preview_render), so it falls just short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by "SPENDS CREDITS" and the hand-off instruction "call get_generation to follow it," which tells the agent the correct follow-up tool. However, there is no explicit statement of when to choose this over render_video, cinematic_ads_apply_template, or the preview tools.

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