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. It goes in the Authorization header — never in the server URL.
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
There is no MCP tool for the send itself — 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
- No MCP tool for sends or deletes
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 can’t 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.
Supercharge your marketing automation
FAQ
Questions, answered.
Anywhere Codex reads your config.toml and can reach the environment variable holding the key. CLI and IDE are the straightforward cases. Cloud-executed tasks depend on how that environment is provisioned for you — if the variable is not present there, the server will load but every call will fail authentication.
Yes, and that is a genuine advantage of the config-file approach. The block names an environment variable rather than a secret, so it can live in your dotfiles repo or an onboarding script. Each engineer supplies their own Spreeflo key, which also keeps the audit trail attributing changes to the right person.
Tool discovery does not need the credential; the calls do. So a server that lists its tools and then rejects each one is telling you the connection is fine and the key is missing or stale. Check the environment of the process that launched Codex, then restart it.
No. Spreeflo runs a hosted MCP server, so Codex calls it directly over Streamable HTTP — nothing to install, nothing to self-host, no SDK to keep up to date. A server URL and a sign-in (or, for a headless agent, an API key in the Authorization header) are the whole integration.
It cannot delete anything or start a send. Spreeflo has no MCP tool for deletes, starting or resuming a campaign or journey, sending or scheduling a broadcast, or publishing a form, rather than leaving them to client settings. Those stay in the Spreeflo app, where a person does them. Journeys you have already switched on keep running, though, so editing a contact, its tags, a segment or an email template, or importing contacts, can set one off, just as the same edit would in the app.
The key resolves to exactly one workspace, and every action runs as the person who owns that key — their membership re-verified on each request. The audit trail names a real person, so agent-made changes are attributable.