fix(mcp): do not set event end actions unless explicitly requested

End actions (load-next, play-next) create playback automations that remove
operator control between events and can surprise users. The agenda-building
prompt previously encouraged play-next for back-to-back segments, causing the
agent to add end actions proactively.

Update the endAction field description and the create_rundown_from_agenda
prompt so end actions are only applied when the user explicitly asks for
automatic cueing or chaining; a seamless schedule no longer implies automation.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011u3XRF6QwHZNB5o69xJ7UB

apps/server/src/api-mcp/mcp.prompts.ts

@@ -90,9 +90,11 @@ Count to end (countToEnd):
 - Do not set \`countToEnd: true\` unless the user explicitly asks for "count to end", "count to scheduled end", or confirms after you explain this behaviour.
 
 End action (endAction):
-- \`none\` (default): stops at end; operator must manually start the next event.
-- \`load-next\`: pre-arms the next event; operator triggers start. Use when a human handoff is needed.
-- \`play-next\`: automatically starts the next event. Use for seamless back-to-back segments with no gap.
+- Leave \`endAction\` unset unless the user explicitly asks for automatic cueing or chaining. It defaults to \`none\`.
+- \`load-next\` and \`play-next\` create playback automations that remove operator control between events and can surprise operators. Do NOT add them just because events are scheduled back-to-back — a seamless schedule does not imply automated playback.
+- \`none\` (default): stops at end; operator manually starts the next event. Use this for essentially every event unless told otherwise.
+- \`load-next\`: pre-arms the next event; operator triggers start. Only set when the user explicitly asks for it.
+- \`play-next\`: automatically starts the next event. Only set when the user explicitly asks for an automatic playback chain; confirm they understand it removes operator control between those events.
 
 Linking (linkStart):
 - \`linkStart\` controls schedule-change propagation through the rundown.

apps/server/src/api-mcp/mcp.schema.ts

@@ -21,7 +21,8 @@ export const EVENT_TIMER_FIELDS = {
   endAction: {
     type: 'string',
     enum: ['none', 'load-next', 'play-next'],
-    description: 'Action when event ends: none = stop, load-next = cue next event, play-next = auto-start next event',
+    description:
+      'Action when the event ends. Defaults to none. load-next and play-next create playback automations (load-next arms the next event, play-next auto-starts it) that remove operator control between events and can surprise operators. Only set load-next or play-next when the user explicitly asks for automatic cueing or chaining; otherwise omit this field and leave it as none. Do not add end actions just because events are back-to-back.',
   },
   linkStart: {
     type: 'boolean',
@@ -116,7 +117,7 @@ There are four entry types discriminated by \`type\`:
   dayOffset: number          // runtime calculated day offset from the rundown start schedule, increments when the rundown crosses midnight
   gap: number                // schedule gap between sequential playable events; negative gap means overlap
   timerType: 'count-down' | 'count-up' | 'clock' | 'none'
-  endAction: 'none' | 'load-next' | 'play-next'
+  endAction: 'none' | 'load-next' | 'play-next'   // load-next/play-next create playback automations; leave as none unless the user explicitly asks for cueing/chaining
   linkStart: boolean         // chain start to previous event's end
   countToEnd: boolean        // advanced mode: counts to scheduled timeEnd instead of duration; confirm before enabling
   skip: boolean              // event is skipped during playback