Skip to main content
Glama
Sign In
character-forge-mcp

character-forge-mcp

by gdhub-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Looping idle video

character_video

Turns a character scene image into a short looping idle clip with configurable model, audio, loop style, and cost confirmation before generation.

Instructions

ONLY on request, after character_scene. Animates scene.png into a looping idle clip (default Kling O1 Standard ≈ $0.084/s, silent; veo ≈ $0.15/s with sound). See loop for how the clip is closed into a loop. Confirm the cost with the user first.

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": {
      "id": "<id>"
    },
    "name": "character_video"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
loopNoframe (Kling default): last frame = first frame, but the background tends to freeze and the motion can jerk at the seam. crossfade (Veo default; Veo also keeps the first = last frame): the last second is blended into the first, picture and sound, so the seam never jerks. off: plain clip.
audioNoVeo only: default true ($0.15/s; $0.10/s without). Kling has no sound.
modelNoDefault from models.json. kling (Kling O1 Standard ≈$0.084/s, no sound) · veo (Veo 3.1 Fast 720p, native sound $0.15/s or silent $0.10/s, 4/6/8 s).
notesNoCorrections on top of the default prompt for this take, in plain words (e.g. 'his height must read against the ceiling', 'hands stay off the barometer'). Use this to fix a result instead of rewriting the whole prompt.
promptNoSmall cyclical motions only: breathing, blinking, a habitual gesture, ambient motion; static camera; returns to the start pose.
secondsNoDefault 8: room for one characteristic gesture and a return to the first-frame pose.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it does most of it: cost per second for each model, the silent-vs-sound tradeoff, and the default model. It omits what happens on failure, whether an existing clip is overwritten, and expected generation time, which are real gaps for a paid mutation with a 30 s cap.

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 gating constraint ('ONLY on request'), then pricing, then the loop reference and the confirmation requirement. Dense but every clause carries information; the nested parentheticals on cost are the only mild clutter.

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?

Covers the costly, prerequisite-heavy parts well: sequencing, pricing, model defaults, and the user-confirmation step. For a seven-parameter paid generation tool with no output schema, it should still say what comes back (clip path or id) and what 'see loop' concretely changes about the result.

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 coverage is 86%, so the enum descriptions already explain loop, audio, and model semantics in detail; the description mainly restates the default model and its price. It adds little syntactic or behavioral meaning beyond the schema, so the baseline 3 applies.

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?

Specific verb and resource: 'Animates scene.png into a looping idle clip', with the input artifact and the output type both named. The phrase 'after character_scene' situates it in the pipeline relative to a sibling, so an agent knows this is the step that follows still creation rather than an alternative to it.

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 gating conditions: 'ONLY on request, after character_scene' tells the agent when not to call it, and 'Confirm the cost with the user first' adds a required pre-call interaction. It also points to the 'loop' parameter/related reference for closure behavior, 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.

Deploy Server

Other Tools