Codex Social Media Automation with an MCP Server

Codex social media automation takes one command. Register SocialFaktory as an MCP server, keep the secret in an environment variable, and the same terminal session that ships your code can brief, price, render and schedule a brand's week.

The setup is deliberately boring, which is what you want from something holding a publishing credential.

1. Mint a token in your settings, with read and generate to start.
2. Export the secret into your shell environment.
3. Register the server with the Codex CLI, naming the environment variable rather than the secret.
4. Start a session and ask Codex to list your brands.
5. Brief a video and read the quote it returns.
6. Approve the render, then use a token with publish to compose and schedule the posts.

How do you register the server?

Two lines. The first keeps the secret out of the Codex config; the second tells Codex where to find it.

export SOCIALFAKTORY_TOKEN=sfp_...
codex mcp add socialfaktory --url https://www.socialfaktory.com/mcp --bearer-token-env-var SOCIALFAKTORY_TOKEN

If you prefer to edit configuration by hand, the same entry can live in your Codex config file under an mcp_servers table keyed by the name you choose.

[mcp_servers.socialfaktory]
url = "https://www.socialfaktory.com/mcp"
bearer_token_env_var = "SOCIALFAKTORY_TOKEN"

Both forms produce the same connection. The command is faster; the file is easier to check into a dotfiles repository, because it holds no secret.

Why keep publishing behind a confirmation?

Because a brief is a guess until you have read the output. Codex approval modes let you require a confirmation before a tool runs, and publishing is the tool worth gating. Generation is recoverable, a wrong post on a live account is not.

There is a harder limit underneath the approval prompt, and it is the better one. A token without the publish scope cannot post at all, whatever the session decides to try.

What does a session cost?

Looking around is free. Listing brands, channels and formats, reading your wallet, and pricing a job with the quote tool all cost nothing. Only generating a video and writing a post spend credits.

That asymmetry is what makes an agent safe to leave exploring. It can map your whole account, propose a week, and show you a number, before a single credit moves. The MCP reference marks which of the twenty tools spend and which do not.

How do you brief from a terminal?

In plain English, with one concrete constraint. "Two videos for Thursday and Friday, the serum, the objection about price, show me the quote first" is a better brief than three paragraphs of tone guidance, because the tone already lives in the brand.

The briefs that fail are the vague ones. An agent that is unsure will still generate something, and generating is where the credits go, so ambiguity has a price you can read in the wallet afterwards. Name the product, name the day, name the angle.

Over a week the briefs get shorter rather than longer. By Friday you are writing one line, because the brand, the cast and the calendar are all already known and the only new information is the idea.

What is the rate limit?

A hundred and twenty calls a minute per token, and three hundred requests every five minutes per address. Interactive sessions never notice.

A scheduled session can, if it polls a render in a tight loop. Read the generation back on a sensible interval instead, and the ceiling stops mattering.

How do you keep it on one brand?

Pin the token. A pinned token refuses every other brand's channels, generations, posts and library, so a session that wanders cannot reach another client's work. Uploads and the credit wallet are the exception: they belong to the account, so a pinned token can still read a file uploaded for another brand.

If you run several brands from one machine, mint one token per brand and export them under different variable names. Registering each as its own MCP server keeps the sessions honest about which floor they are standing on.

What does the output look like coming back?

An identifier first, then a finished asset. Generation is asynchronous, so the tool that starts a render hands back an id and the session reads the result when it is ready rather than blocking on it.

In practice that makes a terminal session pleasant rather than awkward. You start three renders, carry on with something else, and read all three back in one call a few minutes later, which is closer to how a queue should feel than watching a spinner.

What is out of reach from the terminal?

Cloning a video from a link, still images and carousels are app features and are not exposed to an agent. Connecting a social channel is a browser sign-in and always will be. Changing your plan is not an agent's job either.

Everything else is on the table, and the boundary is written out in full on the Codex agent page. The hub at SocialFaktory for AI agents compares the clients side by side.

Is the terminal the right place for this?

If you already brief work there, yes, because the context switch is the expensive part of a content routine, not the typing. If you would rather see previews while you decide, the AI assistant runs the same pipeline inside the app with the same prices on screen.

Either way, a token without the publish scope never posts. Start a brand, mint a read-only token, and spend the first session just looking around.

In one sentence: Codex social media automation is one MCP server entry and one environment variable away, bounded by the scopes and the monthly credit cap on its token.