FableCut

fablecut_encode_profiles

Instructions

List what fablecut_export can make. DELIVERY PRESETS (structured settings, the Export dialog's Preset list): youtube, youtube-shorts, instagram-reels, tiktok, x, linkedin, master (project size), broadcast (ProRes 422 HQ), web (720p), archive (lossless FFV1), custom — plus presets the user saved — each a spec of resolution, fps, codec (h264, hevc, av1, vp9, prores, dnxhr, mpeg2 XDCAM, ffv1), rate control (crf / vbr / cbr), keyframe interval, pixel format, color, container, audio, a file-name template and metadata. {preset:'youtube'} returns one preset's full spec; the encoders this ffmpeg can use are listed (hardware ones only when they work on this machine). ENCODING PROFILES (encoding-profiles.json): raw ffmpeg argument lists plus jpegQuality, extension and color, for anything the presets do not cover; edit the file on disk (hot-reloaded); {profile:'hq'} returns one, detail:true includes every args array. Both are dry-run against ffmpeg when an export starts, so bad settings are refused before rendering.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fablecut_encode_profiles"
  }
}

Input Schema

Name	Required	Description
`detail`	No	Include the full ffmpeg args array per encoding profile (default: a truncated summary)
`preset`	No	Return one delivery preset's full spec (youtube, broadcast, a saved preset id …)
`profile`	No	Return one encoding profile by id instead of the full list

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.16.0Oct 21, 2026

changedInput schema / properties / detail / description

Previous value: -"Include the full ffmpeg args array per profile (default: a truncated summary)"New value: +"Include the full ffmpeg args array per encoding profile (default: a truncated summary)"

addedInput schema / properties / preset

Added value: +{
+  "description": "Return one delivery preset's full spec (youtube, broadcast, a saved preset id …)",
+  "type": "string"
+}

changedInput schema / properties / profile / description

Previous value: -"Return one profile by id instead of the full list"New value: +"Return one encoding profile by id instead of the full list"

Addedv1.9.0Sep 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it names the config file (encoding-profiles.json), states it is edited on disk and hot-reloaded, discloses that settings are dry-run against ffmpeg at export start so bad config is refused before rendering, and warns that hardware encoders appear only when functional locally. These are exactly the operational traits an agent cannot infer from the schema.

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?

The purpose is front-loaded and the two-mode structure is easy to scan. However, the long parenthetical enumerations of preset ids, codecs, rate-control modes, and container details are largely re-derivable from the tool's own output, making the middle section denser than it needs to be.

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 zero-required-parameter, no-output-schema discovery tool, the description supplies return shape (per-preset spec fields, truncated vs. full args arrays), the backing file, and the validation model. What the no-argument default call returns as a whole is only implied, which is the one gap.

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 3 is the floor, and the description earns extra by giving concrete usage forms ('{preset:"youtube"}' returns one full spec; '{profile:"hq"}' with detail:true includes every args array) and by clarifying that the default is a truncated summary. It largely echoes the schema's own wording, which keeps it from a 5.

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 concrete verb and resource: 'List what fablecut_export can make,' then splits the answer into two named categories (DELIVERY PRESETS and ENCODING PROFILES) with their backing artifacts. This distinguishes it cleanly from the sibling fablecut_export, which performs the render rather than the discovery.

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?

The division of labor is implied well: presets cover standard destinations, and encoding profiles exist 'for anything the presets do not cover,' giving the agent a selection rule between the two branches. It also tells the agent that encoders are listed only when they actually work on this machine. There is no explicit 'use this before calling fablecut_export' statement or named exclusion, so it falls short of a 5.

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