Send a Newsletter from Cursor, Then Ship the Launch
Connect Cursor to your email stack, turn release evidence into a saved campaign, review the audience and render, and approve delivery deliberately.
You can send a newsletter from Cursor by connecting an email MCP, creating a saved campaign from the files already open in your workspace, reviewing its audience and rendered output, and explicitly confirming delivery. With Lumail's API-token MCP, Cursor can work against the same organization data as the dashboard instead of returning copy you must paste into another tool.
The launch remains the story. Cursor is where the evidence lives, and Lumail is the email line in the stack.
What you need before Cursor writes anything
- a Lumail organization with a verified sending domain and sender;
- a consented subscriber list or a controlled test segment;
- a current API token stored outside the repository;
- the release notes, offer, price, and destination URL;
- one campaign goal and one call to action.
Do not ask Cursor to infer production claims from code. Tell it which files are approved source material and which facts need a live check.
Connect Cursor to Lumail
The shortest setup is to paste this into Cursor Agent:
Read lumail.io/mcp/install and connect this project to the correct Lumail organization. Prefer one organization in a project-level .cursor/mcp.json and never register the same HTTP endpoint twice in one scope.The machine-readable install guide selects the supported transport, configures the client, and verifies the live tool list. The manual API-token configuration and stdio fallback live in the canonical Cursor MCP guide.
Cursor's official MCP documentation describes remote transports, project and global configuration, tool approvals, and how Agent uses enabled MCP tools. Keep secrets out of project-level files that could be committed.
The launch workflow inside Cursor
1. Extract a campaign brief from the release
Ask Cursor to produce a five-line brief before it calls any email tool:
- the audience;
- the change that matters to them;
- the proof available in the workspace;
- the offer or next action;
- missing facts that block the campaign.
Resolve the missing facts. A generated paragraph is not a substitute for a confirmed price, deadline, or feature state.
2. Create a draft, not a send
Use a request that makes the boundary explicit:
Turn the approved changelog into a newsletter campaign for the launch segment. Create it as a draft, return the campaign ID, subject, preview text, audience filter, and estimated recipient count, and list every product claim with its source file. Do not test, schedule, or send yet.The campaign ID is the handoff between the conversation and the dashboard. Read the same object back before moving on.
3. Make the email about the shipped result
Use this sequence:
old friction → shipped change → concrete proof → one action
Avoid turning the body into release-note bullets. Show how the release changes the reader's work, then link to the live result. Lumail only needs one line when the stack itself is relevant.
4. Render for a real test subscriber
Ask Cursor to render the saved draft with a controlled subscriber so variables and conditional content resolve. Check:
| Check | Evidence to read back |
|---|---|
| Identity | Campaign ID and draft status |
| Sender | From and reply-to addresses |
| Audience | Saved filter and recipient estimate |
| Content | Subject, preview, HTML, and text |
| Safety | Unsubscribe link and unresolved variables |
| Destinations | Final URLs, not development links |
If the render differs from the chat draft, the render wins. It is closer to what the recipient receives.
5. Send a test and review it in an inbox
Request a test only after the draft read-back is correct. Open it on desktop and mobile, click every destination, and verify the sender identity. A successful test tool call proves the test was accepted, not that the production campaign is ready.
6. Confirm the final schedule
Lumail marks campaign scheduling as a dangerous action because it delivers to every matching recipient and cannot be undone after sending. Over the API-token MCP, the first scheduling call returns a short confirmation challenge. Approve the exact campaign, audience, date, time, and time zone before Cursor repeats the call with that confirmation.
Use this final read-back:
Read the saved campaign again and show me the campaign ID, status, sender, subject, audience rule, recipient count, date, time, timezone, rendered links, and unsubscribe status. Do not schedule until I explicitly approve this exact read-back.7. Read the launch result in the same workspace
After delivery, bring campaign performance back beside the release notes. Compare clicks and purchase events with previous campaigns to a similar audience. Record one change for the next launch rather than rewriting the whole system from one send.
Can Cursor send a newsletter directly?
Yes. Cursor can use Lumail's API-token MCP to draft, render, test, and schedule a campaign when those tools are enabled for the organization. Scheduling requires explicit confirmation because it contacts real recipients. If you use a reduced OAuth connection instead, complete delivery in the Lumail app or with the CLI according to that connection's exposed tools.
Keep the prompt system stable
Use the existing pack instead of creating a new prompt library for Cursor. It includes the changelog-to-issue prompt, click-based segmentation, subject-line ranking, re-engagement, reporting, and welcome-sequence jobs used in this workflow.
Get the seven prompts that run a newsletter, or return to the Ship with Email hub.