MCP · OpenAI
Marketing MCP for Codex
Codex already lives in your repo and your terminal. Point it at Spreeflo and it can ship the marketing side of a release without leaving them.
config.toml or one command·Bearer token from an env var·Works in CLI and IDE
# ~/.codex/config.toml
[mcp_servers.spreeflo]
url = "https://mcp.spreeflo.com/mcp"
bearer_token_env_var = "SPREEFLO_API_KEY"
# or, in one line:
# codex mcp add spreeflo --url https://mcp.spreeflo.com/mcp \
# --bearer-token-env-var SPREEFLO_API_KEYWrites apply to your live workspace immediately — there's no approval queue here. Keep a human in the loop and check Codex's confirmation settings first.
The agent
What is Codex?
Codex is OpenAI’s coding agent — terminal, IDE, and cloud. It reads Streamable HTTP MCP servers from its config, which means the same agent writing your release can also prepare the campaign that announces it.
Config-file driven
MCP servers live in ~/.codex/config.toml, so the connection is reviewable, diffable, and shareable with your team.
Env-var credentials
Codex reads the bearer token from an environment variable rather than the config file, keeping the key out of anything you commit.
Next to your code
Changelogs, release notes, and the email that announces them can come out of one session with the same context.
Setup
Connect Codex in about a minute
A Spreeflo API key, and one entry in Codex.
Create an API key
In the Spreeflo app, go to Settings → API Keys and click + Add API Key. Name it Codex so you can revoke this one connection later without touching the others.
Add the Spreeflo MCP server
config.toml- 1.Export your Spreeflo key as
SPREEFLO_API_KEY. - 2.Add the block below to
~/.codex/config.toml, or run the one-liner. - 3.Restart Codex so it picks up the new server.
# ~/.codex/config.toml
[mcp_servers.spreeflo]
url = "https://mcp.spreeflo.com/mcp"
bearer_token_env_var = "SPREEFLO_API_KEY"
# or, in one line:
# codex mcp add spreeflo --url https://mcp.spreeflo.com/mcp \
# --bearer-token-env-var SPREEFLO_API_KEYIf tools do not appear, the usual cause is the env var not being set in the shell that launched Codex.
Check it works
Ask Codex for something small — "list my Spreeflo audiences". A working connection is one where the tool call returns real audience names instead of an auth failure.
Full setup guide and troubleshootingIn practice
What Codex does with it
Two ordinary requests, and the Spreeflo tools behind them.
We’re shipping 2.4 today. Draft the announcement email from the changelog and target active users.
Read the changelog in the repo, built the audience, and drafted the announcement:
list_audiencescreate_segmentread_format_doccreate_email_template
The send itself is refused over MCP — a person starts the campaign in the app.
Did the signup events from last week’s SDK change actually land?
Checked the tracked events and the pages reporting them:
list_custom_eventsget_events_summarylist_pages
Useful right after a tracking change, when you want the data rather than a dashboard.
Running it
Keeping it clean in a repo
Codex reads its MCP servers from a file on disk and its credentials from the environment, which makes this the easiest pairing to get right — and the easiest to get subtly wrong when the env var is not where you think it is.
The env var belongs to the launching shell
Codex resolves SPREEFLO_API_KEY from the environment it was started in, not from your shell profile at call time. Exporting it in a new tab after Codex is already running changes nothing. This is the single most common reason the tools appear but every call fails on auth.
Commit the config, never the key
Because config.toml references an env var rather than the secret itself, the block is safe to check in and share — your team gets the same connection without anyone pasting a credential into a repo. That property is worth preserving; resist inlining the token when debugging.
One session, code and campaign
The reason to connect Codex specifically is context it already has. A changelog it just wrote is better source material for an announcement email than anything you would paste into a separate tool, and the audience query can be reasoned about from the same diff.
Think twice before CI
Codex runs unattended in pipelines, and Spreeflo writes land on the live workspace with no staging environment behind them. A misfiring job creates real segments and real drafts. If you automate anything here, keep it to reads, and use a key scoped to that job.
There is no sandbox workspace to practise in
Coming from code, the instinct is to point a new integration at staging first. Spreeflo has no such target — a key resolves to exactly one real workspace, and objects an agent creates are objects your team will see. Try the read-only tools first, and let the first write be something you would be happy to find in the app.
Why this pairing
Codex + Spreeflo
- MCP config lives in version-controllable TOML
- Bearer token sourced from an env var, never the file
- Same session covers code and the campaign about it
- Structured tool output rather than scraped screenshots
- Sends and deletes refused server-side
Coverage
Everything it can touch
The same surfaces you work with in the app, exposed as tools — and a short list that is deliberately off limits.
From a repo, the useful half of this is usually audiences and templates on the way out, and tracked events on the way back in after a tracking change.
Audience
- Audiences and contacts
- Segments, static and dynamic
- Tags
- Custom contact attributes
- CSV import
Sending
- Campaigns and journeys
- Email templates
- Web push templates
- Sender and domain identities
Capture
- Forms and question types
- Inline and popup embeds
- Response summaries
- CSV export of responses
Insight
- Campaign and web push performance
- Tracked events and pages
- Link clicks
- Form analytics
What MCP refuses to do
These are irreversible or they reach real people, so they are removed from the surface rather than left to your client's confirmation settings. A person does them in the app.