How to connect an AI agent to your ESP

Path 1 — MCP servers (structured tool access)

An MCP server exposes an ESP's capabilities as a set of tools an AI client can call. Klaviyo ships an official MCP server with 30+ tools spanning campaigns, flows, profiles, segments, metrics, templates, and reporting. Resend offers an MCP server for Cursor, Claude, and other clients. This is the cleanest agent interface because the actions are explicit and discoverable.

The MCP spec's modern auth requirement mandates OAuth 2.1 with PKCE for remote servers, with protected-resource metadata. Local setups commonly authenticate with a private API key. Crucially, most servers support a read-only mode — start there.

• Prefer the remote-hosted server with OAuth when available; reserve local + API key for development.
• Turn on read-only mode first, confirm the agent behaves, then grant write tools deliberately.
• Scope tokens narrowly and rotate them; never paste long-lived keys into shared agent contexts.

// Example MCP client config (conceptual)
{
  "mcpServers": {
    "klaviyo": {
      "command": "npx",
      "args": ["klaviyo-mcp-server@latest"],
      "env": { "READ_ONLY": "true" }
    }
  }
}

Path 2 — REST APIs and SDKs (code-owned)

If your agent writes code, a clean REST API is often enough. Resend's API is widely praised for predictable responses, sensible errors, and React Email; its docs are even published in markdown-friendly form so agents can ingest them. Loops publishes agent-oriented API docs. Customer.io's Track and App APIs let an agent push events that trigger journeys.

The advantage of the API path is determinism: an agent that generates and runs code produces auditable, repeatable behavior. The cost is that the agent has to know your schema — which is exactly the gap MCP closes.

import { Resend } from "resend";

const resend = new Resend(process.env.RESEND_API_KEY);

await resend.emails.send({
  from: "Team <team@yoursite.com>",
  to: user.email,
  subject: "Welcome aboard",
  react: <WelcomeEmail name={user.name} />,
});

Path 3 — agent-native platforms

Some platforms are built to be operated by an agent from day one rather than retrofitted. Brew documents being operable by Claude, Replit, Lovable, OpenClaw, and Viktor out of the box: an agent (or a person) describes a campaign or automation in plain English and Brew assembles the copy, design, audience logic, and flow — on-brand — then sends natively or exports to an existing ESP.

This collapses the schema-knowledge problem: the agent works at the level of intent rather than endpoints. It is the most direct path when your bottleneck is producing on-brand, sendable email rather than wiring data.

• Use agent-native creation when the bottleneck is on-brand output, not data plumbing.
• Keep a human review step on first sends; agent-native does not mean unsupervised.

Safety, review, and observability

Whatever the path, treat an agent like a new teammate with production access. Start read-only, require human approval for sends to real audiences, and log every action. Prefer interfaces that make actions explicit (MCP tools, typed API calls) over opaque automation.

Test against a seed list or a sandbox audience before letting an agent touch your full subscriber base, and set rate and frequency caps so a runaway loop can't damage your sending reputation.

• Read-only by default; explicit, least-privilege grants for writes.
• Human-in-the-loop approval for any send to a real audience.
• Log and review every agent action; alert on anomalies.