Driving it from an agent
Install the Rendemo plugin for Claude Code, sign in with npx rendemo login, and use /rendemo:demo and /rendemo:tour — or connect any MCP-compatible agent to the server directly.
Install the plugin
Rendemo’s MCP server has a large tool surface. That is an API, not an interface — you would have to know which tool to call, in what order, with what arguments. The Claude Code plugin ships the workflow instead: you state an intent, and the agent sequences the tools, stops at the checkpoints that matter, and writes the files the MCP cannot touch.
claude plugin marketplace add https://www.rendemo.com/marketplace.json
claude plugin install rendemo@rendemoBoth commands name rendemo — the first is the marketplace, the second is the plugin inside it. Or run /plugin interactively and pick it. Either way, restart Claude Code afterwards — MCP servers are wired up at startup.
The plugin installs from npm, so updates resolve through the registry and claude plugin list shows a real version. A GitHub source — claude plugin marketplace add jakegrepo/rendemo-plugin — works too, and is the one to use if you pin to a tag or commit. Team and Enterprise admins distributing through Organization settings must use it: organization sync does not support npm plugin sources.
Sign in
The endpoint authenticates with a per-workspace bearer token, so no token can ship inside the plugin. One command handles it:
npx rendemo loginIt prints a short code and a URL, you approve in a browser where you are already signed in, you pick a workspace, and the token is stored in a per-user config file outside every checkout. The token is never printed and never logged. npx rendemo logout removes it.
| OS | Config path |
|---|---|
Windows | %APPDATA%\rendemo\config.json |
macOS / Linux | $XDG_CONFIG_HOME/rendemo/config.json, else ~/.config/rendemo/config.json |
RENDEMO_API_TOKEN still works and is the right answer for CI. Get the token from Workspace settings. It takes precedence over a stored login, which makes it the usual cause of “I logged in but it is using the wrong workspace”. npx rendemo doctor says which source is in play.
The commands
Three, and the first one exists so you never have to know which of the other two you wanted.
| Command | What it does |
|---|---|
/rendemo:start | Picks between a demo and a tour from what you typed, and hands off. Asks one question only when the intent is genuinely ambiguous. |
/rendemo:demo | Installs a published demo on your site: picks the demo, detects the framework from your repo, writes the wrapper and the tag. It will not publish anything without asking, and it stops before writing files if the demo is password-protected. |
/rendemo:tour | Authors or edits a tour. It reads your repo and proposes the steps as a table with a file:line per target, then waits for approval there — that table is the checkpoint, because it is the first thing you can actually judge. Writes the markers as a reviewable diff, hands you a preview link, and asks before publishing. |
Any MCP agent
The plugin is the front door; the MCP server stays the API for everything else — Claude.ai, or anything MCP-compatible.
| Endpoint | https://www.rendemo.com/api/mcp/mcp |
| Transport | Streamable HTTP, stateless |
| Auth | Authorization: Bearer <workspace API token> — the same token the browser extension uses. Every tool is scoped to that workspace, and no tool accepts a workspace id, so switching workspaces means switching tokens. |
By hand
claude mcp add --transport http rendemo https://www.rendemo.com/api/mcp/mcp \
--header "Authorization: Bearer <your workspace API token>"For Claude.ai, add a custom connector with the same URL and header. For an editor that reads an mcp.json — Cursor, Cline, Windsurf, VS Code — that is this:
{
"mcpServers": {
"rendemo": {
"type": "http",
"url": "https://www.rendemo.com/api/mcp/mcp",
"headers": { "Authorization": "Bearer <your workspace API token>" }
}
}
}That is the standard shape, but the file it belongs in and the wrapper key vary by client — VS Code nests the same rendemo object under servers rather than mcpServers. Check your editor’s own MCP docs for the path. Workspace settings has all of these ready to paste with the token already filled in.
Tool reference
108 tools across 26 groups. Every name, title and description below is read from the server’s own registry at build time — the same registrations the endpoint serves — so this list cannot drift from the code. Arguments are in schema order; the full schema comes back on tools/list.
Craft
1 toolRendemo's own direction and taste, as skill documents — read the relevant one before a polish, restyle or re-direct pass.
rendemo_load_craft_skillRead onlyLoad a craft skillRendemo's own direction and taste for a given kind of work, as a skill document. Read the relevant one BEFORE a polish, restyle, re-direct or "make it look professional" pass — each carries the treatments that actually exist, the combinations the runtime rejects, and the rules that silently discard a change you thought you applied. Cheap, read-only, no project needed. - brand-and-look — Use when choosing or changing how the demo LOOKS as a system, not step by step — picking a card look, the backdrop and frame, applying a brand kit, setting accent/material/density/motion, fixing overflowing copy, choosing a presentation recipe, or the video's kinetic-text style. Read it before rendemo_set_demo_presentation_theme, rendemo_set_demo_backdrop, rendemo_set_step_presentation, rendemo_design_brand_style, or any "make it match our brand / pick a look" request. - camera-direction — Use when framing shots or adding camera movement to EITHER the interactive demo or the rendered video — "zoom in on that", "the camera is too jumpy", "add a push-in", "make it more cinematic", "why isn't the camera moving", "re-frame step 4", or before calling rendemo_direct_step / rendemo_auto_direct / rendemo_frame_video_shot / rendemo_set_video_shot. Covers the shot vocabulary, when a step earns a move at all, and the runtime rules that silently discard a move you thought you wrote. - demo-craft — Use when polishing the INTERACTIVE demo — the step SCENE (form, grade, mark, tie, entrance, reveal), highlight rects, step copy and roles, real-DOM effects, product data, and the bulk styling pass. Read it before rendemo_update_step, rendemo_style_steps, or any "make this step land" request. - drive-and-record — The agent drives the user's signed-in product — rehearses unrecorded, proposes the take as a plan the user approves, then records one clean pass. A real take for a data-dense product, no replica to leak. - new-demo — Use when someone wants a demo and no project exists yet: what to ask first, why a recording beats a crawl, and reaching a published link from chat. - sandbox-demos — Use when authoring a SANDBOX DEMO from a crawled replica we host. Read before rendemo_add_sandbox_demo_step: asking the author for vibe/motion, surveying pages, durable targets, cards, validation, publish order, and promoting a re-crawl of an already-published sandbox. Tours are only for codebases. - tour-craft — Use when authoring or polishing a CODEBASE TOUR — the overlay that guides a visitor through the customer's own live product via data-rendemo markers. Read it before rendemo_add_tour_step or any "make the tour better" pass. Covers what a tour card renders, emphasis, the magnified lens, marker resolution, and verification. - video-craft — Use when improving the rendered VIDEO cut — "the video feels snappy / warpy / over-zoomed", "make it look professional", "make it a launch film", "add music / a title / b-roll / captions", "tighten the pacing", or before calling rendemo_get_video_plan, rendemo_tune_video, rendemo_apply_video_treatment, or any rendemo_cinematic_* tool. The video is the same plan the demo reads, but the card and emphasis tools do NOT shape it — these levers do.
args skill
Read
7 toolsLook at what exists before changing it — projects, the plan, the funnel, and the audit trail of every AI-made change.
rendemo_list_projectsRead onlyList projectsList the workspace's demo projects (newest first): id, name, step count, published demo url when live, and whether the demo is password-protected. Start here to find the projectId every other tool needs.
args limit
rendemo_get_planRead onlyGet plan summaryThe demo plan as an agent needs it: every step in play order with its role, emphasis, marker, card variant and recipe, target geometry, framing authorship, viewport overrides, and whether a sandbox demo step carries a camera move. It also reports unbound recorded targets, plus demo-wide presentation, guide, choreography, lead-capture and playback settings. Read this before styling so you do not set something the runtime will discard.
args projectId
rendemo_get_demo_analyticsRead onlyGet demo analyticsThe published demo's funnel: viewers, completion, per-step drop-off, CTA rate, campaigns, per-variant outcomes with the current best performer, and lead count. The starting point of every improve-the-demo loop.
args projectId
rendemo_list_leadsRead onlyList demo leadsCaptured leads for a project's demo, with the step each in-card lead converted at (intent depth). Read-only; emails are viewer PII — handle accordingly.
args projectId · limit
rendemo_get_journeyRead onlyGet journey graphThe demo's step graph: linear flow, branch edges (card choices + goto hotspots), unreachable steps and dangling branch targets. Use before/after editing choices.
args projectId
rendemo_review_projectRead onlyReview readinessPre-publish review: per-step sign-off states, untitled steps, missing lead capture, and step/lead totals. The launch-checklist tool.
args projectId
rendemo_get_decision_logRead onlyReview past AI decisionsThe audit trail of every AI-made change (copilot and MCP): directing calls (camera shots, card placement), copy rewrites, emphasis/design updates, publishes — each with its arguments and outcome. Read it BEFORE re-directing or re-diagnosing a demo so you build on (or deliberately reverse) earlier decisions instead of repeating them.
args projectId · limit
Story & copy
6 toolsWhat each step says, and the order the steps say it in.
rendemo_write_step_captionsWrite step captions with AIRewrite step titles + helper lines with Claude from the recorded click-through (the same writer behind the editor's AI improve). mode 'fill' captions only element-labeled steps; 'rewrite' redoes every step. Author edits always survive 'fill'.
args projectId · mode
rendemo_run_story_directorPropose (or apply) a whole-demo storyClaude re-directs the whole demo as one story: selects/orders the strongest 4-12 moments, writes copy, picks per-step layout + emphasis, chooses the look, playback and ending. Give an instruction to steer (audience, outcome, tone). BY DEFAULT IT ONLY PROPOSES — it returns the story, the rationale and the exact list of changes, and writes nothing. Show the author what it would do, and call again with apply:true only after they say yes. Applying REPLACES current story choices (copy the author wrote is preserved by the proposal normalizer where ids survive).
args projectId · instruction · apply
rendemo_update_stepUpdate a stepTargeted patch on one step (recorded beat or authored step): title, blurb, CTA label, the step SCENE (form, grade, entrance, mark, tie, reveal, scale, weight) + emphasis color, click marker, card variant/size/placement/anim, eyebrow, per-step choreography, narration, branch choices, persona variants, hidden, and `effects` — the real-DOM treatments the interactive embed applies to the replayed element itself (pop/lift/tilt/nudge/tint/type/set-text/toggle-class/spotlight/count-up/progress/reveal/hide). Only the fields you pass change. Pass null on a nullable field to clear it.
args projectId · stepId · title · blurb · stepType · successMessage · recoveryHint · searchTerms · advanceLabel · emphasis · scene · emphasisColor · marker · eyebrow · choreography · narration · choices · variants · hidden · targetSelector · replayFrameMs · rect · holdThrough · playIn · playSpeed · effects
rendemo_style_stepsStyle many steps at onceBulk-update step copy, emphasis, markers, choreography, travel pacing and framing (`playIn`/`playSpeed`/`holdThrough`) and real-DOM `effects` — the whole per-step patch surface, up to 40 steps in one call. Use rendemo_apply_presentation_direction for recipe assignments and rendemo_auto_direct for camera framing.
args projectId · steps · device · preview
rendemo_set_product_dataSet the demo's product dataRead and write the demo's product variables (plan.personalizationTokens) — find→replace pairs applied to the card copy AND to the replayed product's own text nodes (reassembled across element boundaries, so a name split over two spans still matches), plus image/logo swaps on the replayed imagery. This is how one recording becomes a demo that says the prospect's company name and shows their logo. Call with no ops to read the current list. `set` upserts by label, `remove` deletes by label, `replaceAll:true` makes `set` the entire list. Image/logo replacements must be an https: URL or a same-origin path.
args projectId · set · remove · replaceAll
rendemo_reorder_stepsReorder stepsSet the demo's play order. Pass the COMPLETE ordered list of step ids from rendemo_get_plan (a partial list drops the missing steps from the story order).
args projectId · order
Presentation
10 toolsRegistry-backed composition, materials, motion, target behavior, review, and whole-demo direction.
rendemo_apply_custom_designApply a saved custom designApplies a card, emphasis or pointer saved in the workspace library to one step. Use rendemo_list_presentation_recipes to discover ids. A coded card replaces the step's recipe rendering, and also sets the emphasis mode and marker the design was drawn against where it declares them; a coded emphasis or pointer replaces the step's emphasis mode and marker entirely.
args projectId · stepId · designId
rendemo_list_presentation_recipesRead onlyList presentation recipesReturns the WHOLE card vocabulary: the five forms, the grades, marks, ties, reveals and entrances, the scene's two continuous scalars, and the workspace's own saved designs. There is one vocabulary — a step's look is its scene, and nothing else sets it.
args role
rendemo_set_demo_presentation_themeSet demo presentation themeSets the DEMO-WIDE scene every step starts from, plus how the accent is used and how far the camera commits. The scene here is a floor, not a lock: any step can override any axis. Five fields replace what were nine — a material is a grade, density and motion intensity were the scene's two scalars, and both connector flags were a tie.
args projectId · themeId · scene · accentMode · motionIntensity · missToast · restingHint
rendemo_set_step_presentationSet step presentationSets one step's SCENE — its card, what the surround does, how the target is marked, what points at it, and whether the product itself moves — plus the copy. Copy that overflows the form it is set in is rejected before the plan is saved. For anything the scene axes cannot express, write the card yourself with rendemo_apply_custom_design.
args projectId · stepId · scene · content
rendemo_suggest_step_presentationsRead onlySuggest step presentationsProposes a FORM per step from its role, the director's story intent, its narrative position, and whether it has a target to point at — resolving through the same intent map the build uses, so a suggestion cannot disagree with what publishing would produce. The result can be passed to rendemo_apply_presentation_direction as-is. Reads the plan; changes nothing.
args projectId
rendemo_apply_step_presentation_style_to_allApply one card's styling to all cardsCopies the source step's material, compatible motion, typography, per-block text formatting, and border to every demo card while preserving each step's recipe, composition, content, target relationship, branching, media, and analytics identity.
args projectId · sourceStepId · preview
rendemo_review_step_presentationsRead onlyReview step presentationsReturns deterministic copy, content, role, responsive, accessibility, repetition, and narrative-rhythm findings plus a signed real-render review URL. Content findings are the SAME rules the publish gate enforces, each tagged blocking or warning, so this says in advance what a publish will refuse. It counts characters against a form's budget; it does not SEE the demo, so it passes on a card that is unreadable over the product behind it. For that, publish and call rendemo_review_demo_frames, which returns real screenshots of each step.
args projectId
rendemo_apply_presentation_directionApply presentation directionApplies an approved recipe sequence while preserving copy, interactions, branches, narration, hotspots, and analytics identifiers.
args projectId · assignments
rendemo_set_demo_backdropSet the demo backdrop and window frameSet the stage the demo sits on: the backdrop behind the product (one of eight curated presets — midnight, slate, graphite, linen, sand, aurora, ocean, plum — or your own solid colour or two-stop gradient), how the product is mounted on it (pad, radius, shadow) and whether a browser window frame is drawn around the recording. Pass exactly one of preset/solid/gradient, or clearBackground to go back to the plain brand-kit surface. Chrome light/dark is derived from the backdrop's own luminance unless you set `mode`.
args projectId · preset · solid · gradient · clearBackground · pad · radius · shadow · frame · mode
rendemo_style_player_shellStyle the player chrome with your own CSSRestyle the demo player's own chrome -- the header, the transport bar, the step dots, the chapter list and the footer -- with your own CSS. Every selector must name a piece of the chrome: any .rps-* class, .modebtn, or .wrap / .col on their own. Selectors are scoped and specificity-raised for you, so write plain rules and no !important. Pass clear:true to go back to the stock chrome. Read the class names off rendemo_get_embed, or ask for the current sheet with css omitted.
args projectId · css · clear
Card preview
1 toolSee a step's card as HTML before publishing it — the real renderer, and several candidate looks side by side.
rendemo_render_step_cardRead onlyRender a step's cardThe actual HTML of one step's card — composed by the same renderer the player and the live tour use, with its own scoped stylesheet and no external references. Pass `variants` to render several candidate looks of the SAME step side by side (different recipe/material/emphasis, optionally different copy) and choose by looking rather than by publishing. Each variant reports whether the runtime would actually accept it: a recipe carries a role constraint and a copy budget, and a refused combination is returned with the reason instead of a card that could never ship. Returns every variant on one comparison page as well as one embedded HTML resource per card. Clients may render or save those resources according to their supported MCP resource behavior.
args projectId · stepId · variants
Revisions
3 toolsUndo, over the protocol. Every mutating tool writes a labelled revision now, so a pass you regret is findable by the tool that made it and reversible without opening a browser.
rendemo_list_revisionsRead onlyList a project's saved revisionsEvery saved state of this project's plan, newest first — what each one was labelled, who wrote it, and when. A revision holds the plan as it was BEFORE the write that created it, which is the state rendemo_restore_revision goes back to. Every mutating MCP tool writes one labelled with its own name, so a pass you regret is findable by the tool that made it.
args projectId · limit
rendemo_restore_revisionRestore a saved revisionPuts the plan back to a saved revision — the undo for a pass that went wrong. Find the id with rendemo_list_revisions. Call with `preview` first to see what restoring would change; a restore is itself a write, and it writes its own revision before it, so nothing is lost either way. It restores the PLAN only: a published demo keeps serving its existing artifact until you publish again.
args projectId · revisionId · preview
rendemo_remap_after_recaptureRead onlyPreview a re-capture remapREAD-ONLY. Given a project and a second project holding a NEW recording of the same product, reports what would carry across: card copy, camera framing and hotspots, each with a confidence and the evidence behind it (a unique element label, a shared one, or merely position in the recording). It applies NOTHING and there is no argument that makes it apply. Redaction rectangles and product-data replacements are never proposed for migration at any confidence — a redaction that lands on the wrong element publishes the thing it was hiding, and that failure is invisible from looking at the demo. Those are listed as unresolved, and a publish is refused until a person has re-made or dismissed each one. Show the queue to the author; applying is theirs.
args projectId · fromProjectId
Design a card
1 toolWrite a step's card yourself. Ask for the brief, write the CSS on your own subscription, and it is validated and applied — the escape hatch the scene axes cannot cover.
rendemo_design_cardDesign a cardWrites one step's card yourself, in CSS. Call it WITHOUT `css` to get the full design brief — the runtime contract, the live slots, the brand tokens, the motion rules and the per-step target variables — then call it again with the CSS you wrote, which is validated and applied. This is the escape hatch the scene axes cannot cover, and it is the same brief the Studio hands Claude. `layout` designs the card's own DOM and keeps it editable; `composable` styles the existing anatomy; `raw` replaces the markup and gives up the inspector's controls.
args projectId · stepId · direction · mode · css · layout · markup · placement · name
Conversion
4 toolsLead capture, translations, and per-campaign tracking links.
rendemo_configure_lead_captureConfigure lead captureThe demo's conversion moment: a gate at start/end (or at a step), and/or the in-card inline email form at a chosen step (capture at peak intent, no gate). Sets every string the gate renders, including the privacy line and the post-submit confirmation. Leads flow to the dashboard, webhooks, and CRM integrations with step context. Pass enabled=false to remove capture entirely.
args projectId · enabled · placement · gateStepId · inCardStepId · required · heading · body · button · fields · customFields · handoff · consentText · privacyText · privacyUrl · successHeading · successBody
rendemo_add_localizationAdd a localizationTranslate every card's copy into a locale with Claude (or store provided copy) — the default published demo then swaps to the viewer's language on arrival (localized-on-arrival). Locale is a BCP-47-ish tag: ja, de, pt-BR. Re-running a locale overwrites its draft.
args projectId · locale
rendemo_create_tracking_linkCreate a tracking linkA campaign-attributed share URL for the published demo (views, completion and leads segment by campaign in analytics). Returns the /t/<token> URL to share.
args projectId · name · campaign
rendemo_list_tracking_linksRead onlyList tracking linksExisting campaign links for the project's demo, with view counts.
args projectId
Embed
1 toolEverything needed to install a published demo on a website.
rendemo_get_embedRead onlyGet the embed code for a demoEverything needed to install a published demo on a website: the script tag and where it goes for this framework, the markup, and the source of a local wrapper component. The demo must be published first. Write the returned files yourself — this tool cannot touch your filesystem.
args projectId · framework · mode
Tour
13 toolsAuthoring guidance on your own product: markers, preview, the lockfile, and the second visit.
rendemo_create_tourCreate a product tourCreate a TOUR — step-by-step guidance on the user's OWN product, which they perform for real. No recording: each step is anchored to a data-rendemo marker you write into their source. Returns the tour slug to use in every marker. Add steps with rendemo_add_tour_step, preview it with rendemo_get_tour_preview, then publish; only published tours run for visitors. If the user instead wants something a visitor WATCHES, that is a demo — record and publish one, then install it with rendemo_get_embed.
args name · tourSlug
rendemo_create_sandbox_demoCreate a sandbox demoCreate a hosted SANDBOX DEMO backed by a crawled replica. This is a demo viewers watch and share, not a codebase tour: it writes nothing into customer source and has no lockfile. BEFORE styling anything, ask the USER what vibe and motion they want — the sandbox-demos skill carries the exact questions and the theme menu; never pick a look silently. Survey the source sandbox first, add steps with rendemo_add_sandbox_demo_step, validate with rendemo_check_sandbox_demo, then publish the source sandbox followed by this demo.
args name · demoSlug · sandboxDemoId
rendemo_add_tour_stepAdd a step to a tourAppend a step to a CODEBASE TOUR and return the exact data-rendemo attribute to write into customer source. Read the `tour-craft` skill first. For a hosted sandbox demo, use rendemo_add_sandbox_demo_step instead. The optional `sandbox` input remains accepted only for older clients and creates a sandbox-demo step; new agents must not use it.
args projectId · step · route · sandbox · do · wait · match · title · blurb · emphasis · lens
rendemo_add_sandbox_demo_stepAdd a step to a sandbox demoAppend a step to a hosted SANDBOX DEMO. Choose the target from rendemo_list_sandbox_pages plus rendemo_find_in_sandbox or rendemo_read_sandbox_page; the server stores durable element facts and re-resolves them after rebuilds. This tool never returns a marker to write into customer source. Use rendemo_add_tour_step only for codebase tours.
args projectId · step · sandbox · do · wait · match · title · blurb · emphasis · lens
rendemo_check_sandbox_demoRead onlyCheck whether a sandbox demo's steps still resolveFor a SANDBOX DEMO only: re-scores every authored step's stored facts (from rendemo_add_sandbox_demo_step) against the source sandbox's CURRENT pages and reports, per step, whether it would still resolve — without writing anything. RUN THIS after any sandbox rebuild (a re-recording, a re-extraction) and before publishing: a rebuild renames files and can reflow the DOM enough that a step which resolved yesterday scores differently today, and this is how that is caught before a visitor is. Uses the SAME scoring the real stamping pass (at publish, and again after every rebuild) uses, so a step reported 'resolved' here will stamp, and one reported 'ambiguous' or 'absent' will not. 'resolved' names the winning element's node id and score. 'ambiguous' means two elements were too close to call — the runner-up's score is included so you can judge how close, and how to make the target more specific (an id, a data-testid) to break the tie. 'absent' means nothing scored high enough — most often the element is gone from the current sandbox, or the sandbox itself is not built or not in this workspace. Codebase-tour steps added with a plain `route` are skipped; this tool refuses when the project has no sandbox-demo steps.
args projectId
rendemo_list_toursRead onlyList product toursEvery TOUR in this workspace: projectId, name, tour slug, step count, and whether it is currently live. Start here for any change to an existing tour — adding a step, rewording one, reordering, or removing one. Replay demos are deliberately excluded; they are a different artifact and rendemo_list_projects covers those. With a projectId in hand: rendemo_get_plan for the step ids, rendemo_add_tour_step to append, rendemo_update_step to reword, rendemo_reorder_steps to reorder, rendemo_remove_tour_step to drop one, rendemo_remove_tour to retire the whole thing.
args limit
rendemo_remove_tour_stepRemove a step from a tourDelete one step from a tour AND get back the data-rendemo marker you must strip from source in the same change. THIS IS NOT OPTIONAL: leaving the marker behind makes `rendemo check` fail the build with an orphan-marker, so removing the step without removing the attribute breaks CI for whoever pushes next. Present both edits as one reviewable diff. Afterwards the tour must be published again (rendemo_publish_demo) and the lockfile regenerated (rendemo_get_tour_lockfile) — until then the committed lockfile still describes the step you removed. Refuses when another step's branch choice points at this one, because a dangling choice is dropped silently rather than reported, and refuses on the last remaining step (use rendemo_remove_tour to retire the whole tour).
args projectId · stepId
rendemo_take_demo_offlineTake a published demo or tour offlineStop serving ONE published demo or tour, without deleting anything. Its public link, its poster, and any tour running on the customer's pages all go dark within 30 seconds (the payload's edge-cache window); a visitor whose tour is ALREADY running finishes it — this stops it being served, it does not reach into open tabs. The published plan is preserved, so re-publishing later serves the identical artifact. Use this the moment a live tour is wrong, points at removed UI, or should not be running. To take EVERY tour in the workspace down at once (a release that moved the UI out from under all of them), the human turns off Settings → Product tours instead. To put this one back on the air, publish it again (rendemo_publish_demo) or use Put back online in the library.
args projectId
rendemo_remove_tourRetire a tour: offline, markers stripped, lockfile entry goneRetire a whole tour in one reviewable change. Takes it offline (it stops being served within 30 seconds) AND returns every data-rendemo marker to strip from source AND the contents of rendemo.tours.json with this tour's entry removed and every other tour preserved. Do all three: taking it offline while the markers stay in source leaves `rendemo check` failing the build with orphan-marker for each one, which is the safety feature turning into a nuisance exactly when someone is backing out. NOTHING IS DELETED — the plan and the published plan are kept, so publishing again later serves the identical artifact; only the serving stops and the source is cleaned. If you only want it dark for a moment (a live tour pointing at UI that just moved), that is rendemo_take_demo_offline instead, which touches no files.
args projectId · lockfile
rendemo_get_tour_lockfileRead onlyGet the tour lockfile to commitThe exact contents of rendemo.tours.json for a PUBLISHED tour. Write this file to the repo root and commit it — the `rendemo` CLI reads it offline in CI to verify every step still has a marker in source. That CLI is published on npm, so `npx rendemo check` works with no install (needs rendemo@0.2.0 or newer for the rendemo.tours.json name). IMPORTANT: if the repo already has a lockfile — rendemo.tours.json, or the older rendemo.flow.json — read it and pass its text as `lockfile` — one file describes EVERY tour in the repo, and writing a single-tour file silently stops checking the others.
args projectId · lockfile
rendemo_probe_tour_targetsRead onlyCheck each step's marker against the running appFetches every step's route from the user's running app and reports, per step, whether the tour would find its marker there. RUN THIS BEFORE rendemo_get_tour_preview: it catches the failures a preview would otherwise spend the reviewer's time (and the link's 30-minute clock) discovering — markers not deployed to that host, a route that renders a sign-in stub, a marker that resolves to several elements with no `match`. HOW TO READ 'absent': the probe sees the HTML the server sends a SIGNED-OUT stranger. A marker rendered after sign-in, or only on the client after hydration, is genuinely missing from that response and genuinely present for the real visitor. So 'absent' means look here, not broken — and knowing WHICH steps need a signed-in session is exactly what makes the preview review efficient rather than confusing.
args projectId · baseUrl
rendemo_get_tour_previewRead onlyGet a link that previews this tour before it is liveA ready-to-open URL that runs the tour's CURRENT DRAFT on the user's own running app — before publishing, and without publishing. Open it in a browser pointed at their app (a dev server, a staging deploy, production) and the tour appears, with a persistent "Preview" badge on every card so a draft is never mistaken for the live thing. Nothing is published, no analytics are recorded, and progress is kept out of a real visitor's storage. SHARE IT CAREFULLY: the link is a bearer token — anyone who opens it sees the draft, with no sign-in — and it expires 30 minutes after it is issued. THE LIMIT WORTH SAYING OUT LOUD: the data-rendemo markers must already exist in the BUILD being previewed. Against a dev server that is immediate (save the file). Against a staging or production URL, the commit that adds the markers has to be deployed there first, or every step will report that it cannot find its target. RUN rendemo_probe_tour_targets FIRST. It answers that from the host itself, in seconds and without spending any of this link's 30 minutes — and the clock here starts the moment the link is issued, so mint it when the reviewer is ready to look, not before a build or an install.
args projectId · baseUrl
rendemo_get_sandbox_demo_previewRead onlyPreview a sandbox demo before publishingReturn a ready-to-open, 30-minute bearer link for the CURRENT DRAFT of a hosted sandbox demo. It opens on Rendemo's workspace host, carries a persistent Preview badge, publishes nothing, records no analytics, and requires no customer source markers. Run rendemo_check_sandbox_demo first.
args projectId
Sandbox pages
3 toolsList, grep and read the extracted pages behind a sandbox replica — the same list/grep/read an agent gets against a customer's own repo.
rendemo_list_sandbox_pagesRead onlyList a sandbox's extracted pagesEvery page in a SANDBOX replica — a free-roam, byte-accurate rebuild of a recorded product, extracted from a screen recording rather than read from a customer's own repo. Returns each page's file name (the exact address rendemo_find_in_sandbox and rendemo_read_sandbox_page expect), the URL it was recorded from, its size in bytes, and which ONE is the entry page a visitor lands on first — `bytes` comes back null for a page storage could not answer for right now, without failing the rest of the list. Sizes only: this tool never opens a page, so it cannot tell you what is ON one. Pick a page by its recorded URL and size, then call rendemo_find_in_sandbox or rendemo_read_sandbox_page, which report that page's line count as `totalLines`. A sandbox can carry dozens of pages and any single one can reach several megabytes, so START HERE before grepping or reading anything — this tool is how you decide WHICH page to look at, not what is on it. THIS LIST IS THE WHOLE WORLD: a page not in it does not exist for a sandbox demo, and a sitemap crawl routinely misses everything behind a login or rendered only after an interaction — so read it as what the demo CAN be about, before committing to a sequence. Read the `sandbox-demos` skill (rendemo_load_craft_skill) now: it covers choosing steps worth taking and elements that survive a rebuild, both of which happen before rendemo_add_sandbox_demo_step. If `demoId` names a codebase-tour project, there are no pages here — use rendemo_get_plan and the customer's own source instead.
args demoId
rendemo_find_in_sandboxRead onlySearch one sandbox page for textGrep ONE sandbox page — get its file name from rendemo_list_sandbox_pages first, this tool does not search across pages. `pattern` is a LITERAL substring, matched case-insensitively, never a regex — paste back text you just read (a button's label, a fragment of an href) without escaping anything. Every hit carries the line it lives at, for a follow-up rendemo_read_sandbox_page call, AND a nodeId: the durable address a sandbox-demo step names as its target. Search always runs over the WHOLE page, never just the default 200-line read window, so this finds text a plain read at the top of the page would miss.
args demoId · page · pattern · limit
rendemo_read_sandbox_pageRead onlyRead a slice of a sandbox pageA bounded, line-numbered view of ONE sandbox page — get its file name from rendemo_list_sandbox_pages first. A captured page can reach several megabytes, so this NEVER returns the whole document: at most 400 lines per call, 200 by default. `offset` is the 1-based line to START AT — 1 shows the top of the document, not the second line. Read `totalLines` back, and if it is bigger than the last line you were shown, call again with `offset` set just past it. Each line is one element's start tag — attrs verbatim — indented by nesting depth, plus that element's own leading text, and carries the nodeId a tour step would target. Prefer rendemo_find_in_sandbox when you already know the text you are looking for; reach for this when you need to see the STRUCTURE around a spot, or are paging through a page you have not looked at yet.
args demoId · page · offset · limit
Sandbox publishing
2 toolsPut a sandbox replica on a public URL, and take it back off — the redaction gate is re-checked server-side every time.
rendemo_publish_sandboxPublish a sandbox to a public URLPut a SANDBOX on the air. This makes the replica WORLD-VISIBLE: anyone with the URL, signed in or not, can browse every page in it. AUTHORING A SANDBOX DEMO DOES NOT NEED THIS — rendemo_list_sandbox_pages, rendemo_find_in_sandbox, rendemo_read_sandbox_page and rendemo_add_sandbox_demo_step all work on an unpublished sandbox, so never publish merely to author or check a demo. Publishing re-verifies server-side that the sandbox's pages are marked redacted, and refuses if they are not — a hard gate with no override. It also draws on the plan's published-artifact budget, which demos, codebase tours and sandboxes share. Returns the public url and the shareable short URL. Reversible with rendemo_unpublish_sandbox.
args demoId · acknowledgeReviewConcerns
rendemo_unpublish_sandboxTake a published sandbox off the airTake a SANDBOX back off the air: its public URL stops serving and the replica becomes visible only to members of the workspace that owns it. Idempotent — running it on a sandbox that is already a draft simply confirms that. Safe by construction (it can only ever expose less, never more), so it needs no redaction re-check. Frees the published-artifact slot the sandbox was holding. Sandbox demos authored from this source remain editable, but their published viewer cannot run until the source sandbox is live again.
args demoId · acknowledgeReviewConcerns
Sandbox promotion
2 toolsReview a re-crawl that was staged because the sandbox was already published, and apply it to the live replica — the one step a human still owns.
rendemo_review_staged_sandboxRead onlyReview a staged re-crawl before promoting itCheck whether a re-crawl is STAGED for a sandbox and read its redaction review. Re-crawling a sandbox that is already PUBLISHED does not replace the live pages — it writes a staged build and leaves the live replica exactly as it was, so a fresh crawl of a site that may have changed cannot go world-visible without a human looking at it first. This tool is how you look. Reports whether a staged build is pending, when it finished, its page count, what the redaction pass found, and any concerns raised. A CLEAN REPORT IS NOT A REVIEW: the detector only flags a person's name when it sits beside a dollar amount, so an all-zeros report routinely rides along with real names still in the pages. Read pages with rendemo_read_sandbox_page, or have a human look, before promoting. Read-only — it changes nothing. Apply the staged build with rendemo_promote_staged_sandbox.
args demoId
rendemo_promote_staged_sandboxApply a staged re-crawl to the live sandboxApply a STAGED re-crawl to the live sandbox: its pages are copied over the live replica and every viewer sees the new crawl from that moment. THIS REPLACES WHAT THE WORLD ALREADY SEES at a public URL, with a fresh recording of a site that may have changed since anyone approved it. Call rendemo_review_staged_sandbox FIRST, and only call this once a human has actually reviewed the staged build — a redaction report with no concerns is not a review, because the detector does not flag a bare personal name at all. `acknowledgeReviewedStagedBuild` must be true and is the claim that this happened. Promotion re-verifies server-side that the staged pages are marked redacted and refuses if they are not — a hard gate with no override. It does not publish or unpublish anything and spends no published-artifact budget: the sandbox was already live, this only changes which build is. NOT REVERSIBLE — the previous build is not kept. Re-crawl to change it again.
args demoId · acknowledgeReviewedStagedBuild
Ship
5 toolsPublishing, offline export, and video renders.
rendemo_publish_demoPublish the demoBuild and publish an interactive demo (recorded or sandbox-backed) and return its public URL. This makes the demo WORLD-VISIBLE — confirm with the user before publishing and before sharing. The same endpoint also publishes codebase tours for compatibility; a codebase tour returns no URL because it runs inside the customer's own product.
args projectId · locale
rendemo_export_offlineRead onlyExport offline demoA time-limited download link for the published demo as one self-contained offline HTML file (replay, styling, interactions and media embedded). Publish first.
args projectId
rendemo_queue_video_renderQueue a video renderRender the project as a video (mp4 or gif) on the render worker. Returns a renderId to poll with rendemo_get_render_status. Takes minutes. `stepMs` sets one flat hold per step for this export only; omit it and each step is held for as long as its own card takes to read, which is usually what you want.
args projectId · name · format · resolution · quality · kind · stepMs
rendemo_get_render_statusRead onlyGet render statusStatus of queued/running renders — pass a renderId, or omit it for the workspace's recent renders.
args renderId · limit
rendemo_republish_allRepublish every live demoRe-bake every PUBLISHED demo in this workspace so they pick up player fixes. The player runtime is baked into each artifact at publish time, so a deployed fix -- a redaction change, corrected copy, an accessibility fix -- is invisible on demos that already exist until they are republished. This is the only bulk path. It never publishes anything that was not already published: it refreshes live artifacts and nothing else. Returns a jobId; poll it with rendemo_get_crawl_status. Pass dryRun to count what would be rebuilt without rebuilding it.
args projectId · dryRun
Video
14 toolsThe cut sheet: shots, zoom, pacing, effects and sound.
rendemo_get_video_planRead onlyRead the video cutThe video output's full cut sheet: every shot (beat) with its timing, zoom depth, transition link, salience, story intent and annotations, plus the plan-level pacing, click effects, sound mix, caption state, trim (in/out) and speed sections — the WHOLE video is viewable here. Read this BEFORE adjusting shots — 'improve the video' means these levers (then rendemo_frame_video_shot / rendemo_set_video_shot / rendemo_add_video_shot / rendemo_split_video_shot / rendemo_delete_video_shot / rendemo_apply_video_treatment / rendemo_tune_video / rendemo_trim_video / rendemo_set_video_speed_section / rendemo_clear_video_sections), not the demo card tools. CRAFT: a polished cut is mostly wide/medium — punch only the 1-2 payoffs, hold shots ~3s, one move per shot, gentle pacing (over-zoom + high maxSpeed is what reads snappy/warpy). Load the video-craft skill with rendemo_load_craft_skill before a real polish pass.
args projectId
rendemo_set_video_shotAdjust one video shotPer-shot video edit — the same operation as the editor's Shot tab: zoom (1 = full frame, up to 4x), center (pan the framing to a content-% point at the current zoom — the same math as the editor's reframe drag), holdFrom/holdTo (retime the shot's hold window, seconds), and enabled (false cuts the shot from the video; the interactive demo is unaffected). Use rendemo_get_video_plan first for shot ids and current values.
args projectId · beatId · zoom · center · holdFrom · holdTo · enabled
rendemo_frame_video_shotFrame a video shot on its recorded elementFrame one video shot on its recorded element — 'wide' (full frame), 'medium' (~1.7x on the element), 'punch' (~3x hero close-up), 'auto' (from salience). Deterministic solver from the captured element box (no vision). Writes beat.crop, the same field the editor's reframe/zoom write.
args projectId · beatId · shot
rendemo_add_video_shotAdd a new video shotInsert a brand-new shot (beat) into the video cut at a point in time — for a moment worth its own hold that the recording didn't naturally break into one. Starts full-frame; pass shot ('wide'/'medium'/'punch'/'auto') to also frame it like rendemo_frame_video_shot would (only takes effect if the moment has a recorded element to frame on). Keeps shots in time order. To break an EXISTING shot into two instead, use rendemo_split_video_shot.
args projectId · atSeconds · holdSeconds · shot
rendemo_split_video_shotSplit a video shot into twoBreak one shot's hold window into two independent shots at a point in time — the same operation as dragging a split on the timeline. Both halves keep the original shot's framing/annotations until you adjust them separately. Fails if the split point would leave either side shorter than 0.3s.
args projectId · beatId · atSeconds
rendemo_delete_video_shotDelete a video shotHARD-remove a shot (beat) from the video cut — it's gone from the plan entirely. Contrast with rendemo_set_video_shot enabled:false, which cuts a shot from the video but keeps it (restorable by re-enabling). Fails if it's the only shot left, or the id doesn't exist.
args projectId · beatId
rendemo_tune_videoTune video pacing, effects, cursor & soundPlan-level video feel: pacing (tight time-warp with a max speed, or off for real time), click effects (style/intensity/zoom-punch, plus motionBlur — physically-correct camera motion blur on fast moves, final renders only), cursor styling (trail: 'comet' is the signature accent-glow ribbon that lights up on ordinary mouse travel; 'subtle'/'strong' only fire on fast flicks; 'off' disables), and the sound mix (clicks, whoosh, background music level, narration cleanup). Only passed fields change.
args projectId · pacing · effects · cursor · sound
rendemo_trim_videoTrim the video's in/out pointsSet the video's start/end trim — RAW footage seconds (the same clock plan.sections use), not the trimmed/output timeline. Cuts everything before the start point and after the end point. Only passed fields change (start or end alone shifts just that edge); the other edge is clamped so start stays before end. Use rendemo_get_video_plan's settings.trim for current values.
args projectId · startSeconds · endSeconds
rendemo_set_video_speed_sectionSet a speed/cut section on the videoAdd a rate-override window to the video cut — RAW footage seconds (add plan.trim.start to convert from the trimmed/output timeline). speed >= 50 EXCISES the range (a hard cut, like deleting dead time); speed < 1 is slow-mo (e.g. 0.5 = half speed); speed > 1 (and < 50) speeds the range up (e.g. 4 = 4x). Sections stack — adds a new entry to plan.sections, it does not replace existing ones. Use rendemo_get_video_plan's settings.sections for current values, rendemo_clear_video_sections to remove one.
args projectId · startSeconds · endSeconds · speed
rendemo_clear_video_sectionsRemove video speed/cut sectionsRemove one speed/cut section by index (pass index) or ALL sections (omit index). Use rendemo_get_video_plan's settings.sections to find indices.
args projectId · index
rendemo_apply_video_treatmentApply a video treatment (one-move polish)One move to set a coherent, professional feel across the whole cut — the fix for a snappy/over-zoomed/warpy video. 'calm'/'professional': gentle pacing (max 4x), subtle glow effects, camera motion blur on fast moves, quiet sound, AND pulls every over-zoomed shot (zoom > 2) back to a calm medium framing. 'dynamic': punchier pacing + effects + motion blur (leaves your shots alone). 'minimal': real-time pacing, no effects, resets ALL shots to full frame — and resets effects to their defaults, INCLUDING clearing an explicit motionBlur:false. An explicit effects.motionBlur:false set via rendemo_tune_video survives 'calm'/'professional'/'dynamic', but 'minimal' wipes the slate and a LATER treatment re-applies its own mix (blur back on) — re-set motionBlur:false after it if you want blur kept off. After a treatment, selectively rendemo_frame_video_shot 'punch' the 1-2 real payoff moments.
args projectId · treatment
rendemo_set_video_captionsToggle & style video captionsBurned captions on the video, auto-transcribed from the narration (the TEXT comes from the voiceover — this controls whether they show and how they look). enabled on/off; style subtitle (clean line) or pill (rounded chip); size; position top/bottom; karaoke word-highlight. Only passed fields change. One idea per moment — keep them on the payoff, not every shot.
args projectId · enabled · style · size · position · karaoke
rendemo_annotate_shotAdd an annotation to a video shotDraw a callout / feature / box / ellipse / arrow / line / spotlight on one shot — it shows in the video (and demo) for that beat's duration. rect is a content-% box (x,y,w,h in 0-100, the same space as the shot framing). 'callout' shows text with an optional leader line to `target`; 'feature' is a designed b-roll card (bold title + optional `body` line, accent bar) anchored at the rect — the pro way to name a feature on screen; 'spotlight' dims everything outside the rect; box/ellipse outline the rect; arrow/line point across the rect's diagonal. One idea per moment — use on the payoff, not every shot.
args projectId · beatId · type · rect · text · body · target · color · anim · pulse
rendemo_clear_shot_annotationsRemove annotations from a video shotRemove one annotation (pass annotationId) or all annotations from a shot. Use rendemo_get_video_plan / the editor to find ids.
args projectId · beatId · annotationId
Directing
4 toolsCamera and card geometry, solved from the captured element boxes — no screenshots.
rendemo_direct_stepDirect one step (camera + card)Set the camera shot and card position for one interactive-demo step. shot: 'wide' (full frame), 'medium' (~1.7x frame on the target), 'punch' (~3x hero close-up), 'auto' (from the step's recorded salience). cardAnchor: a corner/center, or 'auto' to place the card beside the highlighted element without covering it. The deterministic solver computes exact geometry from the captured element box — results land in the same fields the editor's drag/zoom controls use, so the author can adjust by hand afterwards.
args projectId · stepId · shot · cardAnchor · settleShot · moveDelayMs · moveDurationMs · device
rendemo_auto_directAuto-direct the whole demoOne deterministic directing pass over every visible step: hero moments (high recorded salience) get a punch-in, ordinary actions a medium frame, and every card is placed beside its target instead of on top of it. Steps where the author hand-placed the card or hand-zoomed are left alone unless force=true. Run rendemo_director_lint afterwards to verify. Cheap by construction — pure geometry, no model calls.
args projectId · force · cameraMoves · device · preview
rendemo_director_lintRead onlyLint the demo's directionZero-cost audit of a demo's direction AND its content, PLUS the resolved choreography of every step — whether it holds still or moves, both framings of each move, and why a move was dropped. GEOMETRY: cards covering their own target, crops that cut off the highlighted element, off-stage cards, disorienting zoom depths, long copy over tight shots. CONTENT: a CTA wired to nothing, an emphasis colour no viewer can see, placeholder copy, internal hostnames, card imagery with no alt text, an unused brand, and orphaned or dangling steps in a branching demo. Two rules block (a dead CTA and an invisible mark); the rest are warnings. Run after directing or copy changes. THIS IS GEOMETRY, NOT LEGIBILITY: it passes while a card is unreadable over a busy region or covers the very element it points at, because it never sees the demo. To actually LOOK at it, publish and call rendemo_review_demo_frames, which returns real screenshots of each step.
args projectId
rendemo_set_demo_pointerSet the demo pointer and its clickThe pointer a viewer sees and the click it performs. `cursor` draws the recorded pointer between steps, or removes it. `clickCue` decides whether the pointer glides onto each action step's target and presses it just before the demo moves on — the guided-action half, and the thing that reads as a product demo rather than a slideshow. `effect` is what that click LOOKS like and is SHARED WITH THE RENDERED VIDEO, so one word means one gesture in both: press (the ring closes on the point and brightens -- the quietest, and the shape the strongest cursor in the surveyed market uses), ring (a ring out from the point), burst (dots thrown outward, the loudest), glow (the target blooms, plus the ring), highlight (the target fills briefly), none. `tone` is dark by default because a pointer lives over a product and products are light — invert it only for a mostly-dark one. `scale` sizes the arrow and its ring together.
args projectId · cursor · clickCue · effect · tone · scale
Cinematic
8 toolsCarried by the registry and served by the endpoint; not written up in docs/mcp/README.md.
rendemo_set_title_cardSet the branded title cardSet the full-frame intro card the film opens on (a themed backdrop + headline over the brand accent). Keep the headline short — a title, not a sentence (the product/feature name). Only passed fields change; pass remove:true to drop the title card. Cards render on the worker (already live for intro/end). The SAME card can open the interactive demo as a standalone welcome cover: pass showInDemo:true (plan.demoCover) and, optionally, buttonLabel for its start action.
args projectId · text · subtitle · buttonLabel · showInDemo · seconds · remove
rendemo_set_end_cardSet the end / call-to-action cardSet the full-frame outro card the film ends on — the call to action (e.g. 'Start free', 'Book a demo'). Short headline; optional subtitle (a URL or tagline); and `href`, where the button actually SENDS a convinced viewer. Without an href the demo ends on Replay and the publish gate says so, so set it whenever the card is a real call to action. Only passed fields change; remove:true drops it. Renders on the worker (live today).
args projectId · text · subtitle · href · remove
rendemo_add_interludeAdd a section interlude (chapter) cardInsert a full-frame chapter SLIDE — a slideshow-style interrupt that titles the next part ('Connect your data', 'Invite the team'). atSection is the chapter index (0-based, in the order the film's establishing/wide shots open each chapter); the slide renders just before that chapter. NOTE: by default chapters are already marked by animated on-screen titles over the footage (the produced-film look) with no slides — use this only when you deliberately want the full-frame slideshow treatment instead.
args projectId · text · subtitle · atSection
rendemo_clear_interludesRemove interlude cardsRemove section interlude (chapter) cards — all of them, or only those at a given atSection index.
args projectId · atSection
rendemo_set_bgmSet the background-music bedControl the background-music bed under the film. enabled toggles it; mood is a text query the worker uses to retrieve a fitting catalog track when none is uploaded (e.g. 'soft minimal tech corporate', 'upbeat energetic', 'calm ambient'); volume 0..1 is the bed level under the narration (default 0.12 — keep it low so voice/UI stay legible). An uploaded track always wins over mood.
args projectId · enabled · mood · volume
rendemo_generate_narrationWrite the story layer (intents + on-screen chapter titles)Run the deterministic story pass over the cut: assign each shot a story intent (hook/establish/action/detail/payoff/breather — this also tells the camera which shots should breathe) and enable captions. Chapters are marked by animated on-screen section titles over the footage automatically (from the establishing shots) — the produced-film look — so you do NOT need chapter cards for that. Set addChapters:true only if you specifically want full-frame interlude slides (a slideshow-style interrupt) instead. Never overwrites shots/cards you've hand-edited. A good first move on a raw capture before fine-tuning.
args projectId · addChapters
rendemo_set_section_transitionSet the section transitionSet the transition played at each chapter (establishing/wide shot): 'wipe' (an accent band sweeps across — the tasteful default), 'push' (a bolder accent sweep), 'fade' (a quick dip to accent), or 'none'. Renders in the video and the preview.
args projectId · style
rendemo_cinematic_polishMake the VIDEO look professional (one move)THIS IS A VIDEO-CUT VERB AND IT TOUCHES NOTHING A DEMO VIEWER SEES — it shapes the rendered MP4 only, so do not reach for it when asked to polish, improve or fix the INTERACTIVE demo (that is rendemo_style_steps, rendemo_update_step and rendemo_auto_direct). The 'make it a produced film' verb: seeds a branded title + end card when missing, turns on the background-music bed, enables burned captions, and sets a restrained, premium mix (clean click ripple, tight pacing, no over-production; an explicit effects.motionBlur:false is respected). Camera motion blur on fast moves is part of the mix for MOTION-engine renders only — a plan on the 'cinematic' engine locks its master camera, so the flag is stored but adds no blur there. Ken-Burns push on establishing/wide shots is automatic, and chapters are marked by animated on-screen titles over the footage (no slideshow). Non-destructive: it won't overwrite cards you already set unless force:true. Follow with rendemo_queue_video_render to see it (only add rendemo_add_interlude if you specifically want full-frame chapter slides).
args projectId · force · preview
Brand style
7 toolsCarried by the registry and served by the endpoint; not written up in docs/mcp/README.md.
rendemo_get_video_styleRead onlyGet the brand video styleRead the on-brand kinetic-text style for auto section titles/feature callouts/cards: both the plan's raw overrides (videoStyle) and the fully resolved style (defaults + theme accent filled in). Use before rendemo_set_video_style to see what's currently in effect.
args projectId
rendemo_set_video_styleSet the brand video styleSet on-brand kinetic-text style fields for auto section titles/feature callouts/cards — type (font/case/tracking), color (accent role/ink/scrim), motion (preset/duration/ease/stagger/direction/mask), layout (text position/card look), and per-kind variants (sectionTitle/featureCallout/stat). Deep-merges per nested field — only the fields you pass change; siblings you leave out are preserved. Use rendemo_get_video_style first to see current values, or rendemo_apply_motion_preset for a quick motion-only change.
args projectId · type · color · motion · layout · variants
rendemo_apply_motion_presetApply a motion preset to the video styleQuick way to switch the kinetic-text entrance motion: 'reveal', 'rise' (default — the safe premium choice), 'draw', 'type', or 'fade'. Set resetParams:true to also clear any custom duration/ease/stagger/direction/mask overrides so the preset's own defaults take over.
args projectId · preset · resetParams
rendemo_design_brand_styleAuto-design the on-brand video style from the brand kitAsks an LLM to propose a complete on-brand kinetic-text style (type/color/motion/layout) from the project's brand kit (accent + heading/body fonts) — a one-shot 'design my style' instead of setting each field by hand. Deep-merges the result into plan.videoStyle: by default the author's existing overrides win over the new design (only unset fields get filled in); pass force:true to let the new design override existing fields too. Pass saveAsDefault:true to also make this the WORKSPACE default (see rendemo_save_brand_style_default) so future projects inherit it. Falls back to a deterministic template style if no AI key is configured. Use rendemo_get_video_style afterward to see the resolved result, or rendemo_set_video_style/rendemo_apply_motion_preset to hand-tune it further.
args projectId · hint · force · saveAsDefault
rendemo_save_brand_style_defaultSave the current video style as the workspace defaultSaves THIS project's current plan.videoStyle overrides as the workspace-wide default on-brand kinetic-text style. Future projects in this workspace inherit it automatically when their plan is first built (as long as they don't already carry their own overrides); existing projects can pick it up with rendemo_apply_brand_style_default. Use rendemo_get_brand_style_default to see what's currently saved, or rendemo_design_brand_style with saveAsDefault:true to design and save in one step.
args projectId
rendemo_get_brand_style_defaultRead onlyGet the workspace default video styleRead this workspace's saved default on-brand kinetic-text style (set via rendemo_save_brand_style_default or rendemo_design_brand_style saveAsDefault:true) — the style new projects inherit and rendemo_apply_brand_style_default applies to an existing one. Returns null when nothing has been saved yet.
rendemo_apply_brand_style_defaultApply the workspace default video style to this projectMerges this workspace's saved default video style into THIS project's plan.videoStyle. By default the project's existing overrides win (only fields the project hasn't set are filled in from the default) — pass force:true to let the default win instead, overriding fields the project already set. Fails with a clear message if no workspace default has been saved yet (see rendemo_save_brand_style_default).
args projectId · force
Crawl
2 toolsMass-produce sandboxes from public sites with headless Chrome, no manual recording.
rendemo_crawl_siteCrawl a public site into a sandboxCrawl a site's PUBLIC pages (via sitemap.xml) with headless Chrome and build a Rendemo sandbox from it. THIS IS THE WEAKEST OF THE THREE CAPTURE ROUTES and the right one only when the demo genuinely IS a public website. BEFORE CALLING, ASK TWO QUESTIONS. Is this a product? Then the user should RECORD it with the Rendemo Chrome extension ('Record this tab', then 'Stop' and 'Send to Rendemo') — that captures real interaction and real data instead of a static replica of what a stranger's bot can fetch, and auto-direction runs on upload; see the `new-demo` skill. And must the demo show anything behind a login (their dashboard, their account, their data)? Users rarely volunteer this, and the public marketing site is rarely what they meant — if yes or unsure, use rendemo_start_browser_crawl instead, which handles signed-in capture through the user's own browser. Having no browser tools of your own is NOT a reason to prefer this tool: the user has a browser and drives all three routes. Returns a job id: poll it with rendemo_get_crawl_status, which reports the crawl AND the sandbox build that is chained behind it automatically. This is SLOW — a crawl typically takes a few minutes (40 pages took 239 seconds in production) and the sandbox build takes several more — so poll every 15-30 seconds and trust the tool's elapsedSeconds rather than your own sense of time. Pass projectId to RE-crawl an existing crawl-sourced project, which keeps its sandbox id and slug so already-authored demos keep working. Pass urls to name the exact pages to visit — that SKIPS sitemap discovery entirely — but it still fetches anonymously, so pages behind a login come back as sign-in screens. FOR SIGNED-IN PAGES use rendemo_start_browser_crawl instead — it works even with no browser tools of your own (the user captures pages with the Rendemo extension via a capture code). The url you pass is always visited too, path and all. The resulting sandbox is NOT published: publishing stays a separate, deliberate step. IF THIS CRAWL WILL BECOME A SANDBOX DEMO, read the `sandbox-demos` skill (rendemo_load_craft_skill) while it runs — a sandbox demo writes no markers into customer source and is not a codebase tour.
args url · urls · maxPages · include · exclude · projectId · viewport
rendemo_set_redaction_kindsSet which PII kinds redaction scans forChoose which kinds of PII the redaction pass removes from this project's replica and its published artifact. Default (no call needed): email, phone, creditCard, ssn, moneyName, secret and handle. The one worth deciding is personName: it catches a bare Titlecase name -- the account holder's name in a sidebar, which every other detector misses -- but it matches ANY two Titlecase words, so on a product with lots of Titlecase UI copy it also flags nav labels, button text and feature names. Turn it on when a capture shows real people's names, then re-crawl and read the review. Takes effect on the NEXT build: a replica already extracted was scrubbed with whatever was set at the time.
args projectId · kinds
Seed data
2 toolsFind the real names, handles, emails and photos still visible in a recording, and replace them with a consistent, plausible persona per region before you publish.
rendemo_find_real_dataRead onlyFind real data still in this demoRead-only. Sweeps the recording for real data a viewer would see -- people's names, handles, emails, and the image sources next to them -- and reports them CLUSTERED BY REGION rather than as loose hits, with up to 3 samples and a count for each (never the full list of real values -- this tool is not a place to bulk-read a customer's data). This is what to call before publishing anything built from a real account: a lead list, an inbox, a CRM screen. Pair with rendemo_seed_data to replace what it finds -- pass the SAME path back with a type: a `personName` cluster seeds as type:"person", `imageSrc` (reported here as photographs) seeds as type:"avatar", and `handle`/`email` keep their own name -- the two tools' vocabularies differ only for those two kinds. If the recording is large, the sweep can stop early -- the result's `capped` flag and its own text say so plainly when it happens, because a partial sweep that reads as complete is exactly the failure this feature exists to prevent: a region past the cap having no finding is NOT evidence it is clean.
args projectId
rendemo_seed_dataSeed fake data over a regionReplace the real data in a region with plausible fake data, by pointing a TYPE at a path from rendemo_find_real_data. COPY THAT PATH EXACTLY -- they are long, and a rule whose path does not match a region replaces nothing at all; publishing now warns when a rule matches nothing, but a mistyped path is silent until then. Rules bind to a REGION (a structural path), not to the literal strings -- more durable than a find/replace list, but NOT immune to a re-record: a reordered wrapper or a renamed class can move the region the path names, and unlike a tour marker there is no automatic remap for a seed rule. After a re-record, call rendemo_find_real_data again to confirm each rule's path still covers what it used to -- a drifted path simply reappears as a fresh uncovered cluster, but only if you check for it. The same real value always becomes the same persona, so one person reads consistently across every step. Pass enabled:false to say 'that region is product copy, leave it' -- which also silences the publish advisory for it, instead of it being re-proposed on every sweep. `type` is usually whatever rendemo_find_real_data reported at that path, but a rule set BY HAND works with no matching finding at all: a rule replaces every text value at the path it names, whether or not a detector reported anything there. type:"company" needs this -- there is no detector for an employer name, so a column of company names never surfaces as a cluster on its own, and an author who can see one (a CRM's 'Company' column, an account list) should seed it anyway. The flip side: a path that also holds product copy has that copy replaced too, so name the cell, not its container. Add/update rules with `rules` (matched and replaced by label, so calling again with the same label updates it rather than duplicating it); delete rules with `remove` (labels). Republish to ship the change -- an already-built artifact keeps whatever it was baked with.
args projectId · rules · remove
Browser-driven crawling
3 toolsCapture a site into a sandbox by driving a signed-in browser yourself, for pages a headless crawl cannot reach.
rendemo_start_browser_crawlStart a browser-driven crawlCapture signed-in, click-gated or robots-disallowed pages into a sandbox — the cases the headless rendemo_crawl_site cannot reach. FIRST CHECK WHETHER A RECORDING IS POSSIBLE: if the user can walk through the product themselves, the Rendemo Chrome extension's 'Record this tab' (then 'Stop' and 'Send to Rendemo') captures real interaction and real data rather than the page-at-a-time snapshots this tool collects, and queues auto-direction on upload — see the `new-demo` skill. Use this when a recording is not on the table but the pages need a login. CALL THIS EVEN IF YOU HAVE NO BROWSER CONTROL: lacking browser tools does NOT make this impossible, and no cloud/hosted browser is needed or usable. Two ways the pages get captured, both through this same tool: 1. NO BROWSER TOOLS (ChatGPT and most clients): call this, then give the USER the capture code from the result. They paste it into the Rendemo Chrome extension's 'Capture pages for a sandbox' popup mode, signed in on the site — and from that moment YOU capture the pages: rendemo_capture_pages({ crawlId, url, urls }) opens each url in their signed-in tab and captures it, no clicking on their side. When the sandbox has what it needs, call rendemo_finish_browser_crawl. 2. YOU DRIVE A BROWSER THE AUTHOR IS ALREADY SIGNED INTO — their real, local browser with their sessions. A CLOUD OR HOSTED BROWSER YOU OPENED YOURSELF DOES NOT QUALIFY: it holds none of the author's sessions and providers like Google refuse sign-ins from automated browsers, so never ask the author to log in inside one — use path 1 instead. Per page: navigate, WAIT for it to finish rendering (the recorder snapshots the instant it arms; armed too early, the page is captured as an empty shell and discarded as a duplicate), then evaluate `snippet` with that page's index. The page uploads itself and returns a receipt; finish when every page posted. No credential ever reaches Rendemo on either path. Returns a crawl id, a short-lived ingest token, the capture code, and the `snippet`. IF THIS CRAWL WILL BECOME A SANDBOX DEMO, read the `sandbox-demos` skill (rendemo_load_craft_skill) while you go.
args url · urls · projectId
rendemo_finish_browser_crawlFinish a browser-driven crawlClose a browser crawl started with rendemo_start_browser_crawl and queue the sandbox build from the pages you posted. Returns a job id — poll it with rendemo_get_crawl_status exactly as you would a headless crawl; the build is the same one, and it is chained automatically. Pass pagesCaptured so a page that failed to upload is reported rather than silently missing from the sandbox. The count is CHECKED against what reached storage before anything is queued: if nothing landed this refuses, and it never confirms a number it has not verified.
args crawlId · url · pagesCaptured · projectId
rendemo_capture_pagesCapture pages through the user's extensionCapture named pages of a signed-in product into a browser crawl WITHOUT the user clicking per page. Requires a crawl from rendemo_start_browser_crawl whose capture code the user has pasted into the Rendemo Chrome extension: from then on the extension opens each url you pass in their signed-in tab, captures it, and reports back. Pass full urls on the crawl's origin; logout/delete-shaped paths are refused, and a page that lands on a login wall is refused and named rather than captured. HOLDS THE CONNECTION OPEN (default 90s) while pages are captured and returns per-url results plus whether the extension has joined at all — the difference between 'nobody pasted the code' and 'working'. If pages are still in flight when it returns, CALL IT AGAIN WITH NO urls — that is not a stopping point. Then rendemo_finish_browser_crawl. The user can still click 'Capture this page' for pages you cannot name; rendemo_watch_captures counts everything that reached storage either way.
args crawlId · url · urls · waitSeconds
Drive & record
5 toolsRehearse a workflow unrecorded on the user's own signed-in tab, propose it as a plan they approve, then record that plan as one clean take that auto-directs into a demo — no free-roam replica to leak, for a product too data-dense for a public sandbox.
rendemo_start_drive_sessionStart an agent-driven recording session (rehearsal first)Open a session in which YOU drive the user's signed-in tab. It starts in REHEARSAL: nothing is recorded while you explore with rendemo_drive — read pages, try paths, fail and retry — until you know the way to the outcome. Then rendemo_propose_drive_plan writes the take as a numbered plan the user approves in chat, and rendemo_record_drive_plan records exactly that plan in one clean pass after they click 'Record the plan'. The result is a REAL take (real clicks, typing, transitions) that auto-directs into a demo with no free-roam replica to leak — prefer this over rendemo_capture_pages for a product whose screens are full of other people's data. Returns a session id and a code; give the user the paste steps verbatim.
args url
rendemo_drivePerform one rehearsal action in the driven tabRun ONE action in the user's signed-in tab of an open drive session and get back what the page looks like afterward, so you can choose the next one. This is REHEARSAL: nothing is recorded, so explore, backtrack and retry freely. Actions: navigate (same origin only; logout/delete paths refused), click (by selector or visible text; a destructive-looking target is refused), type (into a field; never a password), scroll, read (a compact page outline), wait. Start with read. It HOLDS THE CONNECTION OPEN until the extension has run the action; if it says the session has not started, the user has not pasted the code yet — the action waits for that. When you know the path, stop driving and rendemo_propose_drive_plan.
args sessionId · url · action · waitSeconds
rendemo_propose_drive_planPropose the take as a plan for the user to approveAfter rehearsing, write the take: an ordered list of VISIBLE steps (navigate, click, type, scroll, wait — never read) along one path to the outcome, each with a one-sentence purpose that says what the viewer learns. Five to ten steps. Every step passes the same safety gate as a live action, and the extension stores the plan so its popup can show 'Record the plan'. Returns the plan rendered as a numbered list: SHOW IT TO THE USER and ask them to approve or change it before you record anything. Propose again to replace it. Then rendemo_record_drive_plan.
args sessionId · url · title · steps
rendemo_record_drive_planRecord the approved plan as one clean takeQueue the approved plan for recording. The user clicks 'Record the plan' in the extension popup (Chrome needs their click to start the tab recorder); the extension then executes the steps back-to-back with a short settle after each, stops, and uploads the take, which auto-directs like a hand recording. Call this only after the user approved the plan. It HOLDS OPEN until the take is done; if it comes back still recording or waiting for the click, call it again — not a stopping point. When it reports done, rendemo_watch_captures (no crawlId) picks up the project.
args sessionId · url · waitSeconds
rendemo_finish_drive_sessionEnd the drive sessionClose a drive session: cancel anything still queued and tell the extension to end it — if a take is rolling it stops and uploads (auto-directing like a hand recording); if it was only rehearsing, the session simply ends. You do not need this after rendemo_record_drive_plan, which stops the take itself. Use it to abandon a rehearsal or to stop a take early. Then rendemo_watch_captures if anything was recorded.
args sessionId
Crawl status
1 toolFollow a queued crawl and the sandbox build it chains — progress, phase, elapsed time, and what to do next.
rendemo_get_crawl_statusRead onlyGet crawl statusStatus of a crawl queued with rendemo_crawl_site, and of the sandbox build it chains. THIS TOOL WAITS: it holds the connection open (30s by default, up to 120) and returns when the state actually moves, so one call covers what used to take several. It reports the crawl's progress and phase, an authoritative server-computed elapsedSeconds, then the sandbox job and demo id once the crawl finishes, plus authenticated (whether a shared session was used) and walledPages (urls dropped as login walls), and a nextStep saying plainly what to do now. IF IT COMES BACK STILL RUNNING, CALL IT AGAIN IMMEDIATELY with the same jobId — that is not a stopping point and not something to report to the user. Ending your turn there abandons the crawl: nothing resumes it, and the person is left waiting for a result that already arrived. A crawl typically takes a few minutes (40 pages took 239 seconds in production) and the sandbox build takes several more, so expect a handful of calls.
args jobId · waitSeconds
Waiting for a capture
1 toolHold the connection open until the person you asked to record has finished, so waiting is a tool call rather than a turn that ends.
rendemo_watch_capturesRead onlyWait for a recording to arriveWAIT for the user to finish recording their product with the Rendemo extension, then report the project it became and whether the story director has finished with it. Call this immediately after telling someone to record — it HOLDS THE CONNECTION OPEN (up to 120s per call, 60 by default) and returns the moment something lands, so you do not need the user to tell you they are done and must not ask them to. IF IT RETURNS NOTHING YET, CALL IT AGAIN IMMEDIATELY with the sinceIso it gives back: that is not a stopping point and not something to report to the user. Ending your turn there strands them — a chat has no timer, so nothing resumes the wait, and the recording they just made is never picked up. It watches for HUMAN recordings only (browser extension and desktop recorder); seeded sample projects and crawl-built projects are excluded, so a crawl you started yourself will not end the watch — poll that with rendemo_get_crawl_status. Pass projectId to wait on the direction of a recording that has already arrived. Pass crawlId instead to watch a CAPTURE-CODE session from rendemo_start_browser_crawl: it reports how many pages have really reached storage, which is how you catch a code that was never pasted on page one instead of discovering at finish that nothing arrived. Read the `new-demo` skill for what to do with it once it does.
args sinceIso · waitSeconds · projectId · crawlId · havePages
Looking at the demo
1 toolPhotograph the published demo step by step and hand the pictures to the agent — the only check that sees an unreadable card, a card covering its own target, or emphasis that renders invisibly.
rendemo_review_demo_framesRead onlyPhotograph the published demo and look at itSEE what a viewer sees. Opens the PUBLISHED demo at each step, waits for the card to finish arriving, and returns real screenshots as images you can look at — then fix what is actually wrong and republish. This is the only check that can catch an unreadable card, a card covering its own target, or emphasis that renders invisibly: rendemo_director_lint reads geometry and passes on all three, and rendemo_render_step_card draws the card over a stand-in shell rather than the real screen. Photographs up to 6 steps per call — pass steps to choose which, and call again for the rest. IT WAITS (up to 120s) while the worker drives a real browser; if it comes back still running, call it again immediately with the jobId it gives you and do not end your turn. Requires the demo to be published, because it photographs the real artifact at its real URL; publish first, review, fix, and republish — republishing keeps the same link.
args projectId · steps · device · jobId · waitSeconds
When it does not work
The published CLI can lag the documented one
This repository’s CLI source declares 0.5.0, but npm view rendemo version returned 0.2.0 on 2026-07-26. Because npx rendemo … fetches whatever the registry serves as latest, some commands may not exist yet on your machine even though they are documented here. A cache holding a version too old exits 2 with Unknown command "…".
Check with npx rendemo --version before assuming a command is broken. Until the newer version is published, supply the token with RENDEMO_API_TOKEN — that path never needed the CLI.
- Is the server connected? Run
/mcp. If no credential was produced the server is still listed, but every call fails to authenticate — that is what a 401 from these tools means. - Signed in, still 401? That is the gap
doctor’s MCP headers line exists for: it runs the helper command the config declares, inside the same 10-second budget Claude Code allows, and validates the output the way Claude Code does. could not determine executable to run— your project’s ownpackage.jsonis namedrendemo, sonpxresolves it first. Rename it, or install the CLI as a devDependency and call./node_modules/.bin/rendemo.- Wrong workspace. Every tool is scoped to the token’s workspace, so switching workspaces means switching tokens.