Post to social media from Gemini CLI
To post to social media from Gemini CLI, add PostWharf's hosted MCP server to it once: one gemini mcp add command, or an httpUrl entry in ~/.gemini/settings.json with your workspace key in an Authorization header. Gemini CLI then loads PostWharf's 20 tools and can draft, schedule and publish to Instagram, TikTok, X, LinkedIn, YouTube, Facebook, Threads, Pinterest, Bluesky and Telegram when you ask in plain words, confirming each call with you before it runs. Every post comes back with a delivery receipt for each network, so you see exactly what landed. Reddit, Discord, Snapchat and WordPress are request-only: PostWharf cannot publish to them yet.
The MCP server comes with every plan, from Starter at $15 a month, and Starter's first seven days are free. Start free, then copy your workspace key from the dashboard under API keys.
Connect it with one command
gemini mcp add --scope user --transport http \ --header "Authorization: Bearer $POSTWHARF_KEY" \ wharf https://mcp.postwharf.com/mcp
Two flags in that command are doing real work. --transport http is needed because gemini mcp add assumes stdio, a program running on your machine, while PostWharf's server is remote and speaks Streamable HTTP.
--scope user is about where your key ends up. Left to its default, the command writes to the project file, .gemini/settings.json in whatever folder you happen to be in, and by the time Gemini CLI sees the header your shell has already replaced $POSTWHARF_KEY with the key itself. Run from inside a repository, that puts a live workspace key in a file git will happily commit. The user file, ~/.gemini/settings.json, keeps the key in your home folder and loads the server in every Gemini CLI session, whichever folder you start it from.
Or write the settings entry yourself
{
"mcpServers": {
"wharf": {
"httpUrl": "https://mcp.postwharf.com/mcp",
"headers": { "Authorization": "Bearer YOUR_WORKSPACE_KEY" }
}
}
}
The field to get right is httpUrl. Gemini CLI reads a plain url as the address of an SSE stream, and PostWharf's server offers none: a client that tries to open one there is answered with a 405. That is why the block on the Cursor setup page, which uses url and works in Cursor, is not the one to paste into Gemini CLI. If your settings file already has an mcpServers object, put the wharf entry inside it.
Check that it loaded
Start Gemini CLI and type /mcp. It lists each configured server with its connection status and the tools it discovered; wharf should show as connected with 20 tools, from get_workspace to health. Outside a session, gemini mcp list shows what is configured, and gemini mcp remove wharf takes the entry out again.
Then ask: "Which PostWharf workspace are you connected to?" The answer comes from get_workspace, and it is worth reading once. A workspace key opens exactly one workspace, and a workspace is one brand, so this is the moment to find out whether the key you pasted belongs to the brand you meant.
If wharf will not connect, the server may have turned the handshake away, and its message says why. No header gets "Missing workspace API key". A key that is mistyped, rotated or revoked gets "That workspace key was not accepted", at setup rather than at your first post, because the server checks the key with the API as the client connects. Gemini CLI can take a 401 from a remote server as a request to sign in with OAuth. PostWharf does not use OAuth: it reads the key from the header, so the fix is the header or a fresh key from the dashboard, not /mcp auth.
Ask in plain words
With the server loaded, posting is a prompt in the same terminal session where the work already is:
"Read CHANGELOG.md, write a LinkedIn post about what changed in this release and save it as a draft." "Turn the feature list in the README into a four-post X thread and schedule it for 9am tomorrow." "What is queued for this week, and did anything fail?"
Gemini CLI picks the tool, shows you the call it is about to make, and waits for your answer. PostWharf checks the text against each network's character ceiling before anything is queued, so a post in an X thread that runs past 280 characters is refused in the session instead of failing at X when it goes out. Once a post goes out, its receipt holds the state on each network, the live URL and, if a network turned it down, that network's own reason. Ask whether the LinkedIn post went out and Gemini CLI reads the receipt back rather than guessing.
Keep the approval step
Gemini CLI asks before each tool call from a server unless that server is marked as trusted, and that prompt is the natural place to decide what publishes. These are the settings that change it, all set per server entry or at the prompt:
| Setting | What it does in Gemini CLI | What to do with it for PostWharf |
|---|---|---|
trust | true skips every confirmation for the server; the default is false | Leave it false. With it on, create_post publishes the moment the model calls it. |
| "Always allow this tool" | Stops asking for that one tool | Fine for tools that only read, such as list_channels, list_queue, get_status, list_events. |
| "Always allow this server" | Stops asking for any tool on the server | Avoid it: the publishing tools stop asking too. |
includeTools | Loads only the tools you list | Use it for a drafts-only setup, below. |
excludeTools | Never loads the tools you list, and wins over includeTools | ["create_post"] if every post should be scheduled or drafted first. |
Where Gemini CLI should write and a person should decide what goes out, load only the tools that read and draft:
{
"mcpServers": {
"wharf": {
"httpUrl": "https://mcp.postwharf.com/mcp",
"headers": { "Authorization": "Bearer YOUR_WORKSPACE_KEY" },
"includeTools": ["get_workspace", "list_channels", "describe_networks",
"upload_media", "save_draft", "list_drafts"]
}
}
}
With that list, Gemini CLI can see the channels, attach media from a public URL and write drafts, and nothing it writes is queued or sent. A draft waits in the workspace until someone publishes it from the PostWharf dashboard. The wider rules for letting an agent near a live account, from duplicate posts on a retry to proving a post really went out, are in how to publish social posts safely from an MCP server.
Where it fits
Gemini CLI works in the folder you start it from, which suits the posts that grow out of that folder's work: the release note written from the changelog, the launch thread pulled from the README, the weekly roundup kept in a notes file. Asking for the post while that material is open means it gets written from the source rather than from memory a day later.
The same server connects to Claude Code with its own claude mcp add command, and the key belongs to the workspace rather than to the client, so a team that uses both agents posts into one queue and reads one set of receipts. If you would rather Gemini CLI ran shell commands than called tools, the PostWharf CLI takes the same workspace key and answers in JSON when asked. Either way, the questions a terminal agent raises are the same ones, such as how much one command should cover and when the agent should stop instead of retrying, and scheduling social posts from Claude Code in the terminal works through them.
Questions
Do these steps work in the Gemini app?
No. The settings file, gemini mcp add and /mcp all belong to Gemini CLI, the terminal agent, and the Gemini app in a browser or on a phone has none of them, so nothing on this page carries over to it.
Can one Gemini CLI setup post for two brands?
Yes, as two server entries. A workspace key opens one workspace, which is one brand, so add a second entry under its own name, such as wharf-acme, with that brand's key. Each entry reaches only its own brand's accounts, and an agency running five brands adds five entries.
Start posting from Gemini CLI
Connect the accounts you already run, add one server entry, and post from the terminal with a receipt from every network. Start free for seven days on Starter, or compare the plans on the pricing page.