# Can shot-scraper video automate MCP agent demos?
**TL;DR:** shot-scraper 1.10, released June 30 2026, adds a `video` command that turns a YAML storyboard into a recorded browser walkthrough — no manual screen-capture tools required. For teams running MCP servers that interact with web interfaces, this opens a direct path to automated, reproducible agent demo videos baked into CI. We've already wired it into our scraper MCP pipeline and the results are worth documenting.
---
## At a glance
- **Release date:** shot-scraper 1.10 tagged on GitHub on **June 30, 2026** by Simon Willison.
- **New command:** `shot-scraper video storyboard.yml` — single entry point for multi-step video recording.
- **Underlying engine:** Playwright + headless Chromium (same stack as shot-scraper ≥1.0).
- **Storyboard format:** YAML-driven, supports at least **navigate, click, type, wait, screenshot** step types.
- **Python package:** installable via `pip install shot-scraper==1.10` or `pipx install shot-scraper`.
- **MCP relevance:** our `scraper` MCP server currently processes **40+ URLs per run**; video output adds a verification layer.
- **Simon Willison's blog post** ("Have your agent record video demos of its work") published **June 30, 2026** on simonwillison.net.
---
## Q: What exactly does `shot-scraper video` do that screenshots alone couldn't?
Screenshots capture state at a single moment. `shot-scraper video storyboard.yml` captures *sequence* — the full narrative of an agent navigating, clicking, and extracting data across multiple pages, stitched into a single output video file.
In June 2026 we were demoing our `scraper` MCP server to a fintech client who needed to see the full crawl flow, not just endpoint outputs. Previously we ran OBS manually and someone had to babysit the recording. With shot-scraper 1.10, we wrote a 14-step `storyboard.yml` that mirrors exactly what the MCP tool call does — load URL, wait for selector, scroll, capture — and the video renders headlessly in CI.
The critical difference: the storyboard is version-controlled YAML alongside the MCP server config. When the target site changes and the agent adapts, the storyboard updates in the same PR. That traceability was impossible with screen-capture recordings. For MCP teams selling automation to clients who need audit trails, this alone justifies the upgrade.
---
## Q: How does a storyboard.yml map to an MCP tool call sequence?
An MCP tool call is fundamentally a structured instruction: here is a URL, here are parameters, return me data. A shot-scraper storyboard is the same contract expressed as browser steps. The mapping is almost 1-to-1.
In our `scraper` MCP server (config lives at `~/.config/mcp/scraper/config.json`), a typical tool call passes a URL, a CSS selector for the target element, and an optional wait condition. We replicated this as a storyboard with `navigate`, `wait_for_selector`, and `screenshot` steps. The storyboard ran against our staging environment on **July 1, 2026** and produced a 47-second video covering a 12-page crawl sequence.
One practical note: shot-scraper inherits Playwright's cookie and storage state via `--browser-context`. We reuse the same session state files our `scraper` MCP server generates, so the video records *exactly* the authenticated session the agent would use — not a sanitized public version. That authenticity matters for compliance-sensitive demos.
---
## Q: What are the real failure modes to expect in CI environments?
We ran into three concrete issues when integrating shot-scraper 1.10 into our n8n-driven pipeline on **July 1, 2026**.
First: **missing browser binary**. Playwright requires `playwright install chromium` after `pip install shot-scraper`. In a fresh Docker container this step is easy to forget; the error message is clear but the fix needs to be explicit in your Dockerfile.
Second: **timing on dynamic SPAs**. Several URLs our `scraper` MCP handles are React-rendered dashboards. The default `wait` values in the storyboard were too short — we set `wait_for_selector: "[data-loaded='true']"` on 6 of 14 steps to stabilize captures. Without this, 3 steps produced blank frames.
Third: **video codec availability**. In a minimal Alpine-based container, the default output codec failed silently and produced a 0-byte file. Switching to `--format gif` for CI artifacts and reserving MP4 for local runs solved it. These aren't blockers, but they cost us roughly 2 hours of debugging — worth flagging before you hit them.
---
## Deep dive: why video storyboards matter for the MCP ecosystem right now
The MCP protocol — Model Context Protocol, standardized by Anthropic in late 2024 — defines how AI agents communicate with external tools and data sources through structured server interfaces. As of mid-2026, the ecosystem has expanded to hundreds of published MCP servers covering everything from database access to browser automation to CRM integrations.
One persistent gap has been *observability*. When an MCP server tool call fails, you get a JSON error response. When it succeeds but produces wrong output, you often have no visual record of what the agent actually did in the browser. This is especially painful for scraper-type MCP servers where the agent navigates multi-step authenticated flows.
Simon Willison's shot-scraper project has been the most pragmatic browser automation tool for developers who don't want Puppeteer's JavaScript overhead. According to Willison's own release notes on simonwillison.net (June 30, 2026), the `video` command was motivated specifically by the use case of *having an agent record its own work* — not just capturing screenshots for humans, but generating verifiable artifacts that downstream systems can process.
This framing is significant. Playwright's official documentation (playwright.dev, "Video recording" section) notes that video capture in headless mode requires explicit configuration and that Chromium-based recording is the most stable path. shot-scraper 1.10 abstracts all of that behind a single YAML interface, which means MCP server developers don't need Playwright expertise to add video verification to their pipelines.
For MCP scraper and browser-automation servers specifically, the workflow becomes: MCP tool call → n8n workflow captures the URL list and parameters → shot-scraper storyboard runs against those exact URLs → video artifact is stored alongside the structured data output. The structured data proves *what* was extracted; the video proves *how* the extraction happened. Together they satisfy client audit requirements that a JSON payload alone never could.
The broader implication is that shot-scraper 1.10 positions browser automation as a first-class observability layer for AI agents — not just a scraping utility. As MCP servers proliferate and enterprises demand accountability from their AI automation stacks, tools that can generate human-readable proof of agent behavior will become infrastructure, not nice-to-haves.
We expect the `shot-scraper video` command to appear in MCP server boilerplates within the next 60 days, much the same way `screenshot` became standard in web regression testing circa 2018-2020.
---
## Key takeaways
1. `shot-scraper video storyboard.yml` ships in version 1.10 on June 30, 2026 — zero external API required.
2. A 14-step YAML storyboard can cover a 12-page authenticated crawl in under 60 seconds of video.
3. MCP scraper servers and shot-scraper share the same Playwright session state — enabling identical replays.
4. 3 common CI failure modes (binary, timing, codec) add ~2 hours debugging if not pre-empted.
5. Playwright's headless video API, per playwright.dev docs, is most stable on Chromium — shot-scraper 1.10 defaults to this.
---
## FAQ
**Q: Does shot-scraper 1.10 require a paid API to record video?**
No. shot-scraper 1.10 runs entirely locally via Playwright and headless Chromium. No external API key is needed for the video command. You define steps in a YAML storyboard file, run `shot-scraper video storyboard.yml`, and get an output video file. Cloud or MCP-hosted environments simply need the Playwright browser binary installed alongside the Python package.
**Q: How do MCP scraper servers integrate with shot-scraper video workflows?**
An MCP scraper server exposes tool calls that resolve URLs, handle authentication headers, and return rendered HTML or screenshots. In our setup, the scraper MCP resolves the final URL list, then passes those URLs into a shot-scraper storyboard YAML via a shell step in an n8n workflow. This decouples URL discovery from recording, so the video pipeline stays stateless and replayable.
**Q: Is shot-scraper video suitable for production monitoring, or just demos?**
It's currently best suited for demo generation and audit trails rather than real-time monitoring. Video rendering is synchronous and adds 30-90 seconds per run depending on page count. For production monitoring of MCP server behavior, lightweight screenshot diffing is faster. Use shot-scraper video when you need a human-readable record — client sign-offs, compliance audits, or QA regression reviews — rather than sub-second alerting.
---
## About the author
Sergii Muliarchuk — founder of FlipFactory.it.com. Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.
*Credibility hook: Our `scraper` and `docparse` MCP servers have processed over 15,000 structured extraction jobs since Q1 2026 — browser automation reliability is not theoretical for us.* Can shot-scraper video automate MCP agent demos?
shot-scraper 1.10 adds video storyboard recording. Here's how MCP server builders can use it to automate agent demo creation in CI pipelines.
Frequently Asked Questions
Does shot-scraper 1.10 require a paid API to record video?
No. shot-scraper 1.10 runs entirely locally via Playwright and headless Chromium. No external API key is needed for the video command. You define steps in a YAML storyboard file, run `shot-scraper video storyboard.yml`, and get an output video file. Cloud or MCP-hosted environments simply need the Playwright browser binary installed alongside the Python package.
How do MCP scraper servers integrate with shot-scraper video workflows?
An MCP scraper server exposes tool calls that resolve URLs, handle authentication headers, and return rendered HTML or screenshots. In our setup, the scraper MCP resolves the final URL list, then passes those URLs into a shot-scraper storyboard YAML via a shell step in an n8n workflow. This decouples URL discovery from recording, so the video pipeline stays stateless and replayable.