Email Automation with AI Agents: Using MCP with Claude Desktop, Claude Code, Cursor, and Cline

A year ago, “letting an AI send email for you” meant writing a custom integration: build a tool definition, hand-roll the schema, handle auth, store the API key in the agent’s context, hope it didn’t hallucinate the recipient. Repeat for every agent and every email service.

Then came MCP — the Model Context Protocol. One server exposes the email capability; any MCP-compatible client (Claude Desktop, Claude Code, Cursor, Cline, others) can use it. No custom integration per agent. No re-implementing auth and tool definitions for every client.

This guide is a practical walkthrough of using the Brixus365 MCP server to give AI agents the ability to send and manage email. We’ll cover what MCP is and why it matters, the use cases that actually work today, setup for the four most common clients, two concrete examples, and the safety controls you must put in place before an agent ever sends mail.

What MCP Is and Why Email Matters for AI Agents

The Model Context Protocol is an open standard for connecting AI applications to external tools and data. An MCP server exposes a set of capabilities (functions the AI can call, resources it can read, prompts it can use). An MCP client (Claude Desktop, Claude Code, Cursor, Cline, others) connects to the server and makes those capabilities available to the agent.

The win is the protocol layer. A capability provider (Brixus365) implements the server once. Every MCP client that exists today, plus every one that will exist tomorrow, gets that capability for free. There’s no per-client integration to build.

Why email specifically. Email is one of the highest-leverage capabilities you can give an AI agent. Most real-world tasks end in someone needing to be told something — a customer needing an order confirmation, a teammate needing a status update, a user needing a security alert. Email is the canonical channel for “the agent did the work; now tell the human.” Without email, the agent’s output stays trapped in its own context window.

Use Cases: Where AI-Orchestrated Email Wins

The patterns that actually work today fall into four buckets.

Customer support automation. An incoming support email arrives. An agent reads the message, looks up the customer’s account, generates a draft reply, sends it (or escalates to a human if confidence is low). The agent uses the MCP email server to send the response; another MCP server (CRM, billing, knowledge base) gives it context.

Lifecycle automation tailored to the user. Static welcome sequences treat every signup the same. An agent can look at the user’s signup source, plan tier, and first-session behaviour, then send a tailored welcome with relevant content. The MCP email server handles the send; the agent decides what to send.

Dynamic campaigns from a brief. A marketer writes a one-paragraph brief: “Send a Diwali offer to our top quartile of customers, mention free shipping and the personalised gift wrap, voice should be warm and brief.” An agent generates per-segment variants, drafts the email, and sends. The marketer reviews drafts before send; the agent does the production work.

Operational alerts with summarised context. Ops emails are often a wall of stack-traces and IDs. An agent can read the alert, look up the affected service, summarise the impact in plain language, and email the on-call rotation. Faster triage, less context-loading.

The pattern across all four: the agent is the brain, the MCP server is the muscle. Email is the output channel.

Brixus365 MCP Server Overview

The Brixus365 MCP server gives an agent sixteen focused tools that map directly to the things you actually need to do with transactional email and marketing campaigns. Connect to the hosted server at mcp.brixus365.com — sign in with OAuth, no install and no API key to manage — or self-host the open-source server from source.

Transactional email tools:

• brixus_send_email — send a single email (starter template, custom template by UUID, or raw HTML). Supports cc, bcc, reply_to, custom from address and display name, brand name and logo, attachments (up to 10 base64-encoded files), scheduled delivery (≤30 days out), and idempotency_key for safe retries.
• brixus_send_email_batch — send up to 100 transactional emails in a single API call (≤1,000 total recipients across the batch).
• brixus_get_email — check delivery status of a message by ID.
• brixus_list_emails — browse sent and queued emails with filters (status, date range, pagination).
• brixus_get_email_analytics — aggregated send stats (sent, delivered, opened, clicked, bounced) bucketed by hour or day.
• brixus_cancel_email — cancel a scheduled email before it dispatches.

Starter template tools:

• brixus_list_starter_templates — enumerate the 10 production-ready templates available out of the box (OTP, magic link, password reset, welcome, email verification, password changed, team invite, trial ending, payment receipt, security alert).
• brixus_preview_starter_template — render a template with sample variables to see what it’ll look like.

Template builder tools:

• brixus_create_email_template — design a new template from structured components; returns a template ID and an editor URL.
• brixus_update_email_template — edit a saved template.
• brixus_get_email_template — fetch a saved template by ID.
• brixus_get_email_component_schema — inspect the email component schema before building or editing.

Account introspection:

• brixus_get_api_key_info — tier, usage today and this month, rate limits, and allowed send modes for the current API key. Useful as a health check before a batch run.

Marketing campaigns (Standard / Enterprise plans):

• brixus_list_campaigns — browse campaigns with filters and pagination.
• brixus_get_campaign — fetch full details for a specific campaign.
• brixus_send_campaign_test — send a campaign test email to 1–3 addresses without affecting campaign statistics.

Authentication. Two paths. With the hosted server, you sign in with OAuth in the browser — there’s no API key to copy or store; Brixus365 issues the agent’s credentials behind the scenes. If you self-host, the server takes a Brixus365 API key at startup via the BRIXUS365_API_KEY environment variable. Either way, tier and scope decide what the agent can do. Preview keys (bx_preview_...) are the quick-start path for developers — restricted to starter templates only (no custom templates or raw HTML), which makes them a safe default while you evaluate. Live keys (bx_live_...) unlock the full surface: custom templates, raw HTML, your verified sender domain, and (on Standard / Enterprise) marketing campaigns.

Where the server runs. Two ways. The hosted server (mcp.brixus365.com) is the fastest — point your client at the URL and sign in; nothing to install, no infrastructure. Or self-host from source: clone the open-source repo, build it, and run it as a local subprocess of your MCP client with your own API key. This guide uses the hosted server; the self-host steps are noted where they differ.

Setting Up with Claude Desktop

Claude Desktop is Anthropic’s macOS / Windows / Linux desktop app for Claude. It connects to remote MCP servers through the Connectors UI — not the JSON config file.

1. Open Settings → Connectors.
2. Click Add custom connector.
3. Paste the server URL: https://mcp.brixus365.com/mcp
4. Click Add, then sign in to Brixus365 when prompted.

No JSON, no API key. The Brixus365 tools appear in the tools panel once you’re signed in.

Verify the tools loaded. Ask Claude:

What Brixus365 tools do you have access to?

You should see the agent enumerate sixteen tools — brixus_send_email, brixus_list_starter_templates, and so on. If you don’t see them, make sure you finished the browser sign-in step; you can re-open the connector from Settings → Connectors.

Setting Up with Claude Code

Claude Code is Anthropic’s terminal CLI for Claude. Adding the hosted server is a single command:

claude mcp add brixus365 --transport http https://mcp.brixus365.com/mcp

This edits ~/.claude.json for you. The first time the agent uses the server, it opens a browser to sign in to Brixus365. Verify the server registered with claude mcp list.

The first send. In any Claude Code session:

Use the Brixus365 server to send a welcome email to
jane@example.com. Her first name is Jane and the
app is Acme.

Claude Code will call brixus_list_starter_templates (if it needs to confirm the slug), then call brixus_send_email. You’ll see the tool invocations in the transcript along with the response — a message ID and a status: queued. Use brixus_get_email with the returned ID to confirm delivery.

Common setup issues:

• Tools not found — the server didn’t register, or sign-in didn’t finish. Re-run claude mcp add and complete the browser OAuth step.
• Sign-in didn’t open — trigger any Brixus365 tool in a session; Claude Code opens the consent page on first use.
• scope_required — the agent tried a capability your plan doesn’t include (e.g. marketing campaigns on a free plan). Upgrade, or use a tool your plan supports.

Setting Up with Cursor

Cursor’s MCP config is in .cursor/mcp.json (per-project) or ~/.cursor/mcp.json (global). Point it at the hosted server via the mcp-remote bridge:

{
  "mcpServers": {
    "brixus365": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.brixus365.com/mcp"]
    }
  }
}

After saving, fully quit Cursor (Cmd+Q) and reopen — or run the “Reload MCP servers” command from the command palette. On first use it opens a browser to sign in to Brixus365.

Cursor-specific UX patterns. Cursor’s agent UI surfaces tool calls inline. For destructive tools (anything that does something to the outside world, like brixus_send_email), Cursor will typically pause for confirmation before invoking. You see the proposed arguments and approve each call. This pairs naturally with preview-tier keys during development — the agent can send freely but every send is gated by your click.

Running an agent task that sends a test email. Open the Cursor chat panel:

@brixus365 send a test welcome email to jane@example.com
using the welcome template, with name "Jane" and app_name "Acme".

Cursor will invoke the server and report the message ID and status.

Setting Up with Cline

Cline is a VS Code extension agent that supports MCP. Configuration lives in Cline’s settings: open the command palette and run “Cline: Open MCP Configuration”.

Add the server (hosted, via the mcp-remote bridge):

{
  "mcpServers": {
    "brixus365": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.brixus365.com/mcp"],
      "disabled": false
    }
  }
}

Click “Reload” in the MCP panel after saving. On first use it opens a browser to sign in to Brixus365.

Self-hosting from source

Prefer to run the server yourself? It’s open source. Clone and build it, then point any client at the built entrypoint with an API key instead of the hosted URL:

git clone https://github.com/Brixus-Technologies/brixus365-mcp.git
cd brixus365-mcp && npm install && npm run build
# then, e.g. in Claude Code:
claude mcp add brixus365 -- env BRIXUS365_API_KEY=bx_live_your_key node /path/to/brixus365-mcp/dist/index.js

See the self-hosting guide for the full walkthrough.

Patterns for long-running agent flows. Cline is designed for multi-step agentic tasks — it can plan, execute, observe results, and re-plan. For email flows, this means you can give a higher-level instruction:

Read the latest customer support email in our inbox,
look up the customer's recent orders, and draft a reply.
If the issue is straightforward, send the reply.
If it needs human judgement, escalate to me.

Cline will chain MCP calls across multiple servers (your inbox MCP, Brixus365 MCP, your CRM MCP) to fulfil the task.

Stopping a runaway agent. Cline’s UI exposes a hard stop. Use it. Especially during early testing, agents will occasionally loop or generate unwanted sends — a one-click stop is your safety net.

Example 1: Claude Sending a Transactional Email

A concrete walkthrough from prompt to delivery.

The prompt:

Send a welcome email to jane@example.com.
Her name is Jane and the app is Acme.

What the agent does:

1. Recognises welcome is a starter-template-shaped task.
2. Optionally calls brixus_list_starter_templates to confirm the slug exists and to check what variables it expects (name, app_name).
3. Calls brixus_send_email with to: "jane@example.com", starter_template: "welcome", variables: { name: "Jane", app_name: "Acme" }.
4. Reports back the message ID and accepted status.

The response in the chat:

Sent. messageId: msg_preview_01J7K8X9G4N3P2Q1R5S6T7V8W9,
status: queued, from: noreply@brixus365.dev

Confirming delivery. A follow-up call to brixus_get_email with the messageId returns status: sent within a few seconds, along with the actual delivery timestamp and provider message ID.

Tracing the email in the dashboard. The Brixus365 dashboard at app.brixus365.com shows every send the API initiated, filterable by recipient, template, status, and time window. AI-initiated sends look the same as any other API-initiated send — if you want to mark them differently, pass a custom from_name like “Acme Support Agent” so they’re visually distinct in audit logs.

Example 2: An AI Workflow That Responds to a Webhook

A more realistic production pattern: an incoming event (a webhook from a CRM, a Stripe payment, a signup form) triggers an agent that uses email as one of several output channels.

The pattern:

1. Trigger. A webhook arrives at your service (e.g., payment.failed from Stripe).
2. Context. Your service kicks off an agent task with the event payload.
3. Investigation. The agent uses MCP servers — your CRM, your billing system, your knowledge base — to understand the customer’s situation.
4. Decision. The agent decides what to do: send a polite email, escalate to support, do nothing if it’s a retry-soon scenario.
5. Action. The agent calls brixus_send_email with appropriately composed content.
6. Audit. The send is visible in the Brixus365 dashboard with the agent’s chosen from_name and any custom headers; you can correlate to the event chain.

This is structurally different from a templated workflow. A traditional workflow says “on payment.failed, send template X.” The agent-driven version says “on payment.failed, look at the customer’s history, look at the failure reason, write a contextual response, send it.” The latter is harder to test but produces noticeably better customer experience.

Safety: Limiting What an AI Agent Can Send

AI agents will occasionally do unexpected things. Your safety controls determine whether unexpected means “minor variation in tone” or “1,000 customers got an off-brand email.”

Start in preview tier. bx_preview_* keys are intentionally restricted: starter templates only (no custom HTML), 50 sends per day, 1,500 per month, sender locked to noreply@brixus365.dev. They’re free, magic-link signup, no credit card. Use them for the first week or more of agent observation — long enough to watch the agent operate across normal conditions before switching to a live key.

Scope your live keys. When you do upgrade to bx_live_* keys, create separate keys for separate agent roles. An investigative agent that only summarises data gets a read-only key. An agent that sends transactional mail gets a key scoped to emails:send. An agent that touches marketing campaigns gets marketing:read or marketing:write (Standard / Enterprise plans only). The key’s permissions are the agent’s permissions.

Restrict via from_name, not via the API key. Every send via the API can override the display name. Use this to tag agent-initiated sends with a recognisable handle — “Acme Support Agent” — so recipients understand they’re talking to a bot, and so your dashboard makes the agent’s activity easy to filter.

Rate-limit at the prompt level. Beyond the API rate limits (10 calls per minute on preview tier, scoped per your tier on live), set per-agent send caps in your application logic. An agent that goes off the rails will hit the cap before doing real damage.

Human-in-the-loop for high-stakes sends. Some send categories should always have a human review step — large batches, sensitive content, anything new the agent has not done before. Build the review step into your workflow; don’t trust the agent to ask for help. Cursor’s “approve each tool call” UX is great for this during development.

Watch the usage counter. brixus_get_api_key_info returns usageToday, usageMonth, and your daily and monthly limits. Wire it into your application’s health check so you notice unusual send patterns before they hit the cap.

The most important safety control: start in preview. Don’t promote a key to bx_live_* until you’ve watched the agent operate for at least a week. The preview tier’s 50-per-day cap is your circuit breaker — by the time you exhaust it, you’ve seen enough sends to know whether the agent is behaving.

Where This Is Going: AI-Orchestrated Email Programmes

The shift is not “AI sends email for you.” It is “every developer’s agent can use email as a capability.” That’s a much bigger unlock.

What compounds. As more capabilities show up as MCP servers — CRM, billing, analytics, your own product’s API, your support inbox, your knowledge base — agents become genuinely useful. Email is one capability among many; its real value emerges when an agent can read context from one place, take action in another, and report results via email.

What changes for email programmes. Today, email marketing teams write content, segment lists, and schedule campaigns. The agent-orchestrated version: the marketer writes a brief and a set of constraints; an agent generates per-segment content, runs A/B tests, and adjusts in real time. This is not science fiction — the pieces exist; they need to be assembled. The marketing campaign tools in the Brixus365 MCP server (brixus_list_campaigns, brixus_get_campaign, brixus_send_campaign_test) are the foundation for exactly this kind of workflow.

The next 12 months. Expect MCP-supporting clients to multiply. Expect richer email MCP servers (Brixus365 included) — analytics queries, segmentation tools, BIMI verification, deliverability diagnostics, all exposed as agent-callable tools. Expect new safety patterns to emerge as more teams deploy these in production.

Key takeaways

1. MCP lets one server serve many clients. Setup once, work everywhere — Claude Desktop, Claude Code, Cursor, Cline, and any other MCP-compatible client. No custom integration per agent. This is the single biggest reason MCP matters for agent-driven email.
2. Safety controls — scoped keys, sensible send limits, and a human in the loop — are not optional for AI-initiated sends. Build them in from day one — adding them later, after an incident, is much more painful.
3. The unlock is composability. Email plus analytics plus your own product data, all callable by an agent, compounds. Email alone is useful; email in a stack of MCP capabilities is transformative.

FAQ

The Brixus365 MCP server is open source and works with Claude Desktop, Claude Code, Cursor, Cline, and any other MCP-compatible client. See it on the MCP page or get started in the developer docs — magic-link signup, no credit card.