pepita

Developer tools

Drive your site from Claude, or the terminal.

pepita is a website builder for people who'd rather not build a website. These two doors do the same things the editor does — read files, make edits, publish, and spin up shareable preview links — without opening it. Same account, same sites, no new passwords.

claude — pepita connector

you › List my pepita sites, then read index.html on my-landing.

→ 3 sites. my-landing/index.html (52 KB), styles.css, …

you › Change the hero headline to "Roofing done right".

→ wrote index.html

you › Give me a preview link I can send my client.

→ preview ready → my-landing--a1b2.pepita.page

you › Looks good — publish it.

✓ published → my-landing.pepita.page

Claude connector · MCP

The Claude connector

Connect pepita to Claude (Claude Code, Claude Desktop, or the MCP Inspector) and edit your sites in plain language. Fifteen tools — create new sites, read them, edit and publish them, manage shareable preview links, and reach the videos pepita hosts for you. Edits show up live in the pepita web editor too, so you can move between the chat and the visual editor mid-task.

Tools

list_sitesread
Your sites and their live URLs. The entry point — every other tool needs a slug from here.
create_sitewrites
argsname · allow_embedding? · block_ai_crawlers?
Create a brand-new site — it goes live right away with starter content, ready to shape with write_site_file. Embedding by other sites starts off and AI-crawler visibility on; allow_embedding and block_ai_crawlers flip those, and both are changeable later in the editor's settings.
get_statusread
argsslug
One site at a glance: whether it has unpublished changes, its live URL, and its active preview links.
list_site_filesread
argsslug · state? · preview?
The file tree — the working copy by default, or the live site, or a specific preview.
read_site_fileread
argsslug · path · state? · preview?
One file's contents — from the working copy, the live site, or a preview. Returns a content sha so a later write can catch conflicts.
write_site_filewrites
argsslug · path · content
Create a file, or replace one whole. Writes to the working copy — nothing is public until you publish or push it to a preview.
publishwrites
argsslug
Put the current working copy live at <slug>.pepita.page (and any custom domain).
create_previewwrites
argsslug
Freeze the current site as a new shareable preview link — a stable URL you can send to anyone.
update_previewwrites
argsslug · name
Push the current site onto an existing preview link, so its URL now shows your latest changes.
list_previewsread
argsslug
A site's active preview links, with their names and URLs.
delete_previewwrites
argsslug · name
Stop serving a preview link. The version itself is kept — restorable later from the editor's History.
list_video_assetsread
argsslug
The videos pepita hosts for a site — each with its streaming (HLS) URL and poster image. Videos live outside the file tree, so this is how you find them.
get_video_asset_original_urlread
argsslug · id
A temporary download link to a hosted video's original upload (the file you sent, before streaming prep).
rename_assetwrites
argsslug · id · new_name
Rename a hosted asset. Label only — its URLs never change, so pages that reference it keep working.
delete_video_assetwrites
argsslug · id
Remove a hosted video for good, along with its streaming files and poster.

Every tool takes the site's slug — get it from list_sites. In a signature, ? marks an optional argument. The file-reading tools also accept a state — unsaved (the working copy, the default) or live (the published site) — or a preview name from list_previews, to look at a shared version instead.

Videos live in pepita's hosting, not your files. A video is far too big to sit in a site's file tree, so it never goes through read_site_file / write_site_file. You upload one with the CLI's pepita asset add (below); the connector then lists what's hosted and hands back the streaming URL you reference in your markup.
What it can't do, on purpose. Custom domains, team management, billing, and deleting a site stay in the editor — where their confirmations live. The connector can only do what you can do, on your own sites.

Connect it

Two ways in. The remote connector is hosted — nothing to install, just sign in with your pepita account. The local server runs on your machine and works with any MCP client. It's also listed in the MCP Registry as dev.pepita.mcp/mcp — if your client browses the registry, search for pepita and add it there; otherwise pick the remote or local setup below.

remote — OAuth (recommended)

# Claude Code — add the hosted connector; sign in on first use

$ claude mcp add --transport http pepita https://mcp.pepita.dev/mcp

# Claude Desktop / claude.ai → Settings → Connectors →

# Add custom connector → https://mcp.pepita.dev/mcp

local — stdio

# 1. authorize this device once (opens the browser)

$ npx @pepitahq/cli login

# 2. add the local connector to Claude Code

$ claude mcp add pepita-local -- npx -y @pepitahq/mcp

Try these

List my pepita sites and show me the files in <slug>.

On <slug>, rewrite the About section to be warmer.

Give me a shareable preview link for <slug> to send my client.

What videos are hosted on <slug>? Put the intro clip at the top of the home page.

Publish <slug> to the live site.

Command line · CLI

The command line

@pepitahq/cli pulls a site to your machine, lets you edit it with your own tools, and pushes it back — authenticated the way wrangler or gh do it: a browser sign-in, no pasted API key.

Install & sign in

terminal

$ npm install -g @pepitahq/cli

$ pepita login

→ authorized as you@example.com

Commands

pepita list
Your sites and their live URLs.
pepita create
args<name> · --allow-embedding · --block-ai-crawlers · --from <dir>
Create a new site — live right away with starter content. --from <dir> seeds it from a local folder instead of the blank starter; --allow-embedding lets other sites embed it (off by default) and --block-ai-crawlers asks AI crawlers to stay away (they're welcome by default).
pepita pull
args<slug> · --live · --preview <name> · --dir <path>
Download a site's files into --dir (default ./<slug>). Pulls the working copy unless you pass --live (the published site) or --preview <name>.
pepita apply
args<slug> · --dir <path> · --yes
Upload local changes from --dir (default ./<slug>) into the working copy. Shows a plan and asks first; --yes skips the prompt.
pepita preview
args<slug> · --update <name> · --delete <name>
With no flag: freeze the current site as a new shareable link. --update <name> pushes the current site onto an existing link; --delete <name> stops serving one (restorable from History).
pepita previews
args<slug>
List a site's active preview links.
pepita publish
args<slug>
Put the current working copy live.
pepita status
argsslug?
On its own: your balance — and what it buys in video minutes — plus every site's URL. With a slug: that site's pending changes.
pepita delete
args<slug> · --download-snapshot · --yes
Permanently delete a site. --download-snapshot saves a copy to /tmp first; --yes skips the confirmation.
pepita whoami
Show who you're signed in as.
pepita logout
Sign out — revokes this device's access.

Hosted videos — pepita asset

Videos are hosted outside your files (see Add a video below). Every asset subcommand needs --site <slug> to say which site it belongs to.

pepita asset add
args<file> · --site <slug>
Upload a video. pepita hosts it, prepares it to stream on any device, and returns a URL for your markup. Charged at 60¢ per source-minute when the upload lands.
pepita asset list
args--site <slug>
The videos hosted on a site, with their ids and status.
pepita asset info
args<id> · --site <slug>
One hosted video's details — duration, size, dimensions, and its streaming and poster URLs.
pepita asset rename
args<id> <new name> · --site <slug>
Rename a hosted asset. Label only — its URLs never change, so pages that reference it keep working.
pepita asset rm
args<id> · --site <slug> · --yes
Remove a hosted video. --yes skips the confirmation.
pepita asset pull
args<id> · --site <slug> · --out <path>
Download a hosted video's original upload into --out (default the current folder).

A round trip

terminal

$ pepita pull my-landing --dir ./my-landing

# …edit files with your own tools…

$ pepita apply my-landing --dir ./my-landing

$ pepita preview my-landing # a shareable link to review first

$ pepita publish my-landing

→ published → my-landing.pepita.page

Add a video

A video doesn't belong in your files — it's too big — so it doesn't go through pull / apply. Upload it once with pepita asset add: pepita hosts it, prepares it to stream on any device, and gives you back a URL to drop into your markup.

Two things before you upload. Hosting a video costs 60¢ per minute of source footage, charged from your pepita balance when the upload lands — streaming it afterwards costs nothing, and pepita status shows what's left. And only mp4, mov and m4v are accepted, checked by content rather than by file extension: anything else (WebM, AVI, MKV…) is refused before the upload starts, so re-export it as mp4 first.

terminal

$ pepita asset add intro.mp4 --site my-landing

# uploads, then prepares it to stream (~a couple of minutes)

→ ready → https://cdn.pepita.dev/…/hls/playlist.m3u8

$ pepita asset list --site my-landing # what's hosted

Revoke anytime. Every device you authorize appears in the editor under your avatar → Settings → Devices, where you can sign it out.

Images · automatic

Images optimise themselves

When you publish, pepita transcodes every jpg, jpeg and png into a smaller WebP beside it: hero.jpg gets a hero.jpg.webp. Your original is never touched — not moved, not re-encoded, not replaced. There is nothing to configure. The only thing to know is which of the two URLs to point at.

The two URLs

hero.jpgThe original, byte for byte, forever. Point anything that leaves your site at this one.original
hero.jpg.webpThe optimised copy — often a fraction of the size. Point your site's own markup at this one.optimised
index.html

<!-- your own pages: use the optimised copy -->

<img src="/hero.jpg.webp" alt="…">

<style> .hero { background-image: url(/hero.jpg.webp); } </style>

 

<!-- anything that leaves the site: use the ORIGINAL -->

<meta property="og:image" content="https://you.pepita.page/hero.jpg">

Referencing the .webp cannot break your site. If the optimised copy doesn't exist — a brand-new image, one that didn't come out any smaller, or a site you haven't published since adding it — the server hands back the original's bytes, with the original's content type. So it is safe to write the .webp path before it exists. The worst case is a missed optimisation, never a broken image.
But use the original for anything that leaves the site. Social preview tags (og:image), email, and any URL someone might paste elsewhere should point at hero.jpg. WebP support in link-preview scrapers and mail clients is still patchy — and a missing social card is the kind of thing you only discover after posting. The original's URL is a permanent public contract: it will always serve exactly the file you uploaded.

The small print

jpg · jpeg · pngThe only formats transcoded. svg, gif, ico and files that are already webp are served untouched.
only if smallerSome images — flat-colour PNGs especially — come out bigger as WebP. Those get no copy at all, and the fallback quietly serves the original.
2560px long edgeAnything bigger is scaled down to fit, aspect ratio preserved, never scaled up. This, not the format change, is where most of the saving comes from.
your file winsUpload your own hero.jpg.webp and pepita leaves it exactly as you made it. It never writes over a file you put there.
Prefer the original everywhere? If quality matters more than bytes — you're publishing photography, say — just point your markup at hero.jpg and ignore the copy. Nothing obliges you to use it, for one image or across the whole site. (If pepita's AI is writing your pages, tell it so and it will do the same.)