Skip to main content
Glama

higgsfield

Generate or edit videos inside Takes using Higgsfield models, including Seedance, Kling, and Veo. Jobs run in the background and save to the session's generated folder.

Instructions

Make or change a video with Higgsfield (Seedance, Kling, Veo and 30+ more video models) from inside Takes. Video only: images go to make_image. Returns at once; the job runs in the background and the file lands in /generated/-vN, where the Assets tab shows it. With shot= the storyboard shot shows 'Generating' and then plays the clip (aspect ratio = the storyboard format, length = the shot's length, 4-15 s). For a shot, write a real-footage prompt from the shot's do and say (subject, setting, light, camera move); pass image='sketch' to use the sketch only as a composition reference with params {mode: omni_reference}, and say in the prompt that the result is real footage, not a drawing. Change a video: video= with params {mode: video_edit} (Seedance), or workflow=reframe with aspect_ratio for a new shape. Default model: the one the user picked on Plugins › Higgsfield (higgsfield_status default_model); other models by id (higgsfield model list in Bash; higgsfield model get <id> for params). Each job costs the user's Higgsfield credits: one job per ask, never a batch nobody asked for. Not installed or not signed in: tell the user to open Plugins › Higgsfield.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoShort file name. Default: shot-<id> or the prompt's first words.
shotNoA storyboard shot id: the clip becomes that shot's video.
imageNoA reference image: a session file, or 'sketch' for the shot's sketch.
modelNoA Higgsfield model id. Leave out for the default.
videoNoA session video to change or reframe (take number or path).
paramsNoMore model params, e.g. {"mode": "omni_reference", "resolution": "1080p"}.
promptNoWhat the result shows. Not needed for workflow=reframe.
sessionYesSession as 'Project/folder', an absolute path, or its id (from get_session). An old path still works after a rename or move.
durationNoSeconds (video).
workflowNoreframe (new aspect ratio) or draw_to_video.
end_imageNoLast frame (session file).
start_imageNoFirst frame (session file or 'sketch').
aspect_ratioNoe.g. 16:9, 9:16, 4:5, 1:1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds the behaviors that actually matter: it returns at once and the job runs in the background, output lands at <session>/generated/<name>-vN and surfaces in the Assets tab, each job costs the user's Higgsfield credits, and it must be one job per ask rather than a batch. It also discloses the storyboard 'Generating' state transition.

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 purpose, scope, and return behavior before the workflow detail, and nearly every sentence carries operational content. It is still a dense multi-clause block with parenthetical model lists and inline JSON, which makes it heavier to parse than an ideal single-purpose description.

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 mutation tool with no output schema, the description covers the missing pieces: asynchronous return semantics, where the artifact lands, cost/credit implications, storyboard integration, and the three edit workflows. An agent has everything needed to invoke it correctly without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 real semantics beyond it: shot=<id> binds the clip to a storyboard shot and inherits aspect ratio and length, image='sketch' is a composition-only reference requiring params {mode: omni_reference}, video= plus {mode: video_edit} selects the edit path, and workflow=reframe pairs with aspect_ratio. Default model resolution is also explained.

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?

Opens with a specific verb+resource ('Make or change a video with Higgsfield') and names the model family backing it (Seedance, Kling, Veo, 30+ more). It immediately differentiates from the nearest sibling: 'Video only: images go to make_image.' An agent can route between this and make_image without opening either schema.

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 branches: generate vs. change (video=<session file> with mode video_edit), reframe via workflow=reframe, and storyboard use via shot=<id> including how to write the prompt from the shot's do/say. It also states the exclusion (images → make_image) and the fallback when the plugin is missing or unauthenticated.

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