Model Context Protocol server for Socheli — let any agent run your content engine. Provides tools to control the agentic content engine for faceless video generation.
Four tools with complete input schemas and detailed descriptions. Naming follows verb_noun pattern (edit_*). Descriptions are substantive (150-250 chars), explaining WHAT the tool does, WHEN to use it, and that it PROPOSES rather than applies changes. All parameters have types and descriptions. However, output schemas are not documented, LLMs cannot see what fields to expect from responses. No error handling guidance. No tool annotations (readOnlyHint, destructiveHint). Risk classification is present but not integrated into descriptions.
PROPOSE cutting the dead air / silent gaps out of an ingested video, frame-exact. Reads the understanding (dead-air spans) and the frame timeline, maps each silent span to the clip + frames covering it, and returns a grounded TRIM proposal. Does NOT apply — render the proposal for approval, then on confirmation apply the trims via timeline_trim_clip_frame (or route a remove-clip plan via creative_apply_plan). Use for 'cut the dead air / tighten the silences / remove the gaps'.
PROPOSE razor cuts placed ON THE MUSIC — on each beat, or on the drop. Reads timeline_music_context over a frame range, picks the beat/drop frames, maps each to the clip playing there, and returns a SPLIT proposal (frame-exact razor cuts). Does NOT apply — render it for approval, then on confirmation apply via timeline_split_clip_frame at each frame. Use for 'cut on the beat / split on every beat / cut on the drop'.
PROPOSE a short highlight reel from an ingested video's KEY MOMENTS. Reads the understanding (highlights / dense-vision strongest frames) and the frame timeline, ranks the moments, and returns a KEEP proposal (the spans to keep, in frames) targeting an approximate length. Does NOT apply — render it for approval, then on confirmation build the reel via creative_montage (style 'highlight_reel') or a keep/remove plan via creative_apply_plan. Use for 'make a 30s reel / supercut the best bits / teaser of the highlights'.
PROPOSE a punch-in (zoom) on the moment a WORD is spoken. Reads timeline_words_at_frame to find the word's frame(s), resolves the clip there, and returns a ZOOM proposal (the clip + the frame window to punch in on). Does NOT apply — render it for approval, then on confirmation apply via the clip zoom / creative_punch_ins path (creative_apply_plan). Use for 'zoom on <word> / punch in when they say <word> / emphasize <word>'.
Output schemas not documented. LLMs cannot see what fields responses contain (e.g., does edit_cut_dead_air return frame ranges, clip IDs, duration estimates?). Forces agents to guess structure and risks parsing failures.
No tool annotations. All four tools are read-only (Risk: READ_ONLY noted in metadata), but this is not exposed via readOnlyHint in the tool definition. Agents cannot distinguish safe tools from destructive ones without reading descriptions.
No error handling guidance. Descriptions do not explain what happens if the ingested run is not found, if the word is not spoken, or if the frame range is invalid. Agents have no recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Parameter constraints not fully specified. 'minGapSec' and 'targetSec' lack min/max bounds. 'maxClips' and 'maxCuts' are unbounded. LLMs may pass absurd values (e.g., maxCuts=10000) that break performance.
Composition risk: all four tools are proposal-only and require downstream tools (timeline_trim_clip_frame, creative_montage, creative_apply_plan, creative_punch_ins) to apply changes. No tool in this server actually executes edits. Agents must chain to external tools, risking context loss and broken references.