Your Site Is Live. Now Wire It to Claude: MCPs and Automations That Keep Editing It After Launch

Every "AI builds your website" post ends at the same place: the deploy succeeded, the confetti fires, the tutorial says "and that's it!" It's not it. The site is live and now it's frozen — every headline tweak, every seasonal banner, every new variant for a new ad angle requires you to open the editor, regenerate, redeploy, and hope nothing broke in the process.

The interesting half of AI for the web isn't generation. It's the loop after launch: the model keeping its hands on the site, reading how the page performs, and shipping changes while you're doing something else. That's what this post covers — connecting MCP servers, scheduled LLM calls, and simple automation to a deployed page, and what that loop can and can't safely do.

What MCP actually is, in one paragraph

MCP — the Model Context Protocol — is an open standard Anthropic introduced in late 2024 that lets an LLM client like Claude Desktop talk to external tools through a consistent interface. Instead of copy-pasting output between windows, you run an MCP server that exposes specific capabilities: read files, query a database, call an API. Claude discovers those capabilities and uses them mid-conversation.

If you've read One Landing Page, Four AIs: Who Writes the Code, Who Makes the Hero, and Who Checks the Copy, you already split the work between a code model, an image model, and a reviewer. MCP is what lets the code model keep that job permanently instead of clocking out at deploy.

The pieces of a post-launch loop

A live-editing setup has four parts. You don't need all of them on day one, but knowing the shape helps:

1. The site, deployed with a path back in. This is the part most people skip. If Claude generated your HTML and you dragged the folder to a static host, there's no write path — the host gives you a deploy, not an editable surface. You need either a git repo the host watches, or a host with a deploy API.
2. A channel the model can act through. Claude Desktop with MCP servers configured, or a script that calls an LLM API on a schedule.
3. One or more MCP servers bridging to your stack. Community-maintained MCP servers exist for GitHub, filesystems, browsers (like Puppeteer), and databases. GitHub + filesystem covers most landing-page work.
4. A trigger. You typing "swap the hero headline and deploy," or a cron job, or a form submission that kicks off a workflow.

Walkthrough: Claude edits your live site through MCP

Here's the minimal version, assuming your site lives in a git repo connected to a static host (which is the setup the domain-connecting walkthrough in You Bought the Domain. Claude Built the Site. Now Connect Them assumes by the end).

Step 1: Get your site into a repo. If Claude built your page as loose files, git init, push to GitHub, and point your host at the repo. Now every push is a deploy.

Step 2: Install the GitHub MCP server. Claude Desktop runs MCP servers you declare in its config file. You point it at a server binary or npm package, supply a GitHub token, and restart. From that point, Claude can create branches, edit files, commit, and open pull requests in your repo directly from chat.

Step 3: Give it a job with a boundary. This is the important line. Instead of:

"Update my landing page"

try:

"In index.html, replace the headline text in the <h1> with: [new headline]. Change nothing else. Open a PR titled 'headline-swap-0301'."

The boundary matters because a model with repo write access can refactor your whole page while fixing a typo. Small, named, reviewable changes — merge the PR and your host deploys — is the loop that doesn't blow up at 9PM. When it does break anyway, the triage playbook in Your AI-Built Landing Page Just Broke at 9PM applies to MCP-caused breakage exactly as much as generation-caused breakage.

Step 4: Add a browser MCP server for verification. A browser automation server lets Claude open the live URL after the deploy and confirm the change actually rendered. That's your smoke test, and it closes the loop from "I asked" to "I verified."

What the loop is good at — and what to keep manual

Good fits

• Copy swaps and variant generation. If you're running paid traffic, generating five headline variants as separate files or a simple A/B setup is a perfect MCP task. The ranking criteria in Website Builders Ranked by What Paid Campaign Teams Actually Bleed On — pixels, split tests, revision speed — are exactly what this loop accelerates on the third point.
• Scheduled content touches. A cron job that calls an LLM API weekly to draft a blog post, commit it to a /posts folder, and open a PR for your review is a real, boring, reliable pattern. You stay the editor; the model is a contributing writer who never misses a deadline.
• Pixel and snippet updates. Swapping an analytics snippet or adding a new tracking tag across pages is find-and-replace across files — well within what a GitHub MCP server handles in one prompt.

Keep manual, or keep guarded

• Design decisions. An automation loop will happily drift your page toward the beige gradient look by making "safe" changes every week. The principles in AI Web Design Without the AI Look don't expire at launch — if anything, unattended small edits are how the AI look creeps in.
• Anything with payment, auth, or forms. Let an agent touch your checkout or form handler and you'll be debugging silently failing submissions. Structural code stays human-reviewed; the loop's job is content and configuration.
• Unattended deploys to main. Every change should go through a PR you merge, at least until you've watched the loop behave for a few weeks. "Merge automatically" is a v2 decision, not a v1 one.

The no-MCP fallback: a script and an API key

If Claude Desktop MCP setup feels heavy, the same loop works with plain scripting: a cron job calls the Claude API or OpenAI API with your current index.html in the prompt, asks for one specific change, writes the result to a file, and — if you want full automation — pushes via the GitHub API. It's less conversational and more brittle, but it's thirty lines of code and no new protocol to learn.

The honest recommendation: start with the interactive MCP version where you're in the loop on every change. Once you can predict what it does, automate the triggers. Not before.

The shift in how you think about your site

The biggest change isn't technical. It's that your landing page stops being a document you edit and becomes something with an API surface — a live thing your tools can read, modify, verify, and redeploy. Once that's true, "update the site" goes from a Saturday afternoon to a sentence in a chat window, with you deciding which sentences get through.

Build the loop small, keep the human merge button, and let the model do the part it's genuinely good at: making the change, not deciding the change.