/widget-forms

name: widget-forms
description: Use when the agent should ask the user for structured input with an in-chat form, including single-select, multi-select, text fields, style pickers, or voice audition choices.

Widget Forms

Use the form tool instead of hand-writing markup: the editor chat renders the form as an interactive card and returns the user's structured answer.

Runtime Rule

Call `ask_followup_questions`. It serializes your fields into the editor's native form card; the user's submission comes back as their next message.

Plan the whole questionnaire before calling the tool. Send one final form, not a trial form followed by a corrected form. The tool supports at most 12 fields; if the user asks for more questions, merge related prompts into combined fields before the first call.

After calling `ask_followup_questions`, stop the turn and wait for the submitted answer to appear in chat. Do not apply a choice, create assets, or continue planning from a recommendation until the user's selection is present in the conversation.

Supported Field Mapping

Build a `fields` array. Write every visible string in the user's conversation language.

• Native `<form-single>` -> `{ type: "single", variant: "default" }`
• Native `<form-multi>` -> `{ type: "multi", variant: "default" }`
• Native `<form-text>` / `<form-textarea>` -> `{ type: "text" }`
• Native `<form-visual>` -> `{ type: "single", variant: "visual" }`
• Voice audition cards -> `{ type: "single", variant: "voice" }`
• Native start-scenario cards -> `{ type: "single", variant: "scenario" }`

Form Copy Tone

For form-level text (`title`, `prompt`, `fields[].label`, `submitLabel`, and `messagePrefix`), write like OpenChatCut is a capable video-making partner inviting the user to describe what they want, not like a rigid survey.

Aim for:

• Warm, open-ended, and action-oriented. The copy should imply "choose the

closest video need or just tell me your idea; we can figure it out together."

• Short and scannable. Use one natural sentence for `prompt` and concise

question labels.

• Honest capability framing. OpenChatCut can help with many video workflows, but do

not claim unsupported abilities or guarantee a result before inputs are known.

• The user's language and local product terms. Keep "OpenChatCut", "B-roll",

"Motion Graphics", "MG 动画", model/product names, and platform names in their established forms.

• User-facing creative wording. For early planning or creative-intake forms,

prefer natural terms such as idea, direction, plan, story, shot list, audience, mood, or video need over internal production-document language.

Avoid stiff labels such as "Select video type", "Please choose the video type for this project", or "What type of video do you want to make?" for scenario intake unless the host has no room for warmer copy.

For a scenario-intake form, prefer copy like:

{
  "title": "What do you want to make?",
  "prompt": "Choose the closest video scenario, or choose Something else and describe your idea.",
  "submitLabel": "Start creating",
  "messagePrefix": "I want to start with this video direction:",
  "fields": [
    {
      "id": "scenario",
      "label": "Which scenario fits your video best?",
      "type": "single",
      "variant": "scenario",
      "otherPlaceholder": "For example: turn my travel footage into an atmospheric vlog / make a launch video for a new product"
    }
  ]
}

Do not include file-upload questions in forms. If a task actually needs source media and the project/chat does not already have it, ask the user separately to upload files in the editor (drag & drop or the upload button, or paste into the chat composer). File upload is not a default prerequisite for every questionnaire; only ask for it when the next editing step depends on missing media.

For choice fields:

• Use `id` for the internal value the next tool call needs.
• Use `label` for what the user sees.
• For ordinary single-select and multi-select cards (`variant: "default"`), keep

options label-only. Do not add per-option `description` unless the user cannot distinguish the choices from labels alone.

• Use `description` mainly for voice cards. Visual style cards should usually

use only `preview` + `label`.

• When an off-list answer is acceptable, add an explicit option with

`id: "__other__"` and a `label` in the same language as the rest of the form, using the word the user would expect for an off-list answer. The widget will turn this option into a text entry when selected. Use `otherPlaceholder` if the text entry needs a placeholder.

For visual cards:

• Use real image URLs or data image URLs in `preview`.
• For Design Style catalog choices, call `manage_design_style` with

`action: "list"` first, then map each returned preset to `{ id: preset.presetId, label: preset.name }` (no thumbnails in this build).

• Never hardcode catalog preset ids unless the user already selected one.

For voice cards:

• Use `audioUrl` for the sample file.
• Prefer the documented sample path such as `/voice-samples/doubao-liuchang.mp3`

or a public HTTPS URL. Do not pass localhost sample URLs; MCP host iframes do not reliably resolve editor-local media.

• Keep user-visible descriptions provider-neutral. Describe the voice the same

way the native OpenChatCut audition UI does: gender / age range / tone / use case, such as `Female / young / friendly, general` or `男 / 中年 / 低沉知识解说`. Do not show provider names like ElevenLabs or Doubao in option descriptions.

• Keep the option `id` equal to the provider voice id needed by `submit_voice`.

For native start-scenario cards:

• Use this when the user should choose which OpenChatCut video workflow to start,

such as talking-head editing, MG animation, long-video-to-shorts, product/app promo, AI short film, or explainer video.

• Present these as common video needs/scenarios, not as the only possible video

workflows. The form must also let the use