Skip to main content
Glama
Sign In
Foldline

Foldline

by alireza12t
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Mux and master sound

mux_audio

Mux a mix onto video with two-pass loudness normalization to -14 LUFS and -1.2 dB true peak; pads or trims audio to match frames, optionally adds grain, and returns output path plus loudness.

Instructions

Puts a mix under the video: two-pass loudness to -14 LUFS, true peak -1.2 dB, optional film grain. A mix shorter than the video is padded with silence, a longer one cut at the end. Before handing over, it checks the frame count and that the sound starts and ends with the picture. Returns the output path and the measured loudness.

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": {
      "video": "<video>",
      "audio": "<audio>",
      "out": "<out>"
    },
    "name": "mux_audio"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNoDefault 24.
outYes
audioYesThe mix, e.g. mix.wav.
grainNoFilm grain, 0 for none. Default 2.
videoYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does substantial work: it discloses the two-pass loudness target, true peak ceiling, optional grain, and precise pad-with-silence vs cut-at-end semantics for length mismatch. It also states the pre-handover validation (frame count, audio starting and ending with picture) and what is returned. Gaps remain around codec/container selection, overwrite behavior at the output path, and error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and the technical profile, then behavioral edge cases, then the return contract. No filler or restated name.

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 five-parameter processing tool with no output schema and no annotations, the description covers the operation, length-mismatch policy, validation, and return values, which is most of what an agent needs. Minor omissions are fps handling and output-path conventions.

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 60% and the description adds little parameter-level detail beyond what the schema already says; audio, fps default, and grain are documented in the schema. The description's 'optional film grain' merely echoes the grain parameter, and the undescribed `out` and `video` parameters get no clarification of format or overwrite semantics. Baseline 3 given partial schema coverage.

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?

'Puts a mix under the video' is a specific verb+resource, and the sentence immediately adds the concrete processing profile (-14 LUFS two-pass, -1.2 dB true peak). This clearly separates it from render_video, render_stills, and make_voice siblings without needing to open the schema.

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

Usage Guidelines3/5

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

Usage is implied by the description ('Puts a mix under the video'), so an agent can infer it applies after a video and a mix exist. However, there is no explicit when-to-use or when-not guidance, and no naming of alternatives such as render_video for cases where audio should be handled differently.

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