rendercheck MCP server

rendercheck

<!-- mcp-name: io.github.rogermsc/rendercheck --> <!-- The line above is not decoration. The MCP registry proves who owns a PyPI package by fetching its README and looking for that marker, so it has to ship inside the published long_description. Removing it un-verifies the registry listing on the next release. See server.json. -->

The worst bugs in generated media don't throw.

"the audio often cuts off the final sentence […] though the API returns

success without error signals"

— a developer on the OpenAI forum,

April 2026, describing production output

If you generate speech or video with a model — TTS, voice agents, podcasts, avatars, AI video — your tests catch the exception that never happens. They do not catch the narration that reads at 300 words per minute, the voice track sitting 18 dB below the footage it's cut against, the clip that rendered at 42% length and got cached as a success, the captions that describe the audio three seconds before it happens, or the file whose audio track is missing entirely.

The 2026 state of the art for catching these is a person listening to the output. That works, and it costs more than everything else in your pipeline combined.

rendercheck makes them throw.

from rendercheck import assert_pace, assert_loudness, looks_ok

assert_pace("episode-12.mp3", "episode-12.vtt")
assert_loudness("episode-12.mp3")
looks_ok("slide-14.png", ["the title fits on one line"])

Plain assert functions. No framework, no runner, no service. They raise AssertionError, so they already work in pytest, in CI, or in a five-line script. Eighteen of the nineteen checks have no dependencies and make no network calls — if you have ffmpeg, you're ready.

Quickstart

You need ffmpeg on your PATH (brew install ffmpeg, apt-get install ffmpeg, or winget install ffmpeg). Then:

pip install rendercheck
rendercheck demo

Or drop a file into the playground — same checks, running on ffmpeg compiled to WebAssembly, nothing uploaded.

demo synthesises ten defective files and runs the real checks against them, so you can see it fire without owning a broken render. Verbatim, first two of eight:

Narration too fast
  A voice picked to match a presenter's face read English at machine-gun speed. Valid audio, correct timing, perfectly in sync.

  $ rendercheck check machine-gun.wav --script narration.vtt

  FAIL  pace        narration pace 300 WPM exceeds 245 (300 words in 60.0s) -- this reads as machine-gun delivery and listeners cannot follow it: machine-gun.wav
  PASS  loudness    -16.1 LUFS
  PASS  dead air    0.0 s silence
  PASS  truncation  8.9 dB of fall-off at the end
  PASS  clipping    0 samples at 0 dBFS

Levels that don't match
  Synthesised narration landed 18 dB under the footage it was cut against. Nobody noticed until viewers rode the volume knob.

  $ rendercheck check too-quiet.wav

  SKIP  pace        no --script given
  FAIL  loudness    -34.2 LUFS is 18.2 dB quieter than the -16 target -- it will sound inaudible next to correctly-levelled audio cut alongside it: too-quiet.wav
  PASS  dead air    0.0 s silence
  PASS  truncation  8.8 dB of fall-off at the end
  PASS  clipping    0 samples at 0 dBFS

…and one of the two added in 0.3.0:

Shortened. The full README is on GitHub.