goatedit-mcp 1.1.11 → 1.1.12

package/bundle/goatedit-mcp.js

@@ -21575,7 +21575,7 @@ var BASE_TOOLS = [
   },
   {
     name: "studio_tasks",
-    description: 'The work GoatEdit Studio has for you in this project. Studio makes a video in stages (brief, research, script, breakdown (the script cut into parts), moodboard, styleGuide (the design language every part follows), storyboard, edit plan, combine (the parts joined into the final edit plan), timeline, mix, QC, export, plus any the user added, whose ids start "x-" and whose document is {"notes": string, "points"?: string[]}); a stage opens once the stages it reads are approved, so several are often open at once. Each task is kind "write" (write that stage\'s JSON document: follow `role` as your system prompt, read `inputs`, follow `lessons` when present (what this user has asked for before), and if `previousDraft` is there, revise it using `note` and `problems`) or kind "run" (ask the tab to do it with studio_run_stage). Open tasks in one run do not depend on each other: hand each to its own subagent and do them side by side. When a task names an `agent`, the user wants that subagent or skill of yours on it: hand the task to the subagent with that name, or use the skill with that name. In a batch of reels each run has `batch` (reel number, name, avatar); stages listed in batch.filled are filled by Studio itself (the locked script, the pilot\'s look), so leave them. For each write task: studio_claim it first (the person sees your agent working on that stage), then studio_submit the document. The reply to a submit names the stages it opened; call studio_tasks again for them. Stages waiting for the person are listed under waitingForPerson \u2014 stop there and tell the user to approve them in the Studio panel.',
+    description: 'The work GoatEdit Studio has for you in this project. Studio makes a video in stages (brief, research, script, breakdown (the script cut into parts), moodboard, styleGuide (the design language every part follows), storyboard, edit plan, combine (the parts joined into the final edit plan), timeline, mix, QC, export, plus any the user added, whose ids start "x-" and whose document is {"notes": string, "points"?: string[]}); a stage opens once the stages it reads are approved, so several are often open at once. Each task is kind "write" (write that stage\'s JSON document: follow `role` as your system prompt, read `inputs`, follow `lessons` when present (what this user has asked for before), and if `previousDraft` is there, revise it using `note` and `problems`) or kind "run" (ask the tab to do it with studio_run_stage). Open tasks in one run do not depend on each other: hand each to its own subagent and do them side by side. When a task names an `agent`, the user wants that subagent or skill of yours on it: hand the task to the subagent with that name, or use the skill with that name. In a batch of reels each run has `batch` (reel number, name, avatar); stages listed in batch.filled are filled by Studio itself (the locked script, the pilot\'s look), so leave them. For each write task: studio_claim it first (the person sees your agent working on that stage), then studio_submit the document. The reply to a submit names the stages it opened; call studio_tasks again for them. Stages waiting for the person are listed under waitingForPerson \u2014 stop there and tell the user to approve them in the Studio panel, unless the user told you to approve them yourself (then studio_approve).',
     inputSchema: {
       type: "object",
       properties: {
@@ -21608,12 +21608,61 @@ var BASE_TOOLS = [
         runId: str("The run, from studio_tasks."),
         stage: str("The stage id."),
         document: { type: "object", description: "The stage's document, in the shape its role card gives." },
-        agent: str("Who wrote it, as in studio_claim.")
+        agent: str("Who wrote it, as in studio_claim."),
+        part: str("For a stage written part by part (the task lists `parts`): the part id. The document then holds only that part's beats (storyboard) or scenes (edit plan), and the part is checked and shown in the Studio gallery on its own.")
       },
       required: ["runId", "stage", "document"]
     },
     method: "studioSubmit"
   },
+  {
+    name: "studio_approve",
+    description: "Approve a Studio stage that is waiting for the person (waitingForPerson in studio_tasks), on their behalf. Only when the user told you to approve it, or to run Studio on their own without stopping: otherwise tell them it is waiting for them in the Studio panel. personSaid keeps what they told you in the run's log, so the panel shows who approved it and why. A stage with rival drafts needs pick; a stage written part by part approves every part waiting. The reply names the stages that opened.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        runId: str("The run, from studio_tasks."),
+        stage: str("The stage id."),
+        agent: str('Who is approving, shown in the log ("Claude Code").'),
+        personSaid: str(`The user's words that let you approve it, e.g. "do everything by yourself".`),
+        pick: num("With rival drafts: which one, 0-based.")
+      },
+      required: ["runId", "stage"]
+    },
+    method: "studioApprove"
+  },
+  {
+    name: "studio_send_back",
+    description: "Send a Studio stage in review back to whoever writes it, with what to change; it opens again with the note. Use it when a draft you are reviewing for the user is not good enough.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        runId: str("The run, from studio_tasks."),
+        stage: str("The stage id."),
+        note: str("What to change.")
+      },
+      required: ["runId", "stage", "note"]
+    },
+    method: "studioSendBack"
+  },
+  {
+    name: "studio_update_run",
+    description: `Change a Studio run under way, for the stages still to come (approved, left-out or running stages keep theirs): who writes each stage and who approves it (the same settings as studio_save_workflow; brief, moodboard, styleGuide and export stay approved by the person), and editSequenceId: a sequence the person already edited, for the timeline and qc stages to restyle in place instead of building a new one. With editSequenceId set, timeline and qc can take writer "outside": you edit that sequence over MCP and studio_submit the stage's document. null for editSequenceId goes back to a new sequence.`,
+    inputSchema: {
+      type: "object",
+      properties: {
+        runId: str("The run, from studio_tasks."),
+        stages: {
+          type: "object",
+          description: 'Stage id to { writer?, approver?: "person" | "auto", agent?, instructions?, tier?, review?, enabled? }.',
+          additionalProperties: { type: "object" }
+        },
+        editSequenceId: { type: ["string", "null"], description: "A sequence id from list_sequences, or null." }
+      },
+      required: ["runId"]
+    },
+    method: "studioUpdateRun"
+  },
   {
     name: "studio_run_stage",
     description: `Start a Studio stage the tab does itself: "timeline" (build the edit from the approved plan) or "qc" (check it), or a stage the workflow gives to Studio's agent in the tab. Returns at once; the work goes on in the tab and the panel shows it. Poll studio_tasks to see it finish.`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "goatedit-mcp",
-  "version": "1.1.11",
+  "version": "1.1.12",
   "description": "Local MCP server for the GoatEdit video editor: drive your open editor tab from Claude Code or any MCP client",
   "license": "UNLICENSED",
   "type": "module",