FableCut is a browser-based non-linear video editor that AI agents can fully control via an MCP server, enabling programmatic video editing through a structured JSON timeline.
fablecut_status: Ensures the FableCut web server is running (auto-starts if not), returning the editor URL, project summary, and media library overview. Recommended as the first call in any session.
fablecut_docs: Fetches project schema documentation covering clips, tracks, props, keyframe animation, transitions, and editing recipes. Supports filtering by section to save tokens.
fablecut_get_project: Retrieves the full project JSON or a compact one-line-per-clip summary of the current timeline.
fablecut_patch_project: Applies targeted, token-efficient edits (addClip, updateClip, removeClip, addMedia, removeMedia, setProject) without round-tripping the entire document. All-or-nothing: an invalid operation aborts the whole patch.
fablecut_set_project: Replaces the entire project JSON atomically. Conflict-safe — errors if the project changed on disk since the last read, preventing silent overwrites of user edits.
fablecut_analyze_reference: Analyzes a reference video to extract an edit blueprint including shot boundaries, music beats/BPM, loudness curve, drop point, per-shot audio energy, and an extracted music track — enabling agents to remake a similar edit with different footage.
fablecut_import_media: Copies a local video, audio, or image file into the media library and registers it in the project, returning its ID for use in clips.
Provides fast video export and reference video analysis, including shot detection and beat extraction.
Allows loading any Google Font by name for use in text clips, with automatic fetching.
Enables AI-powered background removal (person cut-out) directly in the browser for video clips.
A browser video editor that AI agents can drive.
English · 简体中文 · 日本語 · Español · Português (BR)
https://github.com/user-attachments/assets/2430b854-168b-4a9a-af2e-489e5efa7543
FableCut is a Premiere-style non-linear video editor that runs entirely in your browser — and exposes its whole timeline as one JSON document. Edit it by hand, from the UI, or let an AI agent (Claude Code, Claude Desktop, or anything that speaks MCP/REST) cut your video for you while you watch the timeline update live.
Zero npm dependencies. One node server.js. That's it.
Most "AI video" tools hide the edit behind an API. FableCut flips that: the
project file is the interface. project.json describes media, clips,
tracks, effects, keyframes and transitions — any process that can write JSON
can edit video, and the open browser UI hot-reloads within ~150 ms via
server-sent events. A human and an agent can work on the same timeline at the
same time.
Related MCP server: premiere-pro-mcp
Editing
3 video tracks + 4 audio tracks, drag/trim/split/snap, undo/redo
Settings (cog in the top bar) — optional prefs stored in this browser via
localStorage. Enable Link timeline and Project bin selection so picking a
timeline clip highlights its media in Project, and clicking a Project item
selects every timeline clip that uses it (off by default).
Direct manipulation on the monitor — click a clip or title on the preview to move, resize (corner handles), or rotate (top handle, Shift-snap) it directly
Timeline multi-select — rubber-band marquee (drag on empty track area), Ctrl/Cmd/Shift+click to add/remove clips, Ctrl+A to select all, Esc to deselect. Drag any selected clip to move the whole group; Delete removes all selected; S splits all selected at the playhead. Inspector shows an "N clips selected" banner.
Beat & cue markers (tap ⇧m on the beat during playback) with edge snapping
Press Alt+t to add an in/out transition based on the playhead position over the selected clip. The last used transition is remembered as the default. Drag the overlay triangle to adjust duration; Delete clears the focused transition.
Real decoded audio waveforms on clips
Project bin folders — tree view with expand/collapse; drag media or folders to nest; right-click the Project tab → New folder; drop files onto a folder to import into it
Audio Hold — timeline toolbar toggle: while paused, loops one frame of audio at the playhead (useful when stepping frame-by-frame). Scrubbing or frame-step retargets the held slice; meters stay live. Play / Pause turns it off.
Canvas aspect presets (16:9, 9:16 reels, 4:5, 1:1) + project FPS select (24 / 25 / 30 / 50 / 60; non-preset rates show as Custom) + safe-area guides
Export frame / reframing — composition canvas can be larger than the delivery
crop (exportFrame in project.json). Preview dims the overscan; drag the
Export frame handle to reframe (e.g. 16:9 canvas → 9:16 export). Fast export
crops to the frame; Realtime export is disabled while a frame is set
Program Monitor zoom — mouse-wheel over the preview zooms the composition toward the cursor (fit → up to 2 screen pixels per canvas pixel). Magnified view uses native scrollbars so overflow stays reachable; middle-click or Alt+drag pans. The Fit button (shown while zoomed) resets to the fit-to-stage baseline
Preview playback speed — shuttle the monitor through 1×/1.5×/2×/4× with J/K/L (from a stop J/L start playback; while playing L steps faster and J slower, K toggles play/pause and resets to 1×); affects the preview player only, never the export
Resizable workspace: drag the divider between monitor and timeline (double-click resets), plus S/M/L timeline track-density presets (S hides thumbnails for compact tracks)
Zoom to selection (⇧Z) frames all selected clips, not just one
IN/OUT work area — set markers with i and o (⇧I / ⇧O to clear). Enabling Limit constrains playback to the marked range and maps Home / End to the IN and OUT positions rather than the full timeline. t splits clips at the markers; ⇧t trims clips to the work (between marker in and marker out) area.
Find & close gaps — a gap is a stretch where every enabled track is empty (black frames). g jumps the playhead to the next shared gap (wraps; respects IN/OUT when both are set). ⇧G closes the gap under the playhead by pulling later clips left on all enabled tracks.
Reset a property — Ctrl/Cmd+click an inspector label to restore that effect/prop to its default (paired fields like Crop L/R reset together). Matching keyframes for the prop are cleared too; transition labels clear the in/out transition.
Replace media — the inspector's Source button (any video/audio/image/svg clip) swaps the underlying file while keeping position, trim, keyframes, transitions and every effect. Pick another item already in the bin or Browse file… to import and replace in one step. A video's linked L/R audio companions are swapped along with it; a shorter replacement clamps the trim to fit and toasts that it did so.
Multi-channel video audio — a video with more than 2 audio channels gets a linked audio clip per channel, not just L/R (5.1, 7.1…). Extra audio tracks (A5, A6, …, capped at 16) are created automatically as needed; replacing a clip's media re-syncs the linked channel clips to the new source's channel count, adding/dropping extras and new tracks as needed.
Look
14 one-click filter presets (cinematic, teal-orange, noir, vintage, cyberpunk, sunset, midnight…)
Adjustment layers — one clip grades everything below it, Premiere-style
Full grade controls: brightness/contrast/saturation/hue, temperature & tint, blur, grayscale/sepia/invert, vignette, animated film grain
Blend modes (screen, multiply, overlay…), fit modes (contain/cover/stretch), per-edge cropping, corner radius, flip H/V
Chroma key (green screen) with tolerance/softness + spill suppression
AI background removal (person cut-out, in-browser via MediaPipe)
Motion
Keyframe animation on ~25 properties with easing
Keyframe markers on clips — diamonds on the clip body at each unique keyframe time (tooltip lists channels; a count badge when several share a time). Ctrl/Cmd+← / Ctrl/Cmd+→ jumps the playhead to the previous / next keyframe (selected clips first, else clips under the playhead)
Keyframe graphs — toggle a property’s curve in the inspector to show an interpolated value graph beside the program monitor; click the graph to seek
Speed ramps — keyframe speed and the engine time-remaps video and the
export audio mix (the fast-into-slow-mo reel move)
Camera shake and RGB-split/chromatic aberration, both animatable
17 transitions: fades, slides, wipes (4 directions), zoom, iris, spin, blur, whip-pan, glitch, pop
Text
Title styles — one-tap cohesive looks (Impact, Elegant, Kinetic cut, Neon, Handwritten, Luxury, and more); new titles vary the font, placement and animation automatically instead of defaulting to one flat style
Kinetic captions: typewriter, word-pop, word-slide, karaoke, letter-pop, wave, bounce, shake, clip-reveal, zoom-in, font-cut (rhythmic typeface cuts), rise-mask
Neon glow for that TikTok caption look
Font editor: system fonts, drop-in custom fonts (library/fonts/), and any
Google Font by name — loaded automatically
Gradient fills, outline, background pills, letter-spacing, line-height, weights, italic, uppercase, soft shadows
Text layout — horizontal Align: left / center / right / justify
(extra spaces between words). Drag a title’s corner handles to create a
text box (boxW / boxH); further corner drags resize it (opposite
corner stays fixed; Ctrl/Cmd resizes from center; Shift
locks aspect). Inside a box, text wraps at the fixed font size by default;
enable Scale to fit to shrink the font so the whole block fits. V-align
(top / middle / bottom) places the text block vertically in the box. Set Box
W/H to 0 to return to hug-content sizing.
Animated SVG clips
A first-class svg clip kind: CSS-@keyframes-animated SVGs render
frame-accurately in preview and export (the compositor freezes the
animation at any time). Agents can author their own vector overlays —
lower-thirds, confetti, sparkles — as plain .svg files. Starters included.
Remake a reference video
Give it a reference edit (a reel you like) and get back an edit blueprint:
shot boundaries, music beats + BPM, a loudness curve, per-shot energy, the
drop — plus the reference's music track extracted into your media, ready
to rebuild the same idea with your own footage. Zero extra dependencies
(ffmpeg does the decoding; onset/tempo detection is plain Node).
node analyze.js ref.mp4, POST /api/analyze, or the
fablecut_analyze_reference MCP tool.
Asset library
library/ folders surface as tabs in the UI: Elements (overlay art),
Sound FX, SVG — drop files in, the open editor refreshes live
Export
Fast export: browser renders every frame + an offline audio mix; ffmpeg
encodes them via an encoding profile from encoding-profiles.json
(keeps rendering if you switch tabs). The Export dialog has a profile
selector; pin a project default with encodeProfile in project.json
Realtime MediaRecorder fallback when ffmpeg isn't available
git clone https://github.com/ronak-create/FableCut.git
cd FableCut
node server.js # → http://localhost:7777Requirements: Node 18+ and a Chromium-based browser. ffmpeg on PATH is optional but recommended (fast export + upload remuxing). AI background removal fetches its model from a CDN on first use.
The server binds 127.0.0.1 only (v1.3.1+). To use it from another device on
your LAN, opt in explicitly: HOST=0.0.0.0 FABLECUT_ALLOWED_HOSTS=<your-ip> node server.js.
Drop media into the window (or ./media/), drag clips onto the timeline, edit,
export.
To keep your work outside the checkout, set FABLECUT_DATA_DIR — it moves
project.json, media/, exports/, analysis/ and library/ to a directory
you choose. Leave it unset and everything stays in the repo, exactly as before.
/plugin marketplace add ronak-create/FableCut
/plugin install fablecut@fablecutThat registers the MCP server for you and adds two skills — edit-video and
remake-reel. Your timeline and footage live in the plugin's own data
directory, so an update never touches them. Node 18+ and (optionally) ffmpeg
still need to be on your machine.
Everything an agent needs is in CLAUDE.md — the complete schema, semantics and recipes. Point any capable model at that file and it can operate the editor end to end.
📖 Browsable docs: for a conversational, auto-generated tour of the codebase — architecture, the
project.jsonschema, the MCP surface — see FableCut on DeepWiki. Ask it questions about the repo in natural language.
Three equivalent control surfaces:
MCP (best for Claude Code / Claude Desktop) — register the bundled zero-dependency MCP server once:
claude mcp add -s user fablecut -- node "<path-to>/fablecut/mcp-server.js"OpenCode can use the same stdio server from its project or global
opencode.json configuration:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"fablecut": {
"type": "local",
"command": ["node", "/absolute/path/to/FableCut/mcp-server.js"],
"enabled": true
}
}
}For another MCP client, register a local stdio server with this equivalent command. The exact key names vary by client, but the command and arguments do not:
{
"name": "fablecut",
"transport": "stdio",
"command": "node",
"args": ["/absolute/path/to/FableCut/mcp-server.js"]
}The server is intentionally client-neutral. It speaks MCP over stdio and does not require Claude-specific environment variables. Keep the path absolute, and use Node 18 or newer.
Tools: fablecut_status (auto-starts the editor), fablecut_docs,
fablecut_get_project, fablecut_set_project, fablecut_patch_project,
fablecut_import_media, fablecut_analyze_reference,
fablecut_encode_profiles.
FableCut is also published on the official MCP registry as
io.github.ronak-create/fablecut
— each release ships an MCPB bundle (fablecut.mcpb) that MCPB-capable
clients can install directly.
The surface is token-efficient by design: agents patch the timeline with
small ops (fablecut_patch_project) instead of round-tripping the whole
document, read a compact one-line-per-clip summary
(fablecut_get_project {compact:true}), and fetch only the manual sections
they need (fablecut_docs {section:"props"}).
The file — read project.json, modify, bump revision, write. The UI
live-reloads.
REST — GET/PUT /api/project, POST /api/upload, GET /api/library,
GET /api/export/profiles, SSE at /api/events. See CLAUDE.md for the full list.
Example: ask Claude Code "cut these six clips to the beat markers, add a teal-orange grade, put a word-pop caption on top and a whoosh on every cut" — and watch the timeline rebuild itself.
Or hand it a reference: "here's a reel I like — analyze it and remake it with
my clips, same music". The agent calls fablecut_analyze_reference, gets the
blueprint (cuts, beats, BPM, energy, drop, extracted music), and rebuilds the
structure shot-for-shot with your footage.
Conflict-safe concurrent editing: the UI, the MCP tools, and direct
project.json writes all agree on a revision counter. If you edit a clip in
the UI while an agent is mid-task, the agent's next write is rejected (409 from
the REST API / a conflict error from fablecut_set_project) instead of
silently overwriting your change. The UI similarly detects when an agent write
supersedes a not-yet-saved local tweak and tells you with a toast instead of
dropping it silently.
server.js zero-dependency HTTP server: static hosting, REST API, SSE,
ffmpeg export pipeline
app.js the editor: timeline UI, compositor, keyframes, text engine,
SVG rasterizer, chroma key, exporters
index.html single-page UI
style.css dark editor theme
mcp-server.js stdio MCP server exposing the editor to AI agents
analyze.js reference-video analyzer: shots, beats/BPM, energy, drop,
music extraction (module + CLI)
CLAUDE.md the agent manual (schema + recipes) — also served by fablecut_docs
encoding-profiles.json
Fast-export ffmpeg presets (hot-reloaded)
project.json your timeline (created on first run; gitignored)
media/ project footage (gitignored)
analysis/ cached edit blueprints from /api/analyze (gitignored)
library/ default assets: elements/ sfx/ svg/ fonts/
exports/ finished renders (gitignored)SVGs animate with plain CSS @keyframes. One convention: never hardcode
animation-delay — set --d: 0.4s instead, and the compositor drives time by
pausing all animations and rebasing their delays. Full rules + a skeleton in
CLAUDE.md; working
examples in library/svg/.
The repo ships with 20 Google Fonts (library/fonts/, OFL — see
LICENSES.md there) and a set of self-authored SVG overlays and animated
elements (library/elements/, library/svg/, MIT like the rest of the repo).
library/sfx/ is yours to fill (gitignored): sound-effect sites typically
don't allow redistributing their files in a public repo, so FableCut doesn't —
library/sfx/README.md lists good free sources.
Export runs in the browser because the compositor is the browser; agents
ask you to click Export (or render directly with ffmpeg from media/).
Questions, ideas, showing off an edit, or want to help shape what's next? Join the FableCut Discord. Bugs and feature requests are still best filed as GitHub issues.
Analyze a reference video into an EDIT BLUEPRINT so a similar edit can be rebuilt with different footage over the same music. Returns: shot boundaries (cuts) with per-shot audio energy, music beats + BPM, a loudness curve, the detected drop, and extracts the reference's music track into media/ (registered in the project, ready to place on A1). Remake recipe: copy the reference's width/height/fps to the project, write beats into project markers, lay the extracted music on A1, then place one clip per blueprint shot at the same start/duration — pick calm footage for low-energy shots and action for high-energy ones, and make the biggest moment land on drop. See the 'Remake a reference video' section of fablecut_docs.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The reference video: an absolute file path (copied into media/ automatically) or an existing '/media/…' src | |
| threshold | No | Scene-cut sensitivity 0–1 (default: adaptive 0.30→0.20→0.12). Lower it if obvious cuts are missed, raise it if too many false cuts. | |
| registerMusic | No | Extract the reference's music and register it as project media (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It explains that the path is copied into media automatically, threshold has adaptive defaults, and registerMusic extracts and registers the music track on A1. No contradictions or hidden side effects are apparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured: purpose first, then outputs, then recipe, then cross-reference. Each sentence adds value, but minor redundancy (e.g., 'Remake recipe' repeats some info). Still efficient for the amount of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the return values (shot boundaries, per-shot audio energy, beats, BPM, loudness curve, drop, extracted music) and provides a complete recipe for using the blueprint. It also references documentation for further details. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value: for 'path' it clarifies absolute vs. media/ src; for 'threshold' it explains adaptive default values (0.30→0.20→0.12) and tuning guidance; for 'registerMusic' it describes extraction and registration. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a reference video into an EDIT BLUEPRINT for rebuilding with different footage over same music. It lists specific outputs (shot boundaries, per-shot audio energy, beats, BPM, loudness curve, drop, extracted music) and distinguishes from siblings via cross-reference to documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (analyze reference for remake) and provides a step-by-step remake recipe. It does not explicitly state when not to use, but the context and sibling tool names imply its specific role. Cross-reference to docs enhances guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the FableCut project schema documentation: clips, tracks, props, keyframe animation, transitions, and editing recipes. Read this before editing. TOKEN TIP: pass section to fetch only the '## …' section(s) you need (substring match, e.g. "props", "Recipes", "Remake") instead of the whole manual.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Return only '## ' sections whose heading contains this text (case-insensitive). Omit for the full document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only retrieval operation ('Return the documentation'), but does not explicitly state it has no side effects. Since no annotations are provided, the description carries the full burden; it successfully conveys the non-destructive nature through context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus a token tip. Front-loaded with purpose, no superfluous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple documentation retrieval tool with one optional parameter, the description covers purpose, usage, and filtering. It could mention what happens if a section is not found, but given the lack of output schema and low complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema: explains the substring match behavior, provides concrete examples (props, Recipes, Remake), and offers a token-saving tip. This fully compensates for the schema's brief parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return the FableCut project schema documentation'. It lists specific content areas (clips, tracks, props, etc.) and distinguishes itself from sibling tools which handle project data manipulation or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Read this before editing', indicating when to use this tool (before making edits). The token tip provides optimization guidance. While alternatives are not named, the context signals show siblings operate on projects, not documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the FableCut project (the timeline document). TOKEN TIP: pass compact:true for a one-line-per-clip summary (ids, tracks, timings, non-default props) — usually all you need to plan an edit; fetch the full JSON only when you must inspect exact keyframes.
| Name | Required | Description | Default |
|---|---|---|---|
| compact | No | Return a compact human-readable summary instead of the full JSON |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It describes the output format options but does not mention error conditions, permissions, side effects, or whether the operation is idempotent (implied read-only). The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose, and the second sentence efficiently delivers a valuable tip. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one optional parameter and no output schema or annotations, the description covers the main scenario (obtaining the project with optional compact format). However, it omits details like error handling, what the full JSON looks like, or behavior when the project is missing. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the parameter compact with a basic description. The description adds meaningful context: 'one-line-per-clip summary (ids, tracks, timings, non-default props)' and advises when to use each mode, going beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'FableCut project (the timeline document)', distinguishing it from sibling tools that patch or set projects. The compact option is also mentioned, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The token tip provides explicit guidance on when to use compact:true versus full JSON, which helps the agent decide the parameter value. However, it does not compare against sibling tools like fablecut_status or fablecut_analyze_reference, so usage boundaries are not fully delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy a local media file (video/audio/image) into FableCut's media library and register it in the project. Returns the created media entry (use its id in clips).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the source file on disk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses it copies and registers the file, and returns a media entry. However, it omits details like file existence checks, type validation, error handling, side effects on project state, and whether the file is copied or moved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines action and scope, second explains return value. No wasted words, efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter. Description covers purpose and return value adequately. Missing details on error cases, duplicate handling, or permissions, but acceptable for a basic import. No output schema, so return information is useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage describing 'path' as absolute path. Description adds 'local media file' reinforcing that the source is local. Baseline 3 is appropriate since schema already documents the parameter well and description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it copies a local media file into FableCut's media library and registers it in the project, specifying media types (video/audio/image). This clearly distinguishes it from sibling tools which handle docs, project settings, analysis, and status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when importing media into the project, but no explicit guidance on when not to use or prerequisites (e.g., file must exist and be accessible). Siblings are not media-related, so no direct alternative, but context could be clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply targeted edits to the FableCut project WITHOUT round-tripping the whole document — PREFER THIS over get+set for every edit (it is ~10-100x cheaper in tokens and merge-safe by design: it re-reads the latest document from disk, applies your ops in order, bumps revision once, saves atomically). Ops: {op:'addClip', clip:{…}} (id auto-generated if omitted) · {op:'updateClip', id, set:{…}} · {op:'removeClip', id} · {op:'addMedia', media:{…}} · {op:'removeMedia', id} · {op:'setProject', set:{name|width|height|fps|background|markers|disabledTracks}}. updateClip merge rules: top-level keys are replaced (keyframes/transitionIn/transitionOut wholesale), props merges key-by-key, and setting any key to null deletes it. All-or-nothing: an invalid op aborts the whole patch unsaved.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | Edit operations, applied in order (see tool description for shapes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses merge-safe design, atomic save, all-or-nothing behavior, updateClip merge rules, and op details comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph densely packs all info, but is well-structured with op list. Could be slightly more segmented, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return value (e.g., success/error response), but covers behavior, parameters, and merge details thoroughly. Minor gap given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema parameter 'ops' defers to description, which provides exhaustive shapes for each op type and merge rules, adding immense value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it applies targeted edits to a FableCut project without round-tripping, distinguishing it from siblings like get+set. Uses specific verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends this tool over get+set due to cost and merge safety, but does not mention when to use alternatives (e.g., for complex edits needing full document).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the FableCut project JSON. Pass the COMPLETE document (read with fablecut_get_project, modify, send back whole). Revision is auto-bumped; the open editor UI hot-reloads instantly so the user sees the edit live. CONFLICT-SAFE: if the project changed on disk since your last fablecut_get_project (e.g. the user tweaked something in the UI), the call errors instead of overwriting — re-read, re-apply your edit on top of the latest document, and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Overwrite even if the project changed since it was last read (discards those external/user changes). Only when the user explicitly asks. | |
| project | Yes | The complete project document (see fablecut_docs for schema) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auto-bumped revision, instant hot-reload, conflict error and retry pattern, and force overwrite behavior. No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences covering all crucial aspects without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains behavior well but lacks description of return value. Given set operation, minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, description adds value by clarifying the 'project' must be complete and the read-modify-write cycle, and explains 'force' usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it replaces the project JSON with the complete document, distinguishing from patch tools. Verb 'replace' with resource 'project' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to read, modify, send whole. Provides conflict-safety retry guidance. Could mention that partial updates should use fablecut_patch_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FableCut video editor: ensure the editor web server is running (auto-starts it), and get the editor URL, project summary and media library. Call this first in a session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavior: auto-starting the web server. Does not detail error handling or idempotency, but for a status tool, this is adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that concisely conveys purpose, behavior, and usage recommendation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers core functionality and usage. Could mention response details more explicitly, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so baseline 4 applies. Description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as ensuring the editor web server is running (auto-start) and retrieving the editor URL, project summary, and media library. It distinguishes from siblings by stating 'Call this first in a session.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this first in a session,' providing clear usage guidance as a prerequisite. Lacks details on when not to use or alternatives, but the instruction is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0fablecut_analyze_referencefablecut_docsfablecut_get_projectfablecut_import_mediafablecut_patch_projectfablecut_set_projectfablecut_statusEach tool has a distinct purpose: docs, project retrieval, targeted patching, full replacement, reference analysis, media import, and status. There is no overlap or ambiguity between them.
All tools use the 'fablecut_' prefix and a verb_noun pattern for most (e.g., fablecut_get_project, fablecut_import_media). However, 'fablecut_docs' and 'fablecut_status' are noun-only, breaking the pattern slightly.
Seven tools is well-scoped for a video editor MCP: status, docs, import media, get/set/patch project, and analyze reference. Each tool serves a clear purpose without excess.
Covers core CRUD for clips and media, project settings, and advanced reference analysis. Minor gaps like explicit track management or export are absent, but the set supports common editing workflows.
A real timeline video editor for AI agents: journaled edits, FFmpeg/MLT rendering, exports
Edit video by talking to your AI — search footage, cut timelines, apply effects, add captions.
Agentic video editing on real footage: cut, caption, reframe, score, and export at full quality.
FFmpeg as a service for AI agents: typed video editing tools, async jobs, downloadable outputs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ronak-create/FableCut'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
