cutlass-mcp: headless MCP server for external agents

[1mrnewton]

What

New crate crates/cutlass-mcp: a headless MCP server (official rmcp 2.2 SDK, stdio transport) so external agents (Cursor, Claude Code, …) can script Cutlass — the roadmap Phase 5b MCP server item.

Trust model

Every mutation flows through the same gate as the in-app agent: WireCommand → cutlass_ai::validate → Engine::apply. Never a raw engine door. Edit batches are one undo group, all-or-nothing with rollback. The engine (not Send) lives on a dedicated OS thread; async tool handlers round-trip over a channel — same pattern as the desktop preview worker.

Tools (13)

• Project: project_new / project_open / project_save / project_get (the in-app agent's compact summary), media_import
• Edits: edit_commands_list + edit_schema_get serve the closed 51-command wire vocabulary (schema v43) as lookups; edit_apply takes {"command": …} batches and returns editor-language action lines + created ids for chaining; edit_undo / edit_redo step per batch
• Render: frame_get (composited PNG as MCP image content, for agent visual verification), export_video (H.264/AAC via platform encoders)
• Probe: version

Testing

19 tests: 16 unit (engine host: lifecycle, fps mapping, batch rollback semantics, frame grabs incl. red-pixel compositor assert, range guards) + 3 integration (tests/mcp_client.rs drives a real rmcp client in-process over a duplex pipe: tool catalog, readOnlyHint annotations, image content blocks, isError conventions). Manually verified end-to-end from Cursor's MCP integration: import → batch edits → frame grab → save → export.

A full whole-crate review pass was done before this PR; findings fixed in the last commit (engine-thread panic recovery, ±2^53 time range guard, frame_get size ceiling 2048, empty-batch rejection).

Limits (documented in the crate README)

Headless (no desktop-session attach), stdio only, synchronous export, one project per server process. Streamable HTTP and desktop attach are follow-ups.

Made with Cursor