CLI Tools for Marketing Automation (2026): A Practical Directory

Why marketing automation needs CLI tools

The shift from manual dashboards to automated pipelines is reshaping what marketing engineering looks like. Three forces are driving it:

• AI agents need programmatic interfaces. An agent running inside Claude Code or Cursor cannot fill out a web form. It needs a CLI, a REST API, or an MCP server. Tools that expose only a web dashboard are invisible to agents.
• CI/CD pipelines run in headless environments. A GitHub Actions runner has no browser. Validation, deployment, and content operations need to be expressible as shell commands.
• Scale and consistency demand automation. Running 200 UTM links through a web dashboard one at a time is not feasible. Piping a CSV through a CLI tool and validating every output URL takes seconds.

The tools listed below are ones that marketing engineers actually install globally and run regularly — not enterprise platforms with CLIs added as an afterthought, but tools where the terminal is the primary interface.

Campaign link infrastructure: missinglinkz

Install: npm install -g missinglinkz

MissingLinkz is campaign link infrastructure for the terminal, API, and AI agents. It covers the two things marketing engineers need to do with campaign links: build them with enforced UTM naming conventions, and validate them before they go live.

Build a UTM-tagged campaign link:

Returns structured JSON with the complete tracked URL, enforced lowercase parameter values, and an optional campaign ID for storage. Validate a destination URL before publishing:

# Build the link
$ mlz build \
  --url "https://example.com/landing" \
  --source "linkedin" \
  --medium "social" \
  --campaign "q2-2026"

{
  "tracked_url": "https://example.com/landing?utm_source=linkedin&utm_medium=social&utm_campaign=q2-2026",
  "params": { "utm_source": "linkedin", "utm_medium": "social", "utm_campaign": "q2-2026" }
}

# Validate the destination
$ mlz check "https://example.com/landing"

{
  "valid": true,
  "checks": [
    { "check": "ssl", "status": "pass" },
    { "check": "resolution", "status": "pass" },
    { "check": "redirects", "status": "pass" }
  ]
}

Or combine build, validate, and inspect in one preflight command:

$ mlz preflight \
  --url "https://example.com/landing" \
  --source "linkedin" \
  --medium "social" \
  --campaign "q2-2026"

{
  "ready": true,
  "tracked_url": "https://example.com/landing?utm_source=linkedin&utm_medium=social&utm_campaign=q2-2026",
  "checks": [
    { "check": "ssl",          "status": "pass", "message": "URL uses HTTPS." },
    { "check": "resolution",   "status": "pass", "message": "Destination responded with 200." },
    { "check": "og_tags",      "status": "pass", "message": "All essential Open Graph tags present." },
    { "check": "twitter_card", "status": "pass", "message": "Twitter Card tags configured." },
    { "check": "utm_survival", "status": "pass", "message": "UTM parameters survive the destination redirect chain." }
  ],
  "summary": { "total": 12, "passed": 12, "warnings": 0, "failed": 0 },
  "recommendation": "All checks passed. Campaign link is ready to publish."
}

The utm_survival check follows the destination's full redirect chain and confirms the UTM parameters arrive intact — something neither mlz build alone nor a parameter-only "UTM validator" can tell you. A non-zero exit code on failure means CI pipelines block automatically on a bad link without any custom scripting. MissingLinkz also exposes an MCP server (mlz mcp) so AI agents can call mlz_build_link, mlz_validate_url, and mlz_inspect_destination as native tools inside Claude Code, Cursor, and any MCP-compatible agent. See the UTM tracking for developers guide for a full programmatic workflow, how to build and validate UTMs from an MCP server for the agent-native setup, and MCP tools for marketing campaigns for how the MCP server fits into an agent stack.

Deployment automation: Netlify CLI and Vercel CLI

Netlify CLI install: npm install -g netlify-cli
Vercel CLI install: npm install -g vercel

Campaign landing pages need to deploy fast. Both Netlify and Vercel ship full-featured CLIs that let you deploy, roll back, manage environment variables, and trigger preview deployments from the terminal without touching the web dashboard.

The Netlify CLI is particularly useful for marketing engineering workflows because it exposes site configuration and environment variables as scriptable objects — which means you can automate campaign-specific landing page deployments from a pipeline rather than a browser. Common marketing uses:

• netlify deploy --prod — deploy a landing page build from CI
• netlify env:set CAMPAIGN_ID "q2-launch" — set environment variables per campaign
• netlify rollback — revert a bad deploy without touching the dashboard

The Vercel CLI has equivalent capabilities: vercel --prod deploys, vercel env add manages environment variables, and vercel list shows deployment history — all from the terminal.

Version control and automation: GitHub CLI

Install: brew install gh or cli.github.com

The GitHub CLI (gh) is essential for marketing engineers who manage campaign configuration files, content repositories, or automated workflows in GitHub. Its primary value for marketing automation is scripting PR creation, issue management, and workflow triggering from a pipeline without API tokens.

Common marketing automation uses:

• gh pr create --title "Campaign: Q2 Launch" --base main — open a PR for a campaign landing page update from CI
• gh workflow run campaign-validation.yml — trigger a campaign link validation workflow on demand
• gh run watch — stream GitHub Actions output from the terminal while a validation pipeline runs
• gh issue create --label "campaign-bug" — file a tracking issue when a campaign link validation failure is detected in CI

Combined with mlz check, the pattern of running link validation in a GitHub Actions workflow and opening an issue on failure is entirely scriptable from the command line — no web dashboard required at any step.

Headless CMS: Contentful CLI

Install: npm install -g contentful-cli

For teams using Contentful as a headless CMS to manage campaign landing page content, the Contentful CLI enables content migrations, environment management, and export/import operations without the web app. Marketing engineers use it to:

• Migrate content models between environments (contentful space migration)
• Export content for backup or analysis (contentful space export)
• Manage multiple Contentful spaces and environments from a single terminal session

Storyblok, Sanity, and DatoCMS all offer comparable CLIs if those are your CMS of choice. The pattern is the same: content operations that used to require browser navigation become scriptable steps in a deployment or campaign launch pipeline.

Cloud asset management: AWS CLI

Install: aws.amazon.com/cli

Marketing teams that host campaign assets (images, PDFs, creative files) on S3 use the AWS CLI to automate uploads, manage cache invalidation, and control bucket permissions without the AWS console. The most common marketing use is automating asset deployment as part of a campaign launch pipeline:

• aws s3 sync ./campaign-assets s3://marketing-assets/q2-launch/ — bulk upload campaign creative to S3
• aws cloudfront create-invalidation --paths "/q2-launch/*" — invalidate CDN cache after asset updates so the new creative serves immediately
• aws s3 ls s3://marketing-assets/ --recursive | grep q2 — audit which campaign assets are currently deployed

For teams on Google Cloud or Azure, gcloud and az provide equivalent capabilities for GCS and Azure Blob Storage respectively.

AI agents as the orchestration layer

Every tool in this directory can be called by an AI agent with Bash access. But the marketing engineering category shifted in 2025–2026 toward agents that don't just execute shell commands — they reason about output, handle failures, and loop across campaigns without human supervision. Two integration patterns have emerged:

Bash-level access — any CLI tool becomes an agent tool. A Claude Code or Cursor agent running with Bash permissions can call gh pr create, netlify deploy --prod, or aws s3 sync directly. This works for all the tools in this directory; no special integration is needed beyond install. The agent reads stdout and exit codes the same way a human would in a script.

MCP-native integration — the highest-leverage pattern for campaign link workflows. When MissingLinkz is running as an MCP server (mlz mcp), an AI agent can call mlz_preflight as a typed tool call that returns structured JSON — no Bash required, no output parsing, and the agent gets a first-class ready: true/false verdict it can branch on. A campaign launch agent can check every link before it hands the tracked URL to a downstream tool.

For a detailed walkthrough of how to wire MissingLinkz into an agent tool loop, see CLI marketing automation for developers. The broader MCP tool landscape for marketing — including ad-platform and CRM connectors — is catalogued at MCP tools for marketing campaigns.

The practical shift: AI-agent orchestration removes the last remaining reason to reach for a web dashboard. The agent handles retries, branching, and reporting. The CLI tools handle the actual operations. Human marketing engineers define the logic once and review results.

Terminal-first vs dashboard-first: why it matters

Most marketing software was built for human operators working in browsers. That design assumption is now a constraint: web dashboards cannot be called from a GitHub Actions runner, cannot be piped into another command, cannot be invoked by an AI agent without a browser-automation layer, and cannot produce structured output that a script can branch on. When a campaign has 200 links to generate and validate, clicking through a web form 200 times is not a workflow — it is a liability.

The terminal-first approach reverses the assumption. Every operation produces structured JSON or a reliable exit code. Every step is composable: mlz preflight can be chained after mlz build, which can be triggered by a gh workflow run, which can be preceded by an aws s3 sync of the campaign assets. The full campaign launch pipeline becomes a shell script or a YAML file — version-controlled, reviewable, and repeatable.

Dashboard tools are not wrong for every use case. Analytics review, A/B test setup, and ad creative approval still happen in UIs. The distinction is between operations that require human judgment (a UI is appropriate) and operations that are mechanical and repeatable (a CLI is appropriate, an agent is even better). UTM link generation, destination validation, asset deployment, and CI gating are all in the second category. They should not be happening in a browser tab.

This is the wedge the tools above occupy: not the parts of marketing that need a dashboard, but the parts that should have been automated years ago and weren't because the tooling didn't exist.

Building your marketing automation CLI stack

The most effective marketing automation CLI stacks combine these tools into pipelines where each step feeds the next — and if you are choosing which link tooling to standardise on, the best UTM tools for developers in 2026 compares the options on CLI, API, and validation support. For a developer-focused deep-dive on CLI marketing automation patterns specifically, CLI marketing automation for developers walks through the full implementation. A typical campaign launch pipeline might look like:

1. Run mlz preflight per link — or mlz build + mlz check separately — to generate and validate each campaign URL before any downstream step. See the UTM CLI developer tool reference for the full command set
2. Sync campaign assets to S3 with aws s3 sync, invalidate the CDN with aws cloudfront create-invalidation
3. Deploy the landing page with netlify deploy --prod or vercel --prod
4. Open a review PR with gh pr create, trigger validation with gh workflow run

Each of these steps produces structured output or exit codes that can gate the next step. mlz check returns "valid": false with a non-zero exit code on failure — which means a CI step can block deployment if campaign links aren't validated. The entire chain is expressible as a shell script, a GitHub Actions workflow, or a step in an AI agent's tool loop.

FAQ

Are there CLI tools for email marketing automation?

Most major email platforms (Mailchimp, HubSpot, Klaviyo) have REST APIs but no actively maintained official CLIs suitable for pipeline use. The practical approach is to use their APIs directly via curl in shell scripts, or use the platform's Node.js SDK in a script. For the UTM tracking component of email campaigns, mlz build handles generating the tracked links that go into those emails, while mlz check validates each destination before the campaign launches.

What about social media management CLIs?

Platform-maintained CLIs for social media are sparse and typically cover ad management rather than content posting. Meta, LinkedIn, and X all have REST APIs, but no official CLIs designed for marketing automation workflows. Third-party tools exist for scheduling and publishing, but the more reliable pattern is calling the platform APIs directly from scripts or agent tools rather than depending on unofficial CLI wrappers.

Can AI agents use all of these CLI tools?

Yes — any CLI tool can be called by an AI agent via Bash tool access. MissingLinkz goes further by also exposing an MCP server (mlz mcp), which makes its tools available as native MCP tool calls in Claude Code, Cursor, and other MCP-compatible agents. This means an agent can call mlz_build_link and mlz_validate_url without needing Bash access at all. For the other tools in this directory, Bash-level access is the standard integration pattern.

How do these tools fit into GitHub Actions workflows?

All of the CLI tools listed here can run inside a GitHub Actions runner since they're available via npm, Homebrew, or package managers. The typical pattern is to install the tool in the workflow's setup step, then call it as a shell command in subsequent steps, checking exit codes to determine whether the pipeline continues. For campaign link validation specifically, see the complete CI/CD campaign validation guide for copy-paste workflow examples.

What is the difference between a terminal-first marketing stack and a dashboard-based one?

A dashboard-based stack requires a human to log in, navigate to the right screen, and click buttons — it cannot be automated, cannot be called from a CI pipeline, and cannot be used by an AI agent without browser automation. A terminal-first stack exposes every operation as a CLI command or API call that produces structured output (JSON, exit codes), which means any step can be scripted, piped, scheduled, or invoked from an agent tool loop. The practical difference: a dashboard-based UTM workflow is a series of manual steps prone to typos and skipped validation; a terminal-first workflow is a shell script or GitHub Actions job that runs the same checks every time, exits non-zero on failure, and can be reviewed in version control like any other piece of infrastructure.

How do I use these CLI tools inside an AI agent?

For general CLI tools (gh, netlify-cli, aws-cli), any AI agent with Bash access can call them directly — the agent runs the command, reads the output, and branches on exit codes or JSON fields. For MissingLinkz specifically, the preferred integration is the MCP server: run mlz mcp once and configure your MCP client (Claude Code, Cursor, or any MCP-compatible agent) to connect to it. The agent then has access to typed tools like mlz_preflight and mlz_build_link — no Bash required, and the structured response gives the agent a first-class ready: true/false verdict to act on. See how to build and validate UTMs from an MCP server for setup details.

Recommended posts