Download the app

← Back to blog

Cline MCP Setup for Social Posting: streamableHttp, autoApprove and the Plan/Act Habit

·Cline MCPcline_mcp_settings.jsonstreamableHttpMCP auto publishCline remote MCP server

Cline MCP Setup for Social Posting: streamableHttp, autoApprove and the Plan/Act Habit

TL;DR: Cline reads MCP servers from cline_mcp_settings.json under mcpServers. For a remote server, set "type": "streamableHttp" explicitly: per Cline’s docs, leaving type out falls back to the legacy sse transport. Keep autoApprove empty for anything that publishes.

Cline’s config looks like the mcpServers shape from other clients, with one catch that bites people: the transport default. Everything below is from Cline’s official MCP docs; settings move between releases, so check them against your version.

What you are connecting

PublishPort exposes two generic tools instead of one plugin per platform. list_capabilities() reports which platforms are logged in on your computer. local_bash(cmd) runs a command there through the relay, using your own browser sessions, and the model reads each command’s --help to learn the arguments. The design is covered in how an MCP server for content publishing works.

On your side: install the PublishPort desktop client, log in to the platforms you want, and copy the connection address from the AI integration page. Treat that address like a password, because it can run commands on your machine.

Adding the server

In the VS Code extension there are two routes, both from the docs:

  1. Remote Servers tab in the MCP Servers panel: enter a server name, the full URL, choose Streamable HTTP (marked recommended), click Add Server.
  2. Configure tab → Configure MCP Servers, which opens the settings JSON.

The JSON entry for a remote server:

{
  "mcpServers": {
    "publishport": {
      "type": "streamableHttp",
      "url": "<your connection address>",
      "headers": {
        "Authorization": "Bearer <token, if your address uses one>"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Drop headers if your PublishPort address already carries its credential; the PublishPort docs say which applies to you. The Cline CLI uses the same definitions, stored at ~/.cline/data/settings/cline_mcp_settings.json (override with CLINE_MCP_SETTINGS_PATH), and has a cline mcp wizard. A scripted add looks like cline mcp add docs https://example.com/mcp --transport http --header "Authorization: Bearer TOKEN" --yes, taken from the docs’ own example.

If it will not connect

The docs’ troubleshooting table is short: verify the URL, re-check tokens and headers, and for timeouts raise the MCP request timeout. The first thing I would check is the missing type line, because without it Cline tries SSE against an endpoint that speaks streamable HTTP. I have not reproduced that failure on every version, so treat it as the likeliest suspect, not a certainty.

Approvals: keep autoApprove empty

autoApprove lists tool names Cline may run without asking. The docs’ security advice is to limit it to safe tools and review tool calls before approving. For publishing:

That is my practice, not a Cline requirement. Cline also has Plan and Act modes; I plan the post first (platforms, wording, link) and only then switch to Act to publish. Check Cline’s docs for how your version treats MCP calls in each mode before relying on that split.

Example: a release note to two platforms

I ask: “Summarise the latest changelog entry in this repo and publish it to Dev.to and Bluesky.” The agent calls list_capabilities(), reads each publish command’s --help, drafts, and waits for approval. Platform details differ, which is why they live in automating Dev.to posts and posting to Bluesky. If the agent has never published for you, rehearse with a throwaway post first. Other clients are covered for Cursor, VS Code Copilot, Windsurf and Zed.

Limits

Checklist