MakersMCP

Overview Schema Source Related Servers Discussions Admin

Fit a track to a video

fit_music

Fits a music track to a video cut by trimming or looping whole bars, aligning the drop to a chosen hit, ending on a beat, ducking under voice, and setting loudness.

Instructions

Fits a music track to a video cut: makes it exactly the given length by cutting or looping whole bars, lands its drop on the hit, ends it on a beat, ducks it under a voice and sets its loudness. Writes fitted.wav, cues.json (every beat, bar, seam and the hit, in seconds and frames), seams.png and FIT.md (what was done and where to listen). Give cues.json to check_video to check the cuts land on the beat. (musicfit 0.1.2, on this machine.)

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": {
      "track": "<track>",
      "length": "<length>"
    },
    "name": "fit_music"
  }
}

Input Schema

Name	Required	Description
`bpm`	No	The tempo, when the one found is half or double the real one.
`end`	No	How it ends: auto, natural (the track's own ending) or fade (default auto).
`fps`	No	Frame rate for frame numbers, like 30, 25 or 29.97 (default 30).
`hit`	No	Where the drop lands in the result, in seconds or frames like 825f.
`drop`	No	Where the drop is in the track (default: found).
`duck`	No	How far the music dips under the voice, in dB (default 10).
`fade`	No	Length of the closing fade, in whole beats (default a bar).
`lufs`	No	Loudness target in LUFS (default -14).
`meter`	No	Beats to a bar (default: found).
`track`	Yes	The music file, or a video whose sound to use; anything ffmpeg reads.
`voice`	No	A voice track on the video's timeline; the music dips under it.
`length`	Yes	How long the result is: seconds like 32 or 32s, frames like 960f, or 1:05.
`out_dir`	No	Folder to save into, absolute or relative to /app. Default: musicfit-{stem:track}.
`wait_seconds`	No	How long to wait for the result before returning a job_id to wait on. 45 is safe for clients that stop a tool call after 60 seconds.

Output Schema

Name	Required	Description
`kit`	Yes
`tool`	Yes
`files`	No
`folder`	No	Where the kit saved its files.
`job_id`	Yes
`passed`	No	For checks: whether the check passed.
`status`	Yes
`exit_code`	No
`last_line`	No	What the kit was doing last.
`expires_at`	No	When the download links stop working.
`next_action`	No
`elapsed_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare the generic profile (not read-only, not destructive, not idempotent); the description goes further by naming every file written to disk and what each contains, which is the real side effect an agent needs to know. It also flags the long-running behavior indirectly via the wait_seconds documentation and the job_id fallback. It stops short of saying whether an existing out_dir is overwritten or what happens on partial failure.

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?

Two dense sentences, front-loaded with the core operation and followed by outputs and the check_video handoff. Every clause carries content, though the closing parenthetical version/environment note is the weakest element and some clauses stack heavily in sentence one.

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 14-parameter mutation tool this covers the essentials: what it does, what it emits, the downstream verification path, and the async/timeout contract hinted via wait_seconds and job_id. An output schema exists so return-value detail is not required. Missing only edge-case behavior such as overwrite policy and error handling for unreadable inputs.

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 earns more by explaining the intent behind parameter pairs rather than restating them: cutting/looping to hit "exactly the given length" (length), landing "its drop on the hit" (drop + hit), "ends it on a beat" (end), "ducks it under a voice" (duck + voice), and "sets its loudness" (lufs). This tells an agent how the knobs interact, which the schema does not.

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 ("Fits a music track to a video cut") and immediately enumerates the concrete transformations: exact length by cutting or looping whole bars, drop lands on the hit, ends on a beat, ducked under voice, loudness set. This is unmistakable against siblings like analyze_music or make_launch_film, and the produced artifacts (fitted.wav, cues.json, seams.png, FIT.md) sharpen the boundary further.

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

Usage Guidelines4/5

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

Explicitly names the downstream alternative and the condition that selects it: "Give cues.json to check_video to check the cuts land on the beat." It does not address when to prefer analyze_music for tempo/drop detection alone or how this fits before/after render_launch_film, but the primary handoff is spelled out clearly.

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

Deploy Server