Post to social media from Warp
Warp is a terminal with a built-in agent, and once you add iHatePosting to its MCP servers page that agent can post to your social accounts. You add our server from the + Add dialog as a Streamable HTTP or SSE Server (URL), with your key in an Authorization header. Anything the agent writes is saved as a draft unless you ask for it to go out now or at a set time.
Set it up
1. Create an iHatePosting API key
Sign in, open Settings → Developers and create a key. It starts with pk_live_ and is shown in full only once, so copy it before you leave the page.
2. Add iHatePosting to Warp
Settings → Agents → MCP servers → + Add. Replace the sample JSON in the editor with this config, then Save. Replace YOUR_API_KEY with your key.
{ "ihateposting": { "url": "https://ihateposting.com/mcp", "headers": { "Authorization": "Bearer YOUR_API_KEY" } } }3. Ask it to post
Tell Warp what you want to say and where. It saves a draft in iHatePosting unless you ask for the post to go out now or at a set time.
What is different about Warp
- Choose Streamable HTTP or SSE Server (URL) in the + Add dialog, not CLI Server (Command): ours is a hosted server, so there is nothing to spawn. Paste the block as it stands, keyed by the name you choose. Warp's own examples are single entries with no mcpServers wrapper; the wrapper is what its docs use for adding several servers at once. A URL server takes url, with headers as its optional second field, and that is where Warp documents an Authorization header. env belongs to the CLI Server (Command) type, so nothing of ours goes there. The MCP servers page also opens from Warp Drive under Personal, and from the command palette by searching Open MCP Servers.
- There is a file route as well. Warp reads ~/.warp/.mcp.json for every project and .warp/.mcp.json at the root of one repository, and it also reads config written by other agent tools: Claude Code's ~/.claude.json and .mcp.json, Codex's ~/.codex/config.toml and .codex/config.toml, and ~/.agents/.mcp.json or .agents/.mcp.json. If iHatePosting is already in one of those files, it can appear in Warp's list without you adding it again. Global Warp servers auto-spawn by default, and global servers from the other providers start on their own only when Auto-spawn servers from third-party agents is on. A project-scoped server from any provider must be toggled on individually from the MCP servers page, and that toggle is session-scoped, so turn it on again after you restart Warp if you still trust the repository.
- Start and stop a server from the MCP servers page, and read its output with View Logs. The log files sit in ~/Library/Group Containers/2BBY89MBSN.dev.warp/Library/Application Support/dev.warp.Warp-Stable/mcp on macOS, in $env:LOCALAPPDATA\warp\Warp\data\logs\mcp on Windows, and in ${XDG_STATE_HOME:-$HOME/.local/state}/warp-terminal/mcp on Linux. A running server only means our server answered, because it answers before it checks your key. Ask Warp to run the whoami tool, which names the iHatePosting account the key belongs to. A wrong key makes every tool come back with iHatePosting API 401.
- Take your key out of the server before you share it with teammates from the share icon. Warp's docs say sensitive values in the env configuration are scrubbed and replaced with variables when you share a server; they say nothing about headers, which is where your key sits.
- A cloud agent only runs with the MCP servers you give it when the run starts. Pass the server with --mcp, or declare it as mcp_servers in the agent config file you pass with -f, and if mcp_servers is omitted the agent runs with no MCP servers enabled. Header-based authentication on a url server works there without extra setup. You can also reference a server already configured in Warp by its UUID as warp_id, which you copy from the MCP servers page. OAuth-gated servers have to go that way, because a cloud run cannot complete a browser login; ours does not, because the key rides in a header.
- The Warp Agent CLI is a separate product from the Warp app, and it keeps its own MCP configuration. It reads one global file in the same mcpServers format, ~/.warp_cli/.mcp.json on macOS, and it does not detect project-scoped files in repositories. Type /mcp to see each server with its transport and status, and to start, stop or retry it. The bundled /tui-migrate-setup skill copies global server definitions over from the app, and it never copies credentials, so check that your key is in the CLI's file.
Limits. Under Settings → Agents → Profiles → Permissions you can set an MCP allowlist and an MCP denylist. On the allowlist, the agent calls our server without asking. On the denylist, it asks for approval first, even if our server is on the allowlist as well. Left on decide, the agent acts on its own when it is confident and asks when it is uncertain.
Denver Technologies's own documentation: Model Context Protocol (MCP) in Warp
Nothing goes out unless you say so
Every post Warp writes is saved as a draft in iHatePosting unless you ask for it to be published now or at a set time. Publishing, rescheduling, retrying and deleting are marked as actions that change things, so clients that honour those markings ask you before they run them. Deleting a post in iHatePosting never removes one that is already live on a network.
Frequently asked questions
Where does the iHatePosting block go?
On Warp's MCP servers page. Open Settings, then Agents, then MCP servers, click + Add and choose Streamable HTTP or SSE Server (URL). Paste the block keyed by the name you choose, with your key in an Authorization header under headers: Warp's own examples are single entries with no mcpServers wrapper. The same page opens from Warp Drive under Personal, and from the command palette by searching Open MCP Servers.
Why is my project server off again after I restart Warp?
A project-scoped server from any provider must be toggled on individually from the MCP servers page, and that toggle is session-scoped, so turn it on again after a restart if you still trust the repository. A server in ~/.warp/.mcp.json is global instead, and global Warp servers auto-spawn by default.
How do I know my key works?
A running server only means our server answered, because it answers before it checks your key. Ask Warp to run the whoami tool, which names the iHatePosting account the key belongs to. A wrong key makes every tool come back with iHatePosting API 401, and View Logs on the server entry shows the server's output.
Can a Warp cloud agent use this server?
Yes, but you give it the server when the run starts. Pass it with --mcp, or declare it as mcp_servers in the agent config file you pass with -f, and if mcp_servers is omitted the agent runs with no MCP servers enabled. Header-based authentication on a url server works there without extra setup, so ours needs no OAuth route.
Ready to post everywhere from Warp?
Start your 90-day free trial — no credit card, about a minute to your first post.
Sign Up