Skip to main content

Architecture

vv-mcp exposes Venturi to AI agents over the Model Context Protocol. The protocol side (rmcp on a tokio runtime) never touches the project: it turns each request into a ToolCall and submits it through a McpHandle. Whoever owns the Session drains the matching McpInbox and runs the call. The headless server and the editor window share the same dispatch and tool code.

Call path

mcp-call-path.png

Modules

ModuleRole
serverVenturiServer: rmcp tool router; one async method per tool that builds a ToolCall and awaits the reply
toolsThe ToolCall enum, argument structs (JSON Schema via schemars), mutates()
hostMcpHandle / McpInbox channel, PendingCalls, run_headless
dispatchRoutes a call on a &mut Session: handled now, or deferred
edit_toolsEditing tools, all built on vv_core::edit
media_toolsFrame render, audio levels, export start/status/cancel
json, idsProject and state serialisation; string ids for clips, media and timelines
socketUnix-socket server for the editor and the --attach bridge

Dispatch outcomes

OutcomeToolsAnswered when
HandledAll the othersImmediately, on the session owner's thread
Deferred: Import / Otioimport_media, import_otioThe matching SessionEvent comes out of tick()
Deferred: Workerrender_frame, get_audio_levelsTheir own thread, working on a project snapshot, finishes

Design points

  • One edit path. Tools edit through vv_core::edit on session.project and session.history, exactly like the UI, so each editing call is one undo step (create_timeline excepted) and undo/redo share the user's history.
  • Owner-driven. Because only the session owner runs calls, a slow tool never races an edit. Long work (decode, export, import) runs on threads and is answered later.
  • Shutdown. McpInbox keeps only a weak sender, so it disconnects once the last McpHandle (the transport) is gone and the host loop ends.

No comments to display

Back to top