Post to social media from 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.