Convert articles/text/URLs into short videos using Claude CLI as orchestrator and Remotion for render.
news-tok MCP server has 7 tools with mixed quality. Tool naming follows verb_noun convention (createProject, listProjects, getStoryboard, updateStoryboard, generateThumbnail, regenerateThumbnail, previewSafeZones), good. Descriptions are present but vary widely in clarity and actionability. createProject description is 400+ chars and overly detailed with layout enumerations; others are concise but lack context on when/why to use them. Input schemas are visible for all tools with basic type definitions, but parameter descriptions are minimal (10-30 chars, well below the 72-char baseline). Output schemas are not documented, LLMs cannot predict return structure. Error handling is mentioned as present but not detailed in source. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (WRITE vs READ_ONLY). Composition is reasonable, tools chain logically (createProject → updateStoryboard → generateThumbnail), but missing pagination/limits on listProjects and no batch operations.
Create a new news-tok project folder under data/projects/<id>/ with an empty storyboard.json. Returns the projectId and the absolute path to the storyboard. Aspect supports 9:16 (1080x1920, default for TikTok/Reels/Shorts), 16:9 (1920x1080, for YouTube/landscape), and 1:1 (1080x1080, for Facebook/Instagram feed). At 1:1 a curated subset of layouts is supported — others auto-fall-back to FullBleed at render time. Supported 1:1 layouts: builtin-fullBleed, builtin-storyPill, builtin-storyChip, builtin-storyVtv, builtin-card, builtin-magazineCover, builtin-statHero, builtin-breakingNews, builtin-newstokvn-keypoint-flame, builtin-newstokvn-keypoint-highlight, builtin-newstokvn-keypoint-quote, builtin-newstokvn-keypoint-bulletin, builtin-newstokvn-keypoint-comparison, builtin-newstokvn-keypoint-international.
Full path: extract candidate frames, build edits inside the universal safe zone, persist Thumbnail to storyboard, renderStill to thumb.jpg.
Return the parsed storyboard.json for the given projectId.
Return a summary of all projects under data/projects/, sorted most recently updated first.
Render the current thumbnail with all 4 platform unsafe zones painted as translucent masks, so the user can verify offline.
Output schemas not documented. LLMs cannot predict return structure for any tool, forcing them to guess what fields are available for downstream chaining.
Parameter descriptions are minimal (10-30 chars vs 72-char baseline). E.g., 'Source type' and 'Source value' lack context on valid formats, constraints, or when to use each source type.
listProjects lacks pagination (limit, offset, page_size) and total count. Returning all projects unbounded risks context window exhaustion and violates paginated-result pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Keep existing edits, only re-extract frames + re-render. Used after a user re-renders the video.
Write a fully-formed project JSON to data/projects/<id>/storyboard.json. Each segment's `scene` field must be a lowercase kind — one of `title`, `keypoint`, `quote`, `outro` — OR the filename (without extension) of a custom scene under data/projects/<id>/scenes/. Do NOT use PascalCase React component names like `TitleCard` / `KeyPoint` / `Outro` — these are filenames, not scene values. The tool runs Studio-equivalent sanitisation (strip emoji from title + every segment.text, lowercase + remap known PascalCase scene typos, stretch each segment.durationSec to fit narration + 0.4s buffer) and validates against ProjectSchema before writing. Returns the persisted project plus lists of any duration adjustments and scene-name corrections applied.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. createProject, updateStoryboard, generateThumbnail, regenerateThumbnail are WRITE operations but not marked as destructive/idempotent.
createProject description is 400+ chars with exhaustive layout enumeration. Violates 10-1024 char guideline (too verbose). Should summarize layouts and reference docs instead.