Post to social media from DeepSeek Harness

Set it up

1. 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. 2. Add iHatePosting to DeepSeek Harness

   Add to ~/.dsh/profiles/web/cordis.patch.yml. On Windows that file is %USERPROFILE%\.dsh\profiles\web\cordis.patch.yml, or under $DSH_HOME instead, if you set it. The file appears after you have started DeepSeek Harness once with npx @deepseek-ai/dsh web — one run is enough. Then look at what is in it. If the only line that is not a # comment is [], replace that line with this block. If it already lists items starting with -, add this block at the end. If it holds anything between [ and ], on one line or several, leave it alone and put this block in ~/.dsh/cordis.patch.yml instead, following the same three rules there — if that file is missing, create it with just this block. That file applies to every profile. It reloads without a restart. Replace YOUR_API_KEY with your key.

   - insert:
       - id: mcp-ihateposting
         name: '@deepseek-ai/dsh-mcp-client'
         config:
           serverName: ihateposting
           transport: streamable-http
           url: https://ihateposting.com/mcp
           headers:
             Authorization: 'Bearer YOUR_API_KEY'
           toolCallTimeoutMs: 60000

3. 3. Ask it to post

   Tell DeepSeek Harness 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 DeepSeek Harness

• The CLI ships dsh-mcp-client but enables no MCP server by default, because each server command is trusted executable code outside the agent sandbox. Your block is what turns ours on. Each server is one insert row of the @deepseek-ai/dsh-mcp-client plugin, with serverName, transport, url and headers under config. serverName is the namespace for the tool names, so ours arrive as mcp__ihateposting__whoami, mcp__ihateposting__create_post and the rest; it has to match [A-Za-z0-9_-], be 32 characters or fewer, and be unique inside one registration scope.
• Put the block in ~/.dsh/profiles/web/cordis.patch.yml. That file appears the first time you run the web profile, because web, headless, sdk, sdk-minimal and acp initialise themselves from shipped templates on first use, and a fresh one holds a single []. Replace that line with the block, because a list item added after [] is not valid YAML. If the file already lists items starting with -, add the block at the end. If it holds anything else between [ and ], leave it alone and put the block in ~/.dsh/cordis.patch.yml instead: that file is shared by every profile and outranks the per-profile layer. Setting DSH_HOME moves both.
• Our block writes your key into an Authorization header. The plugin's own README writes that header as a !!js expression that reads an environment variable instead, Authorization: !!js '`Bearer ${process.env.MCP_TOKEN}`'. toolCallTimeoutMs is the per-call timeout, and the 60000 in our block is the plugin's own default, written out so it is easy to find and raise for a long upload.
• The shipped dsh-hmr plugin is active while you run a profile. It watches the profile and home patch files and reapplies valid edits transactionally, so there is nothing to restart, and an edit that is not valid YAML is not applied. Editing the configuration entry reloads the server connection in place, and unchanged names stay unchanged. If HMR has been turned off in your composition, an edit needs a restart. You can also keep the block in a file of its own and start the harness with dsh web --patch followed by that file's path, which avoids editing the [] in cordis.patch.yml; --patch is repeatable and each overlay applies in argv order, so you pass it on the command line each time you start the harness.
• failOnStartupError defaults to false, so a server that fails when it starts does not stop the harness: it starts, no tools from that server appear, and an error is logged. Set it to true if you would rather the plugin refuse to activate. If the connection drops after it has been made, the plugin reconnects on its own, with delays that double from 500 ms up to 30 s, and after ten consecutive failed attempts the server's tools are removed and it stops trying until you reload the configuration or restart the harness. Those three numbers are the reconnect defaults, and our block does not change them.
• dsh --profile web --dump-config prints the composed configuration with the profile patch, the home patch and any --patch overlays applied, and both dumps print comments naming the file that supplied each row, so you can see whether your block was read. --dump-default-config prints the bundle layers only and will never show it. That proves the config, not your key. Ask the harness to call mcp__ihateposting__whoami, which names the iHatePosting account your key belongs to. Our server does not check the key when the connection opens, so a wrong key still connects and every tool answers iHatePosting API 401.

Limits. DeepSeek Harness is in developer preview. Its README says it is iterating rapidly and that there will be compatibility-breaking changes, so if the block stops loading after an update, check it against the dsh-mcp-client reference before you change anything else.

DeepSeek AI's own documentation: The dsh-mcp-client configuration reference

Nothing goes out unless you say so

Every post DeepSeek Harness 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

Other AI agents

Hermes Agent

Set up

OpenClaw

Set up

Claude Cowork

Set up

Perplexity Computer

Set up

Freebuff CLI

Set up

Kilo Code

Set up

See every AI agent