Demo MCP: Build a demo your agent can edit
Learn what demo mcp means in a real workflow, how to wire it to your repo, and how to build a demo your AI editor can safely update.
Open the demo you last sent a prospect. Now open your live product in a different tab. Count the things that don't match.
Demo MCP is the workflow that keeps that gap from getting worse: the demo lives in your repo, your AI editor can read it, and when the product changes, you re-prompt instead of re-record. The point is simple. The demo is code your agent can edit safely because the source of truth sits next to the code it represents.
What demo mcp means in a real product workflow
The repo, the client, and the server
Demo MCP is a three-part loop. The demo code lives in your repo. An MCP client — Claude Desktop, Cursor, or Claude Code — asks for context when you prompt it. An MCP server exposes the product data, tools, or current UI state the demo needs to stay accurate. The client gets context, edits the demo files, and the repo stays the source of truth. PostHog's MCP server is a working example: a hosted endpoint that lets an AI agent query product data through plain-text questions, with no custom integration required.
A minimal repo tree looks like this:
The demo files and the MCP server files sit in the same repo. That is the basic idea.
Why this is different from a recorded walkthrough
A screen recording is frozen. It lives inside the vendor's SaaS — Supademo, Arcade, Loom — and has no connection to your codebase. When a button label changes or a route moves, the recording shows the old version until someone re-records it.
A code-owned demo is just files. When the product changes, you prompt your agent against those files. The agent reads the current state of both the demo and the product, makes the edit, and commits it. No vendor UI, no manual click-through, no re-recording.
Why a code-owned demo is easier to trust than a screen recording
What breaks when the product changes
Here is the failure mode: your nav changes from `/dashboard` to `/home`. The app gets updated. The code-owned demo still points to `/dashboard` in its routing logic. An agent running against the repo catches that in one pass. It can grep the demo files for the old path, replace it, and regenerate the affected screens. A vendor-locked recording has no access to your repo. It keeps showing the old nav until someone opens the editor, re-records the affected screens one by one, and republishes.
The bigger the change, the more it hurts. A single label rename touches one screen. An API shape change — say, a payload field renamed from `user_id` to `userId` — can break every screen that renders user data. On a screenshot tool, that means one re-capture per affected screen. On a code-owned demo, it is one find-and-replace prompt.
The ownership test builders actually care about
Ownership is not an ideology. It is a practical question: can the same people and agents who change the product also change the demo without going through a third-party UI? If the answer is no, the demo will drift. The people closest to the product change — the engineer who renamed the field, the PM who restructured the nav — cannot touch the demo without switching into a separate tool they may not have access to or time for.
A demo in your repo is updated by the same workflow that updates everything else: a prompt, a diff, a commit.
How MCP connects Cursor, Claude Desktop, and your codebase
Start with Claude Desktop as the simplest client
Claude Desktop is the easiest entry point for an MCP demo workflow. You configure it with a `claude_desktop_config.json` that points at your local MCP server, and from there the AI can request context — current screen states, synthetic data, tool definitions — and edit the demo files in the repo. The Vercel Hono MCP template shows the server side of this: a lightweight Hono server that exposes MCP-compatible endpoints and can be deployed in minutes. The demo MCP workflow uses the same pattern locally.
The loop in Claude Desktop is straightforward: you prompt, the client calls the MCP server, the server returns the relevant tool or data, Claude edits the demo file, you review the diff. No screen recorder open anywhere in that sequence.
Where Cursor and Claude Code fit better
Claude Desktop is good for one-off edits and exploration. Cursor and Claude Code are better once the demo is treated as actual source, because they operate inside the repo directly, with full file access, git context, and the ability to run commands.
In Cursor, you open the demo directory alongside the product code. A prompt like "update the dashboard screen to match the current `/home` route and replace the old user payload fields" runs against both codebases at once. Claude Code handles the same prompt from the terminal. Either way, the demo edit is a code edit — diffable, reviewable, committable — not a manual walkthrough of a vendor UI.
Set up the demo mcp workflow in your repo
The file layout that keeps the demo honest
Before you ask the agent to touch anything, the layout has to be clear. The structure that works:
The `mcp-server/tools/` directory is where you define what the agent can request. `get-screen` returns the current HTML for a named screen. `list-screens` returns the available demo steps. The agent uses these to understand the demo's current state before it edits anything.
The env vars and credentials you actually need
Minimum setup for a local demo MCP run:
If your demo pulls live product data for synthetic previews, add the relevant API key for that service. Keep credentials out of the demo files themselves. The agent reads `.env` for config, not for content to embed in screens.
What to install before you ask the agent to touch anything
Install order matters. Run this sequence:
- `npm install` — get the MCP server dependencies
- Configure your MCP client (Claude Desktop: update `claude_desktop_config.json` with the server path and port; Cursor: add the MCP server to workspace settings)
- Start the MCP server: `npm run mcp-server`
- Verify the client can reach it — in Claude Desktop, ask "list the available demo screens" and confirm it returns your screen names
- Run your first edit prompt only after step 4 succeeds
Handing the agent a broken workspace — server not running, wrong port in config, missing env var — produces edits that look plausible but point to paths or data that do not exist. The verification step in step 4 is the cheapest way to catch that before it spreads.
Use prompts to create, update, and branch the demo
The first prompt that builds the demo
The agent generates the screens from the repo context the MCP server provides. What stays in human control: the seed data shape, which screens to include, and the review before commit. What the agent handles: HTML structure, copy, synthetic data rendering, and routing links between screens.
The update prompt after the product changes
The agent reads the current demo files via the MCP server's `get-screen` tool, makes the targeted edits, and outputs diffs. No screen re-capture. The change is scoped to what actually changed, not a full rebuild.
The variant prompt for different audiences
One base demo, one prompt per audience — founder, product engineer, dev advocate, sales engineer. The variants live in subdirectories of `/demo/variants/` and share the same MCP server tools. No cloning of the full artifact, no four separate recording sessions.
Show the demo against the live product without losing credibility
The mismatch check before a meeting
Before reusing any demo, open it next to the live product and check three things: route names match, field names in rendered data match, and any feature-gated UI that shipped since the last demo update is either included or deliberately excluded. The drift that matters most is route changes, payload field renames, and nav restructures.
When synthetic data is fine and when it starts to feel fake
Synthetic data is fine when it is internally consistent. The company name on the dashboard matches the company name in the settings screen. The plan tier shown matches the features unlocked. It starts to feel staged when the numbers are too round, the names are obviously placeholder ("Acme Corp", "Jane Doe"), or the UI shows a feature the prospect knows is not in their tier.
For founders and sales engineers reusing the demo across meetings: swap the company name and logo per audience, keep the metrics in a plausible range, and make sure any feature shown is one the prospect can actually access. One prompt handles all three.
Package the demo for Notion, docs, or sales handoff
What the downstream handoff should contain
After the demo is built and verified, the handoff artifact is four things: the hosted demo URL (or a local path if offline), a one-paragraph explainer of what the demo shows and what it omits, the repo path so the next person can update it, and the next step for the viewer (book a call, try the sandbox, read the docs). A Notion page with those four items is enough. The demo does not need to be rebuilt for each recipient. The repo path is the source of truth, and the agent can produce a variant for a new audience in one prompt.
How to keep the same demo useful across meetings
The demo stays useful as long as the repo stays current. That means: run the mismatch check before each reuse, commit updates as diffs instead of full rebuilds, and keep the variant subdirectories in sync with the base demo when the base changes. A Notion page or internal docs entry that links to the repo path — not just the hosted URL — means anyone on the team can pull the latest, run the update prompt, and ship a current demo without starting from scratch.
Where Inkly comes in
The structural problem the demo MCP workflow solves is that most demo tools make the demo an artifact that lives in their SaaS, not code you can hand to an agent. You can follow the repo-native pattern above with any stack, but the setup overhead is real. You are writing the MCP server, defining the tools, managing the file layout, and wiring the client config yourself.
Inkly is built on the same premise: the demo is code you own, and you iterate it through the three-prompt loop (create, update, variant) with your own agent (Cursor, Claude, Codex). The Chrome extension gives you the same quick first-capture speed as Supademo. The difference is what you get after capture. The demo comes out as HTML you own, not a recording locked in a vendor platform. When the product changes, you re-prompt against the existing code instead of re-recording the affected screens. When a new customer needs a tailored version, you prompt for a variant off the base: same flow, new branding, new data, in minutes.
The honest tradeoff: Inkly's MVP path is bring-your-own-agent. If you do not already have Cursor or Claude Code set up, there is a small amount of first-time config. A hosted in-app agent is on the roadmap. For builders already in a repo-native workflow, the setup is one less barrier than building the MCP server yourself. Demos as code you own — that is the premise, and it is the one this whole workflow is built on.
FAQ
Q: What does demo mcp actually mean in a real product workflow?
Demo MCP is a workflow where the demo lives in your repo as code, an MCP client (Claude Desktop, Cursor, or Claude Code) requests context from an MCP server you run locally, and the agent edits the demo files directly. The source of truth is the repo, not a vendor platform, so the demo can be updated the same way the product is updated.
Q: How do I build a code-owned demo that an AI editor like Cursor or Claude Code can safely modify?
Structure the demo as HTML files in a `/demo` directory alongside an MCP server in `/mcp-server`. Define tools that expose the current screen state and available screens. Configure Cursor or Claude Code to connect to the MCP server, then prompt against the demo files the same way you'd prompt against any source code. The agent reads the current state, makes targeted edits, and outputs diffs you review before committing.
Q: How do I connect MCP to a live codebase so the demo stays believable?
The MCP server exposes tools that read from both the demo directory and, optionally, your product's current routes or data schema. When you prompt an update, the agent calls those tools to understand the current state of the demo and the product, then makes the edit. The Vercel Hono MCP template is a working starting point for the server side.
Q: What should the demo show for a founder, product engineer, dev advocate, or sales engineer?
Use the variant prompt pattern: one base demo with the core three-screen flow, then a subdirectory per audience. Founders want the business outcome visible fast. Product engineers want the technical flow and API shape. Dev advocates want usage metrics and integration points. Sales engineers want the prospect's logo, their tier's features, and a plausible data set. One prompt per variant, off the same base code.
Q: How do I package the demo so it can be reused across meetings without breaking?
Handoff four things: the hosted URL or local path, a one-paragraph explainer of what the demo shows and omits, the repo path for updates, and the viewer's next step. Anyone with repo access can pull the latest, run the mismatch check, and re-prompt for a current version. The demo does not need to be rebuilt per recipient, only per meaningful audience difference.
Q: How do I keep the demo synchronized when the product or API changes?
Run the mismatch check before each reuse: compare route names, field names in rendered data, and any feature-gated UI. When something has drifted, run the targeted update prompt — name the specific change (route rename, field rename, nav restructure) and let the agent make the scoped edit. Commit the diff, not a full rebuild.
Conclusion
Go back to those two tabs — the demo and the live product. If you can count the mismatches faster than you could fix them, the artifact is in the wrong place. Wire one demo into the repo, stand up the MCP server, and run one update prompt. If your agent can edit the demo file and produce a clean diff without you touching a screen recorder, the workflow is working. That is the test that matters.
Ship your next demo before the meeting starts
Interactive demos built from your real product and kept current as you ship, done for you.
