FlowScope UX Flow Analyser

flowscope-mcp

An MCP server that exposes the FlowScope UX-analysis pipeline to any LLM client. Speaks MCP protocol 2026-07-28 and ships two spec-portable Agent Skills.

uvx flowscope-mcp        # stdio server; needs a local FlowScope backend

FlowScope takes a YouTube product-demo URL, downloads the video, transcribes it, extracts and de-duplicates screenshots of each distinct screen, describes every screen with a vision model, and synthesises a step-by-step UX flow. This package turns that pipeline into tools an agent can call.

Ask your agent something like:

Compare the onboarding flows in these two videos: and

Tear down the checkout UX in this demo:

Requirements

This server is a client of a running FlowScope backend; it does not run the pipeline itself. Start the backend first:

cd backend

uvicorn app.main:app --port 8000

The backend needs ffmpeg, a Python environment with backend/requirements.txt, and one LLM provider key in backend/.env. The server's flowscope_health_check tool reports exactly which of these is missing, so you can ask your agent to check rather than guessing.

Install

As a Claude Code plugin

One step, and it brings the skills, the prompts, and the server registration:

/plugin marketplace add DavidNgugi/flowscope

/plugin install flowscope@flowscope

From PyPI

Nothing needs a permanent install — uvx runs it in a throwaway environment. uv is the only prerequisite (brew install uv):

uvx flowscope-mcp                 # starts a stdio server

uvx flowscope-mcp --version # confirm the published version uvx flowscope-mcp@0.1.0 # pin, when reproducibility matters

From a git URL or a local checkout

uvx --from /absolute/path/to/flowscope/mcp flowscope-mcp

uvx --from "git+https://github.com/DavidNgugi/flowscope.git@main#subdirectory=mcp" flowscope-mcp

Environment

These are read from the process environment on each call. The MCP Python SDK v2 deliberately stopped reading MCP_* variables and .env files, so set them in your client's server configuration instead.

Point a harness at it

The config shapes genuinely differ — VS Code's own file uses `servers` where every other client uses `mcpServers`, Codex is TOML, and Claude Desktop does not expand ${VAR} placeholders — so generating the file is more reliable than copying a snippet:

uvx --from flowscope-mcp flowscope-mcp-install --help   # every client + its path

uvx --from flowscope-mcp flowscope-mcp-install print # portable JSON, writes nothing

uvx --from flowscope-mcp flowscope-mcp-install claude-code uvx --from flowscope-mcp flowscope-mcp-install cursor uvx --from flowscope-mcp flowscope-mcp-install vscode uvx --from flowscope-mcp flowscope-mcp-install codex uvx --from flowscope-mcp flowscope-mcp-install gemini uvx --from flowscope-mcp flowscope-mcp-install claude-desktop

It merges into an existing config file and leaves other servers alone.

VS Code additionally reads the portable /.mcp.json shape (key mcpServers), which flowscope-mcp-install vscode-portable writes when you want one config shared with Claude Code and Cursor.

Remote / shared deployment

Run one server for several clients, or for a harness that cannot spawn a process:

flowscope-mcp --transport streamable-http --host 127.0.0.1 --port 8765

Clients connect to POST http://127.0.0.1:8765/mcp:

claude mcp add --transport http flowscope http://127.0.0.1:8765/mcp

docs/install.md has the full per-harness reference, the placeholder syntax each one accepts, and the two traps that most often break an install.

Use it

Restart your client, open a new chat, and check the install first:

Check whether FlowScope is ready to use.

That runs flowscope_health_check and names anything missing — usually ffmpeg or an LLM provider key on the backend host. Then ask for what you want.

Example prompts

One video, fully analysed

Tear down the onboarding UX in this demo:

What does this product actually do, based on this demo? Walk me through the flow screen by screen:

Analyse and tell me where a first-time user would get stuck.

A specific question about a flow

In this demo, how many steps does signup take, and what does each one ask for?

Does this demo show any error or empty states?

What's above the fold on the first screen, and what's the primary call to action?

Several videos, compared

Compare the onboarding flows in these two demos. Where do they diverge, and what's the trade-off each one makes?

-

-

I'm designing a checkout flow. What do these two demos do differently, and what should I borrow?

Which of these three gets a new user to first value fastest, judging by the demos?

Working with what already exists

What videos has FlowScope already analysed?

Show me the screenshot of the pricing screen from that report.

You do not need to phrase these carefully. Analyses are cached by YouTube video id, so a vague prompt costs a lookup rather than a re-analysis — the agent checks the cache before spending anything.

What happens after you press enter

Analysing a video downloads it, transcribes it, extracts and de-duplicates screenshots, then makes one vision call per distinct screen plus a synthesis call. A five-minute demo typically yields 15–40 screens. Expect 2–10 minutes and real money per video.

flowscope_analyze_video waits by default and usually returns the finished report directly, so one prompt is normally enough. If the video needs longer than the budget it returns status: "running" with a video_id, and the agent should poll flowscope_job_status. If it resubmits the URL instead, stop it — that starts duplicate work.

Answers are grounded, or should be

Reports have three layers: ux_insights (the synthesis), flow_steps (the ordered user path), and frames (the evidence — one entry per screen, with its purpose, UI elements, and aligned narration). A good answer leads with the insights and cites the screen behind each claim. The bundled skills enforce this, including saying "the demo does not show this" rather than inferring.

docs/usage.md has the full walkthrough, prompt patterns that produce better answers, and a troubleshooting table.

Tools

Ten tools, split between read-only inspection and actions that cost money.

Plus two prompts (flowscope_ux_teardown, flowscope_compare_flows) and two resources (flowscope://videos, flowscope://videos/{video_id}/report).

Cost and time

Analysing a video downloads it, transcribes it, and makes one vision call per distinct screen plus a synthesis call. That is minutes and real money per video. Two things protect against waste:

• Results are cached by YouTube video id. flowscope_list_videos reveals existing analyses, and resubmitting a finished video is free and instant.
• flowscope_analyze_video checks the cache before starting work and only submits what is actually new.

The bundled skill teaches an agent to check the cache first.

Transports

flowscope-mcp                                  # stdio (default)

flowscope-mcp --transport streamable-http --port 8765

Streamable HTTP serves POST /mcp. The SDK serves the 2026-07-28 protocol revision and the older handshake era from the same endpoint, so legacy clients work without extra configuration. Legacy clients create server-side sessions, which are stored in-process — if you run more than one worker behind a load balancer, enable sticky routing.

Skills

Two Agent Skills ship alongside the server, written to the open specification so they install into any compatible client:

They carry the operational knowledge the tool descriptions cannot: check the health and the cache before spending money, read the synthesis rather than re-deriving it from the raw transcript, say "the demo does not show this" rather than inferring, and treat an auto-caption's product names with suspicion.

The skills and the server are independent — the skills are useful on a report you already have, and the server