MCP versus CLI
Slideshot ships three ways to integrate: the MCP server, the slideshot CLI, and the raw HTTP API. The MCP server and CLI both call the same API underneath, so the choice is about how the request gets made rather than what the API can do.
Short version
- Use MCP when an AI agent is collaborating with a human and should drive recording from natural-language conversation.
- Use the CLI when recording should run unattended: in a CI job, a release script, or a scheduled product marketing workflow.
- Use the HTTP API directly when neither path fits, for example from a server-side integration or a custom backend.
When MCP makes sense
The MCP server exposes Slideshot as a set of tools the agent can call directly. The agent reads the tool list, plans the recording, asks the user for missing pieces (credentials, the target URL, the goal), and reacts to runs that pause for OTP input.
This is the lowest-friction path inside Claude Code, Codex, Cursor, ChatGPT (with skill loaded), and any other MCP-capable agent.
- The agent describes the run options it picked instead of you composing JSON by hand.
- The agent can keep context across setup, run creation, awaiting-input, and artifact download.
- The agent can mix Slideshot calls with the rest of the conversation: for example, generate a launch tweet from the demo video URL.
- Recording requests start as natural-language goals.
When the CLI makes sense
The CLI is a Node-based command-line client published as slideshot on npm. It is the right path for deterministic, scriptable runs:
- CI jobs that record a demo after a release tag.
- Release runbooks that produce changelog walkthroughs.
- Scheduled product marketing workflows that turn a script into a video.
- Local terminal workflows where you want a stable command, exit codes, and JSON output for piping.
The CLI also makes sense for AI agents in development-focused environments, where the agent already has Node and npx available and you would rather shell out a single command than wire up MCP. For non-developer users, MCP is the friendlier path.
The CLI prints JSON by default for shell composition and supports --output text for human-readable runs. Run it with npx to always pick up the latest version:
export SLIDESHOT_API_KEY="sk_live_xxxx"
npx slideshot runs create https://app.example.com \
--goal "Open the analytics dashboard and create a new project" \
--options '{"artifacts":{"gif":true}}'
npx slideshot runs wait <RUN_ID>
npx slideshot runs download <RUN_ID> --artifact demo.mp4 --dir ./artifacts
When the HTTP API makes sense
Reach for the API directly when:
- You are wiring Slideshot into a server-side service or worker.
- The agent in question can make HTTP requests but does not support MCP and has no shell access.
- You want to embed Slideshot in your own product.
See API key and API overview for endpoint shapes.
Side-by-side
| Concern | MCP | CLI |
|---|---|---|
| Best for | Conversational, agent-driven workflows | Scripts, CI, scheduled jobs |
| Auth | OAuth-approved access token per agent | API key via SLIDESHOT_API_KEY |
| Input | Natural language + tool calls | Flags, JSON files, stdin |
| Output | Structured tool results in the conversation | JSON or text on stdout |
| Awaiting input | Agent reads the prompt and submits the value | npx slideshot runs input <id> --value <otp> |
| Skill compatible | Yes | Yes |
Which one should you choose
- Start with MCP if a human is collaborating with an AI agent to create a demo video.
- Start with the CLI if the recording should happen automatically after a release, docs update, or scheduled campaign.
- Use both together when the agent helps design the workflow interactively and the CLI runs the final repeatable automation.
- Drop down to the HTTP API when neither fits or you are building a server-side integration.