One Agent, Twenty Accounts: Running an MCP Landing Page Pipeline Across Client Campaigns

Every guide about building landing pages with AI — including most of the ones on this blog — quietly assumes the same setup: one person, one offer, one page. That's a solo operator's problem. If you run an agency, your problem looks nothing like it. You have twenty client accounts, each with its own brand voice, its own conversion tracking, its own compliance constraints, and its own stack of ads running at this very moment. And the thought of sitting down to brief Claude twenty separate times, pasting in twenty style guides and twenty sets of ad copy, is not a workflow. It's a copy-paste job with extra steps.

This is the gap that MCP — the Model Context Protocol — exists to close. Instead of hand-feeding Claude each client's context, you connect it directly to the sources where that context already lives, and the same pipeline then serves every account on your roster.

What MCP actually changes for an agency

The Model Context Protocol is Anthropic's open standard for connecting AI models to external tools and data sources. In plain terms: an MCP server is a small adapter that exposes something — a database, a file store, an API — to the model as tools it can call. Claude Desktop and Claude-based agents can connect to multiple MCP servers at once, which means a single session can read your campaign data, pull brand assets, and write files without you pasting anything.

For a one-page build, that's a convenience. For twenty accounts, it's the difference between a pipeline and a pile of one-off prompts.

The pieces that matter for landing page production:

• A file server (like the filesystem MCP server) so Claude can read each client's brand guide and write generated pages into a per-account folder structure.
• A data source for campaign context — wherever your ad copy, keyword themes, and audience notes live. Even a simple structured file per client beats a chat transcript.
• A deployment trigger, so "ship it" means push to the client's hosting, not copy-paste into a terminal.

If you've already worked through the deployment side — the different paths from generated code to a live domain covered in "Claude Built It, ChatGPT Coded It: The Three Paths From AI-Generated Code to a Live Domain" — then MCP's role here is upstream of that: it's how the brief gets assembled, per account, without you.

The per-account context file is the whole trick

The failure mode of agency AI workflows is that every account's context lives in someone's head or a Slack thread. Before you touch MCP, normalize it. Create one structured file per client — clients/acme-corp/profile.md — containing the things Claude needs on every single build:

# Acme Corp — Account Profile

## Voice
Confident, plain-spoken, no exclamation points. Second person. Never say "solution" or "leverage."

## Brand constraints
- Primary: #1A4FA0, Accent: #F5A623
- Headings: Inter, Body: Inter (no serif fonts)
- Legal line required in footer: "Acme Corp is an equal opportunity lender."

## Compliance rules
- No claims about earnings or ROI without the approved disclaimer block.
- Testimonials require first name + last initial only.

## Conversion
- Primary CTA: "Get My Rate" (never "Learn More")
- Form fields: name, email, phone only. No dropdowns.
- Pixel: Meta pixel ID 1234567890, GA4 tag configured in [tracking setup]

Every section of that file maps to a documented failure of AI-generated pages: the compliance rules exist because AI pages ship with predictable legal and accessibility problems, the form spec exists because generated forms break in predictable ways, and the tracking IDs exist because AI-generated pages routinely fail to fire conversion tags when nobody wires them up. The profile file is where all of those fixes get encoded once, so they apply to every page you ever build for that account — instead of being re-discovered on every build.

The pipeline: one prompt, parameterized by account

With profiles in place, the MCP-enabled workflow looks like this:

1. You name the account and the campaign: "Build the landing page for Acme Corp's spring refinance campaign."
2. Claude reads clients/acme-corp/profile.md through the filesystem server.
3. Claude reads the campaign brief — ad copy, keyword themes, audience — from the same folder.
4. Claude generates the page into clients/acme-corp/pages/spring-refinance/index.html, already conforming to the brand and compliance rules.
5. A second MCP tool (or a script Claude triggers) deploys to staging.
6. You run your pre-launch checks, then ship.

The prompt barely changes between accounts. The context does all the work. That's the inversion that makes this scale: at a solo-operator level, the prompt carries the context. At agency scale, the account file carries the context and the prompt is just a trigger.

What MCP does NOT solve

Be honest about the seams, because agencies hit all of them:

• Live ad platform data. Pulling real spend and performance numbers from ad platforms via MCP requires either an official connector for that platform or a custom server you build and maintain against their API. If your search results for a given platform turn up no stable connector, don't promise live dashboards to clients — export structured files instead and feed those in. The principle from "The Ad Is the Brief: How to Feed Your Ad Copy Into Claude So the Landing Page Mirrors It Word for Word" still applies; MCP just automates getting the ad copy into the prompt.
• Review is not delegable. A pipeline across twenty accounts multiplies the cost of a bad pattern — heavy generated code, broken accessibility, silent tracking failures. Those problems don't care how well-organized your context files are. Your pre-launch passes — the twelve-point deploy checklist and the accessibility audit — need to run on every page from every account, and ideally as scripted checks in the pipeline rather than human vigilance.
• Performance drift compounds. One account's bloated generated page is an annoyance; twenty of them is a systemic CPC problem. Encode the performance budget from "The Performance Budget for AI-Generated Landing Pages: What Claude's Code Costs You in Ad Load Time" as a rule in each profile file and as a Lighthouse threshold in your deploy script, so a page that loads heavy fails loudly instead of quietly taxing paid clicks.

A folder structure that survives client turnover

Agencies add and lose clients constantly, so structure for churn:

agency/
├── _templates/
│   └── client-profile.template.md
├── clients/
│   ├── acme-corp/
│   │   ├── profile.md
│   │   ├── campaigns/
│   │   │   └── spring-refinance.md
│   │   └── pages/
│   └── ...
└── checks/
    ├── lighthouse.yml
    └── accessibility-audit.md

The template file means onboarding a new client is filling out a form, not inventing a structure. The shared checks/ folder means your quality bar lives outside any single account — when you tighten a rule, it tightens everywhere at once. And when a client leaves, you delete one folder; nothing else references it.

Start with two accounts, not twenty

The honest way to build this: pick your two most active accounts, write their profile files, and run the MCP pipeline for their next three builds each. You'll discover within a week which rules you forgot to encode — the one client who always needs a specific disclaimer, the one whose forms collect different fields — and the profiles will absorb them. Only after two accounts run cleanly through the same trigger prompt should you scale it across the roster.

The solo-operator guides got you building pages with AI. MCP is what turns that from a skill into a system — one agent, twenty accounts, and a prompt that barely changes between any of them.