Skip to main content
Glama

WIA Motion: product video campaigns

create_campaign

Create a wiamotion product video campaign from 1-4 product photos. Produces finished 1080x1920 video(s) + thumbnail(s) + multi-language metadata (never a raw/unfinished clip) and deducts credits from the caller's account. Package tiers: "trial" (1 video, watermarked, 25cr, 3-language metadata), "starter" (1 video, 50cr, 254-language metadata), "launch" (3 videos — hook/how-to/brand mood — 254-language metadata, 125cr), "story" (everything in launch plus one 60-90s cinematic brand short on a premium engine, 400cr). DIRECT YOUR OWN CINEMATOGRAPHY: write distinct scene prompts (English, one short cinematic camera direction each) — this is what makes the result good, the server will not invent creative direction for you. Videos are subtitle-free by default (globally reusable); on-screen text (hook_text / endcard_text) is OPT-IN — omit both unless you specifically want burned-in copy for one language. For "starter"/"trial" use scenes[] (2-4 scenes, one video). For "launch"/"story" use hook_scenes[]/howto_scenes[]/brand_scenes[] (2-4 scenes each, one set per video role) — omit any of these to fall back to a generic template for that video. For "story" additionally use story_scenes[] (8-12 scenes) for the brand short — think in classic beats: hook, development, climax, resolution into the endcard. The server always appends a standard anti-distortion guard to every scene prompt server-side (keeps the product/printed text exactly as in the reference photo, no warping) — do not add your own "no distortion" wording, just describe the shot. Prefer image_urls over images_base64 when the photos are already hosted somewhere — base64 request bodies are capped at 8MB total (~1MB/photo) and get rejected past that. "creator" (200 credits, 2026-09-25) = a realistic on-screen presenter holds the product and speaks YOUR script with lip-sync (~12s, up to 15s): pass persona (who appears), setting (where), language, script (what they say — hook first, then proof), optional gender (voice) and direction (gestures/beats). scenes/hook_text/bgm are ignored for creator. Returns a job_id — poll it with check_campaign.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product_name": "<product_name>"
    },
    "name": "create_campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
genderNo"creator" only — voice gender (default f).
scenesNo"starter"/"trial" only — 2-4 distinct scenes cut together for the single video (no looping/padding). Omit to fall back to a generic 2-scene hero+detail template.
scriptNo"creator" only — the spoken line, about 12 seconds (ja/zh ≤90 chars, ko ≤120, en/ar/hi ≤200, others ≤260).
packageNoPackage tier — see tool description for what each builds and costs.starter
personaNo"creator" only — who appears on screen: age, look, outfit, mood.
settingNo"creator" only — where it is filmed: place, light, camera.
bgm_moodNoBackground music mood, applied to every video in the campaign. Omit for a deterministic per-job default.
languageNo"creator" only — spoken language of the script.
directionNo"creator" only — optional gestures, camera moves and beats.
hook_textNoOPTIONAL on-screen hook headline, ≤30 chars. Text overlays are opt-in — OMIT for clean, no-caption output that is reusable in any language/market (the default). Provide only when you deliberately want burned-in text (locks the video to that one language).
image_urlsNo1-4 publicly fetchable URLs — either direct product photo files (jpg/png), or product detail-page URLs (e.g. a Coupang/Amazon listing) with an og:image/twitter:image meta tag, which the server will fetch the photo from automatically. Preferred over images_base64.
brand_chainNo"launch"/"story" only. When true, each brand_scenes[] shot after the first is generated from the LAST FRAME of the previous shot instead of the original product photo — use this when your scenes describe a continuous transformation (e.g. a hand finishing a drawing, then holding the finished result) that must stay visually consistent across shots. Costs the same credits as a normal launch/story campaign — no extra charge. Omit (default false) for independent shots, each anchored to the original product photo.
descriptionNoShort product description
hook_scenesNo"launch"/"story" only — 2-4 scenes for the hook video. Omit to fall back to a generic hero+detail template.
brand_scenesNo"launch"/"story" only — 2-4 scenes for the brand-mood video. Omit to fall back to a generic atmospheric-lifestyle template.
endcard_textNoOPTIONAL text on the closing brand card, ≤30 chars. Omit (default) for a clean logo-only endcard with no copy — globally reusable. Provide only to burn in a caption for one specific language.
howto_scenesNo"launch"/"story" only — 2-4 scenes for the how-to/demo video. Omit to fall back to a generic hands-on-demo template.
product_nameYesProduct name
story_scenesNo"story" only — 8-12 scenes for the 60-90s cinematic brand short (hook → development → climax → resolution). Omit to fall back to a generic dome-style 8-scene template.
images_base64No1-4 base64-encoded product photos, alternative to image_urls. Total request body capped at 8MB — use image_urls for larger photos.
accept_text_riskNoSet true ONLY after the user explicitly agrees to proceed despite a source_text_risk rejection (the uploaded image contains heavy printed marketing copy, which AI video generation will garble; garbled text is then not refund-eligible). On a 422 source_text_risk error, explain the risk to the user and ask before retrying with this flag.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare non-readonly, non-idempotent, open-world behavior, and the description adds substantial context beyond them: exact credit deductions per tier, the 8MB base64 cap, the server-side anti-distortion guard, subtitle-free defaults, and refund ineligibility for garbled text. This is exactly the 'what gets consumed and what could go wrong' disclosure an agent needs for a costly write operation.

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 purpose and output, then organized into package tiers, cinematography guidance, and creator-mode specifics. It is dense and long, but for a 21-parameter branching tool nearly every sentence carries distinct operational information rather than 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?

For a 21-param, no-output-schema tool, the description covers costs, fallback behavior when scene arrays are omitted, image-input constraints, the creator package's differing contract, and the polling follow-up. An agent could invoke this correctly across all five package tiers without opening the schema.

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 goes further by explaining cross-parameter relationships the schema cannot (which scene arrays apply to which package, that scenes/hook_text/bgm are ignored for 'creator', and the credit cost per package). It does not restate every parameter, but the added tier-to-parameter mapping is genuinely useful.

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 ('Create a wiamotion product video campaign from 1-4 product photos') and immediately defines the output (1080x1920 videos, thumbnails, multi-language metadata). It is clearly distinguishable from siblings check_campaign (polling) and list_packages (enumeration), and the closing 'poll it with check_campaign' reinforces the distinction.

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?

Gives explicit when-to-use routing across package tiers, which scene arrays map to which tier, when to prefer image_urls over images_base64, and when to opt into burned-in text. It also names the follow-up tool ('poll it with check_campaign') and the escape hatch for source_text_risk rejections, leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources