The Landing Page That Rewrites Itself: Wiring MCP Servers So Your Pages Update From Campaign Data
Michael Sacca•(No live web search in this session, so I'm writing from well-established mechanics — how the Model Context Protocol exposes tools and resources, what MCP servers exist for the platforms most campaign data lives in, and the shape of deployment setups Claude-generated sites typically land on. Server names, plan limits, and API scopes change without notice, so verify each server's README and the provider's current docs before you wire anything up.)
Here's the pattern that keeps repeating: someone asks Claude to build a landing page, gets a genuinely good one, ships it, and then treats it like a printed brochure. Two months later the headline is stale, the proof points are from a quarter nobody remembers, and the page quietly underperforms while the campaigns feeding it moved on.
The fix isn't better prompts. It's changing what the page is. A landing page wired to MCP servers isn't an artifact Claude produced once — it's a surface Claude can read data from and write to, on a loop. That's the difference between Claude the code generator and Claude the marketing agent.
Why one-shot generation is the wrong mental model
We've covered pieces of this before. Your Ads Already Know What Converts: Closing the Loop Between Campaign Data and Claude's Next Page Variant made the argument that campaign data should drive the next variant you generate — but that post described a loop you run by hand. You export the numbers, paste them into Claude, get a new variant, deploy it. Useful, but you're the cron job.
MCP removes you from the middle. The Model Context Protocol is a standard way for an LLM client to call external tools and read external data through a server — and Anthropic ships MCP support in Claude Desktop and Claude Code. Once a server is connected, "check the numbers and update the page" stops being a research project and becomes a tool call.
The distinction matters because hand-run loops die. Not because you're lazy — because the export-paste-deploy ritual has no owner, no schedule, and no alarm when you skip it. An agent with scheduled access to the data and the deploy path doesn't forget. That's also the natural extension of Agent Advertising Is Real Now: Mapping Which Parts of a Paid Campaign an LLM Agent Can Actually Run — we mapped which parts of a campaign an agent can run. This post wires one of those parts for real.
The three servers you need
A self-updating landing page needs exactly three capabilities, and there's an MCP server pattern for each:
1. Metrics in: a server that exposes your campaign data. Depending on where your numbers live, this is a Google Ads MCP server, a Meta Ads server, or — the lowest-friction starting point — a server that reads a Google Sheet or CSV your existing reporting already dumps into. Don't over-engineer this. If your ad platforms export to a spreadsheet on a schedule, a spreadsheet-reading MCP server is a perfectly legitimate metrics source, and it sidesteps OAuth scopes and API review processes you don't want to fight on day one.
2. State out: a server or repo that holds the page content. Claude shouldn't rewrite raw HTML on your production host. Put the page's editable content — headlines, proof points, CTA copy, hero stats — in a JSON or YAML content file in a Git repo, and give Claude access through a GitHub or filesystem MCP server. The page template references the content file; the agent edits the data, not the markup. This is the same discipline as Give Claude a Brand Kit, Not a Prompt: The Spec File That Keeps 30 AI-Generated Pages From Looking Like 30 Different Agencies — constrain what the agent can touch and the output stays coherent.
3. Ship it: a deploy trigger. If your site is a static build on a platform with a Git-backed workflow, pushing to the repo is the deploy. No third server needed in the simplest case — the GitHub server's push is the deployment mechanism. If your host needs an explicit build hook, a small HTTP-call MCP server that hits your deploy webhook closes the loop.
Three tools. Read data, write content, trigger build. Resist the urge to add more.
The wiring, step by step
Step 1: Extract the editable layer. Take your current landing page and pull every string an agent should be allowed to change into a content.yaml file. Headline, subhead, three proof bullets, CTA text, and — importantly — the claims. If the page says "join 2,000 marketers," that number is data, and data goes in the file.
Step 2: Define the write rules inside the file itself. At the top of content.yaml, add a comment block: max headline length, banned claim types, tone constraints, which fields the agent may never touch (legal copy, pricing, the offer itself). The agent reads this file before every write because it's part of the resource. Your brand constraints live where the agent is looking, not in a prompt you retype.
Step 3: Connect the servers. In Claude Desktop or Claude Code, add your metrics server and your Git server to the MCP config. Test each one conversationally first: "pull last week's conversion rate by ad set" should return real numbers before you let the agent act on them.
Step 4: Give the agent a decision rule, not a rewrite order. The failure mode here is the agent "optimizing" the page every time a number twitches. Instead, define a threshold: if a variant's conversion rate beats the live page by more than some margin over a full week, update the proof points and headline to match the winning message. Otherwise, log the observation and do nothing. Stability is a feature. A page that changes daily can't accumulate the statistical signal you need to make good decisions — and worse, you can no longer tell which version of the page produced which result.
Step 5: Schedule the loop. Claude Code on a cron, or whatever scheduler your setup supports, runs a prompt like: "Read the campaign metrics. Compare against the live variant's baseline, which is stored in baseline.yaml. If the decision rule triggers, write the updated content.yaml with a commit message explaining which data caused the change, and push. Otherwise, append your reasoning to agent-log.md and stop."
That commit message requirement is not decoration. When a headline changes at 3am, the commit message is the audit trail that tells you why — which metric, which threshold, which reasoning. Without it, you're debugging a page that has an agent's memories instead of a changelog.
What this looks like after a month
The honest expectation: the agent's most valuable output isn't dramatic rewrites. It's the log. A month of "conversion rate held, no change warranted" entries punctuated by two or three well-documented updates is a landing page that's finally connected to reality — proof points that match what's actually converting, and a paper trail showing the causal chain from metric to revision.
The dramatic rewrites, when they come, are earned: the data crossed a threshold you defined, the agent explained itself, and the change shipped within minutes of the trigger instead of whenever you got around to the export-paste ritual.
Where people get burned
- Write scope creep. If the Git server has access to the whole repo, the agent can eventually touch things you didn't intend. Scope it to the content directory. Most Git MCP servers support path restrictions or at least repo-level isolation — use them.
- No human gate on first deploy. Run the loop in "propose mode" for the first few cycles — the agent writes the updated content file but doesn't push. You review, then flip it to autonomous. The first time an agent rewrites your hero section, you want to be awake for it.
- Feedback loops you can't see. If the agent updates the page and the ad copy still promises the old thing, message match breaks — and as we covered in the landing page disapproval post, platforms notice. Any content the agent changes must have a corresponding ad variant someone (or something) checks. If the agent controls the page, either it or you needs to control the match.
The point of all this isn't novelty. It's that the landing page stops being a thing you built and starts being a thing that's maintained — by an agent with access to the same numbers you'd look at, the same constraints you'd follow, and a much better memory of why every change happened. That's the marketing agent as infrastructure. The wiring is three servers and a decision rule. The discipline is keeping it boring.