Edit and Deploy Pagesmith Sites From Claude Code With Our New CLI and MCP

Our dashboard is a good place to describe a site and watch the AI build it. It is a worse place to rename a component across twelve pages, diff a hundred lines of copy, or script a bulk blog import. Those jobs belong in a terminal, next to the rest of your tools.

This week we shipped two pieces that make that possible:

• @pagesmith-ai/cli v0.2.0 — a standalone CLI for managing Pagesmith sites from the command line.
• @pagesmith-ai/mcp v0.6.0 — a Model Context Protocol server that hands the same operations to AI coding agents like Claude Code, Cursor, and Claude Desktop.

And one thing worth saying up front: every Pagesmith site is a real Astro project. When you pull one, you get actual .astro files, a normal src/pages/ tree, real content collections, and astro.config.mjs — not a proprietary JSON blob pretending to be a site. If you have ever used Astro, you already know the schema.

Same underlying API, two different surfaces. You can drive your Pagesmith site from the terminal, from an agent, or both at the same time.

---

Why a CLI and an MCP

The dashboard is built for creation: describing a site, watching the AI generate it, tweaking pages with prompts. The moment your workflow shifts from “generate” to “maintain,” the ergonomics flip:

• You want git-style diffs, not a visual editor.
• You want to edit Astro components in your own IDE with your own extensions.
• You want scripts that create fifty location pages from a CSV.
• You want an AI agent to read your real component code before it suggests a change.

All four of those want files on disk and a shell. The CLI gives you that for humans. The MCP gives the same to agents — without having to wrap a bunch of HTTP calls yourself.

And critically: no eject required. Unlike other AI builders that force a GitHub export the moment you want to touch code with external tools, Pagesmith’s CLI and MCP talk directly to your live project. No sync lag, no one-way doors, no broken visual editor after you’ve “graduated” to code. Pull, edit, push — the dashboard keeps working the whole time.

---

Getting the CLI running

npm install -g @pagesmith-ai/cli
pagesmith auth ps_live_...        # paste your API key
pagesmith projects                # confirm it can see your account

Grab an API key at app.pagesmith.ai/settings/api-keys. The config lands in ~/.pagesmith/config.json with 0600 permissions, or you can skip the file and set PAGESMITH_API_KEY in your shell.

A typical edit loop looks like this:

pagesmith pull acme-landing        # downloads to ./acme-landing/
cd acme-landing
# edit src/pages/index.astro, src/components/Hero.astro, whatever
pagesmith status                   # see what changed
pagesmith push --message "Tighten hero copy and add social proof strip"
pagesmith publish                  # ship it to production

Because it’s a plain Astro project on disk, you can also run pnpm install && pnpm dev locally if you want Astro’s dev server and hot reload while you iterate. When you’re happy, pagesmith push triggers a preview build on our side and, if the build fails, runs our auto-fixer before reporting back. The output includes a preview URL you can share before publishing.

---

Content collections from the shell

Pagesmith uses standard Astro content collections, so the CLI can treat blog posts and other structured content as data:

# what collections does this site have?
pagesmith content

# list posts in the blog collection
pagesmith content blog

# create a post from a local markdown file
pagesmith content blog create \
  --slug spring-launch \
  --title "Spring launch recap" \
  --body ./drafts/spring-launch.md \
  --field pubDate=2026-04-22 \
  --field tags='["launch","product"]'

That last command is the one that makes CSV-driven content workflows trivial. Loop over rows, call pagesmith content <collection> create for each, done. No dashboard clicks, and the fields map directly to whatever Zod schema the collection defines in src/content.config.ts.

---

Domains and secrets without the UI

Two more surfaces we moved to the CLI because they come up constantly in agency work:

pagesmith domains connect acme.com --method nameserver
pagesmith domains verify <domain-id>
pagesmith domains set-primary <domain-id>

pagesmith secrets set stripe production \
  STRIPE_PUBLISHABLE_KEY=pk_live_... \
  STRIPE_SECRET_KEY=sk_live_...

Nameserver connection remains the zero-config path for domains you bought through Pagesmith. CNAME is there when the registrar is elsewhere.

---

The same operations, through Claude Code

The MCP server exposes the same capabilities as tools an agent can call directly. You install it once, and any MCP-compatible client can drive your Pagesmith sites.

For Claude Code:

claude mcp add pagesmith -- npx -y @pagesmith-ai/mcp
# set PAGESMITH_API_KEY in your shell profile (e.g. ~/.zshrc)

For Claude Desktop, add this block to claude_desktop_config.json:

{
  "mcpServers": {
    "pagesmith": {
      "command": "npx",
      "args": ["-y", "@pagesmith-ai/mcp"],
      "env": {
        "PAGESMITH_API_KEY": "ps_live_..."
      }
    }
  }
}

Restart the client and the agent now has access to the full set of tools — pagesmith_list_projects, pagesmith_pull, pagesmith_push, pagesmith_deploy, pagesmith_publish, pagesmith_prompt, pagesmith_history, pagesmith_content_*, pagesmith_domains, and pagesmith_secrets.

---

What this looks like in practice

Open Claude Code in any directory and say:

Pull my acme-landing site, add a pricing section to the homepage that matches the hero’s style, and push a preview called “pricing v1”.

Here’s what actually happens behind the prompt:

1. Claude calls pagesmith_list_projects to find the project UUID.
2. It calls pagesmith_pull to download the Astro project into ~/.pagesmith/workspaces/<id>/.
3. It reads src/pages/index.astro and src/components/Hero.astro to match tone and styling.
4. It writes a new Pricing.astro component and imports it on the homepage.
5. It calls pagesmith_push with your commit message. If the build errors, our service auto-fixes it.
6. You get back a preview URL.

The agent never leaves the constraints we set: the MCP server only writes under ~/.pagesmith/workspaces/<project-id>/, every path returned by the API is validated, and any attempt to escape the workspace is rejected. Requests time out at 30 seconds and retry once on HTTP 429 using the Retry-After header.

The same prompt structure works for copy edits, new blog posts, programmatic SEO pages, redirect rules — anything the API exposes. And because the agent is working with real Astro files, it can read before it writes. No more “the AI guessed my component’s props wrong.”

---

Pairing human and agent workflows

The two surfaces are complementary, not competing:

• CLI when you are the one driving. Scripts, CI jobs, ad-hoc one-liners, “let me just push this fix from a coffee shop” moments.
• MCP when you want an agent to reason over the site — pulling real files, producing real diffs, pushing real previews.

A pattern we’ve seen work well inside our team: use Claude Code with the MCP to generate the bulk changes, review the diff locally, then use the CLI to push from a tight shell loop once you’re happy. The whole time the dashboard stays live and editable — the visual editor and the terminal are editing the same Astro project, not two forks that have to be reconciled.

---

npm install -g @pagesmith-ai/cli
# or
npx @pagesmith-ai/mcp

Pull a site. Edit it the way you edit everything else. Push a preview. Ship.