Crm Lifecycle Ops MCP Server

crm-lifecycle-ops

Pre-send QA for Braze, Klaviyo and Iterable. Every email, text, push and in-app message is checked by code, as every kind of customer, before it goes out. Then, in your live account: what a change will break, and how to build it.

A Claude Code plugin (and a CLI for CI) for lifecycle, CRM and marketing-ops teams who build campaigns by hand. The message checks work fully today; the live-account features are early alpha (see the status column below). It is read-only: it never sends or edits anything.

Try it in 30 seconds

No account and no Claude Code needed, just Node.js 20+. This checks four sample emails that ship with the package:

npx crm-lifecycle-ops check --demo

Then point it at your own templates: npx crm-lifecycle-ops check path/to/emails. That covers emails. The plugin below adds the rest: every channel, your live account, what a change will break, and build steps.

What it does

Quick start

Needs Claude Code and Node.js 20+.

/plugin marketplace add har5h98/crm-lifecycle-ops
/plugin install crm-lifecycle-ops@crm-lifecycle-ops

Then try it on the built-in demo account. No platform access needed:

1. /refresh demo loads a fictional brand's Braze workspace.
2. /check-campaign Price Drop Alert checks a whole campaign.
3. /what-breaks loyalty_tier shows what a change would affect.

When you're ready for your own account:

• /setup teaches it your team's rules (about five minutes, or paste an email you like and it learns from that).
• /connect adds a read-only key. Keys go in the plugin's settings and your system's secure storage, never in chat.

The engine is also on npm, so any MCP client can run it. The slash commands are Claude Code skills, so elsewhere you ask in plain words ("check this email", "what breaks if I rename loyalty_tier?").

{
  "mcpServers": {
    "crm-lifecycle-ops": {
      "command": "npx",
      "args": ["-y", "crm-lifecycle-ops"],
      "env": { "CLO_BRAZE_API_KEY": "…", "CLO_BRAZE_REST_ENDPOINT": "https://rest.iad-01.braze.com" }
    }
  }
}

Leave env out to use the demo account. Every setting is listed in server.json.

The same checks run from a terminal, so a pipeline can stop a broken email before anyone launches it. It exits 1 on a blocking problem (or on warnings too, with --fail-on warn). It uses the built-in rules unless you pass a rules file, so it gives the same verdict on every machine; commit your team's file (the one /setup saves to ~/.crm-lifecycle-ops/rules.json) and point at it:

npx crm-lifecycle-ops check emails/ --rules team-rules.json

# .github/workflows/email-qa.yml
on: pull_request
jobs:
  email-qa:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx -y crm-lifecycle-ops@0.5 check emails/ # pin a version so new checks don't change your build

--help lists the options (--platform, --subject, --transactional, --json). The template language is detected per file; the output says "guessed" when nothing in a file gives it away, so pass --platform then.

Early alpha. Everything works on the demo account and against mocked API responses. It hasn't been field-tested on real accounts yet. If a result looks wrong, /report-problem turns it into a test and a fix.

Example

Real output from the demo account:

/check-campaign Price Drop Alert          🔴 Don't send. 1 blocking problem

fail  links.non-production-host        "See items" points at staging.fernbrook.example
warn  personalization.dangling-punct.  Someone with no first name on file sees "Hi ,"
warn  html.img-missing-alt             1 image has no alt text
warn  a11y.no-lang                     No lang attribute, so screen readers guess the language

/check-sms Flash Sale Text                🟡 Fix before sending

warn  sms.unicode            "’" and "—" switch the text to Unicode: 70 characters per segment, not 160.
                             Swap ’ → ' and — → -
warn  sms.too-many-segments  Up to 3 billed segments; house limit is 2
warn  sms.no-opt-out         No "Reply STOP to opt out"

Code makes every pass/fail call, never AI. Claude adds a labelled, advisory review (subject line, CTA, tone) on top. Need a record for the launch ticket? Ask /check-campaign for a QA sign-off report: a Markdown file with every finding, what couldn't be verified and a reviewer sign-off, ready to paste into Jira, Slack or Notion.

All commands

✅ works fully today · 🧪 works on the demo account and mocked APIs, not yet field-tested on real accounts

Details

Braze Liquid, Klaviyo's template language and Iterable Handlebars are supported. Platform tags that can't run locally (coupon codes, catalog lookups, Connected Content) are reported as not verified, never as passing or failing. Full list with ids: src/checks/catalog.ts.

What's "wrong" depends on the team, so checks come in three layers:

"That's fine for us" becomes a recorded exception with a reason (/house-rules), which is different from "the tool is wrong" (/report-problem). Teams share one rulebook by setting the same Shared rules file in the plugin's settings.

Every result says what it couldn't verify, and every dependency says how it's known (confirmed by the API, read from the template, read from the segment description, seen on screen).

• Local rendering is an approximation. Braze Connected Content and catalog lookups aren't executed, and Klaviyo's template language is approximated. These are reported as not verified.
• Braze's API doesn't say which segment a campaign or Canvas targets. /what-breaks lists those as "can't rule out" and can read them from your Braze dashboard via Claude in Chrome, with your OK.
• Iterable's API doesn't return journey step order, so Iterable journeys show their emails but not the path.
• Braze content cards come back from the API with few fields; card checks are fullest when the copy is pasted.
• It never builds or edits in your account. /build-plan and /edit-plan tell you how; /bulk-edit previews only.

What it runs, sends and fetches

It never sends messages, never edits your account, never reads customer profiles (it tests with made-up customers), and sends nothing to the author or any third party.

API keys are read only from the plugin's settings (secure storage). See SECURITY.md and the privacy policy.

Learn more

• Operator guide: a one-page routine for setup, each step of a build, and the weekly review.
• How it works: the architecture, data flow and design decisions in plain language.

How it gets better

1. You report: /report-problem turns a wrong result into a redacted GitHub issue (it asks before posting).
2. It becomes a test: each confirmed report joins tests/corpus/ and must pass from then on.
3. Fixes are drafted automatically: Claude writes the test and the fix as a pull request for human review.
4. Vendor changes are watched: a weekly job checks the Braze, Klaviyo and Iterable APIs for changes, and a monthly one opens a checklist to re-verify the build and edit guides against the vendors' docs. Every plan says when its steps were last verified, and warns once that's more than 90 days ago.

Wrong results are the most valuable contribution. See CONTRIBUTING.md.

License

MIT. Not affiliated with or endorsed by Braze, Klaviyo or Iterable; product names are trademarks of their owners.