一句话回答：Cline 官方插件市场没有“发文章”这类插件，想让它把写好的内容真正发到 CSDN、思否这类平台，得自己接一个走 HTTP 的发布 MCP。要注意 Cline 的 IDE 插件版和独立 CLI 版用的是两份不同的配置文件，而且新的
streamableHttp传输协议要显式写type字段——漏了这一步，Cline 会悄悄退回已经标为 legacy 的旧版 SSE 协议，不会报错提示你。
用 Cline 在 VS Code 里改完一个功能，顺手把改动思路、踩过的坑写成一篇技术笔记，这半小时的活它自己就能包办。笔记写完想存到 CSDN 或者思否留个档，还是得退出编辑器，开浏览器登录后台，标题、正文、标签一项项手动填。代码这一步已经交给 AI 了，“发出去”这一步怎么还停在复制粘贴。
这不是 Cline 的 MCP 支持不行——它是 Anthropic 早期开源生态里做得最完整的客户端之一，插件市场、Remote Servers 图形化面板、CLI 向导三条路都能装 MCP，只是没人把“发布”做成一个官方插件。
Cline 的 MCP 面板什么都能装，就是没有“发文章”
打开 Cline 侧边栏的 MCP Servers 图标，进 Configure 标签页能看到内置的插件列表，GitHub、数据库连接这类官方支持的服务点一下就能连上。如果要接一个自己的远程服务，Remote Servers 标签页更省事：填 Server Name、Server URL，再从下拉框选 Transport Type（Streamable HTTP 或者 SSE Legacy），点 Add Server 就完事，不用手写 JSON。
翻遍这个市场，没有一个是“把 AI 写好的文章发到内容平台”。原因跟 Cursor、Windsurf 上的情况一样：GitHub 这类平台本来就有开放 API，插件作者接起来省事；CSDN、思否这类内容平台大多没有对普通用户开放的发布接口，官方自然没动力做插件。
PublishPort 的思路：不按平台注册插件，让 AI 自己当适配器
PublishPort 没有照着插件市场的思路给每个平台单独写一个，而是给 AI 两个通用工具：list_capabilities() 告诉 Cline 这台设备当前登录了哪些平台账号；local_bash(cmd) 把具体的发布命令下发到本机执行，跑的是驱动真实登录态的开源命令行工具。要不要发某个平台、这个平台要传哪些参数，Cline 自己读一遍命令的 --help 就知道，不需要提前给它塞一整套按平台写死的工具定义。
好处是覆盖面不受“这个平台今年愿不愿意开放官方 API”摆布。装好 PublishPort 客户端，用真实浏览器登录要发布的平台账号，就能在「接入 AI」页面拿到一条可以直接接进 Cline 的 MCP 地址。
具体怎么接：先分清自己用的是插件版还是独立 CLI 版
Cline 现在有两个完全独立的运行形态，各自的配置文件不通用：
VS Code 插件版，配置文件在编辑器的 globalStorage 目录下：
- macOS：
~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json - Windows：
%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json - Linux：
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
用的是 VS Code Insiders 或者 VSCodium，把路径里的 Code 换成对应的 Code - Insiders 或 VSCodium。不想记这串路径，直接在 Cline 面板点 MCP Servers 图标 → Configure → Configure MCP Servers 按钮，会自动打开这份 JSON。
独立 CLI 版，走的是完全不同的一份文件，在 ~/.cline/mcp.json，也可以用 cline mcp 命令行向导交互式添加，不用手改 JSON。
两边的配置内容按官方文档的 Remote server (Streamable HTTP) 格式是一致的：
{
"mcpServers": {
"publishport": {
"type": "streamableHttp",
"url": "<PublishPort 接入 AI 页面给的 MCP 接入地址>",
"headers": {
"Authorization": "Bearer <接入地址对应的 token>"
},
"disabled": false,
"autoApprove": []
}
}
}type 字段千万别漏。Cline 官方文档写得很明确：这个字段是用来选传输协议的，一旦不写，Cline 会为了兼容老配置默认退回 legacy 的 sse 传输，不会弹窗提示、也不会报错——服务器八成率还是能连上，只是用的是官方已经标注为过时的协议，往后这条路径优先级只会越来越低。新接的服务器统一显式写 "type": "streamableHttp"，只有确实还在用老版 SSE 服务器时才需要手动指定 "type": "sse"。
一个具体例子：技术笔记写完，同时发到 CSDN 和思否
功能改完、技术笔记也写完之后，跟 Cline 说一句“把这篇笔记发到 CSDN 和思否”。它会先调 list_capabilities() 确认这台设备上这两个平台是不是都在线，再去查各自发文要传哪些必填参数——CSDN 的标题是位置参数、没有独立的 --title 选项，思否的标签得先经接口精确匹配成真实 ID，随手填一个平时用惯的标签名会直接报错，这些细节跟直接调 local_bash 手搓命令没有区别，AI 自己会先读清楚再动手（这两个平台各自的坑，CSDN 自动发布和思否自动发布分别拆过）。确认没问题后分两次调 local_bash 真正执行发布，两条发布回执分别传回来，方便确认是不是两边都真的发出去了，而不是其中一个悄悄失败。
autoApprove 要不要把发布工具加进去
Cline 的每个 MCP 服务器配置里都带一个 autoApprove 数组，把工具名填进去，之后调这个工具就不用每次手动点确认了。官方文档自己也提醒：塞进这个数组的工具会在没有任何确认提示的情况下直接执行，包括有破坏性的操作，只读类工具可以放心加，涉及写入或者执行命令的要三思。发布这类有实际副作用的操作，不建议图省事把它塞进 autoApprove——内容质量和平台合规判断最好留一道人工确认，让 Cline 每次调用前弹出来给你看一眼要发的是什么、发到哪，比全自动跑更稳妥。也不能保证账号从此不被限流：真实设备、真实登录态去掉的是最明显的自动化信号，但发帖节奏还是得照真人的样子来，短时间内连续往多个平台发同一篇文章，节奏拿捏不好照样会被平台盯上。
接进去之前，值得先过一遍这份清单：
- 确认自己用的是 VS Code 插件版还是独立 CLI 版，两份配置文件不通用
- 客户端已经用真实账号登录了要发布的平台，状态显示为已连接
- 配置里显式写了
"type": "streamableHttp"，没有漏掉导致悄悄退回 legacy SSE - 「接入 AI」页面拿到的 MCP 地址当密码一样保管，怀疑泄露就重新生成
- 发布工具没有塞进
autoApprove，每次执行前留一道人工确认
常见问题 / FAQ
Cline 里 MCP 显示已连接，但工具列表是空的怎么办？
先确认服务器进程真的启动成功了，本地 STDIO 类型常见于命令路径写错或者缺环境变量，远程 HTTP 类型常见于地址填错、或者把远程配置写成了本地命令的格式。改完配置后光切换标签页不会重新加载，得点一下服务器旁边的重启按钮，或者干脆重启 VS Code。PublishPort 走纯 HTTP 远程服务，配置里只有 url 和 headers，多数情况下是接入地址复制错了或者过期了。
VS Code 插件版和独立 CLI 版的配置能不能共用一份？
不能，两者是完全独立的两份文件，插件版存在 VS Code 的 globalStorage 目录下，CLI 版存在 ~/.cline/mcp.json。同一台机器两边都装了的话，得各自配一遍，改了一边另一边不会自动同步。
streamableHttp 和 legacy 的 sse 有什么区别，非要写清楚吗？
区别在传输层协议，streamableHttp 是 Cline 目前推荐的新协议，sse 是为了兼容老服务器保留的旧协议。type 字段不写不会报错，Cline 会默认按 sse 处理，多数情况下服务器照样能连上，但用的是官方已经标为 legacy 的路径。新接的服务器建议显式写清楚，省得日后官方逐步收窄 legacy 支持时才发现自己一直没切过来。
autoApprove 里加了发布工具会怎样？
加进去之后，Cline 调用这个工具就不会再弹确认框，直接执行。方便是方便，但对发布这类有实际副作用的操作，等于把“发不发、发什么”的判断权完全交给了 AI 当时的理解，中间少了一道人看一眼的机会。稳妥的做法是把这类工具留在 autoApprove 数组外面，让每次调用前都能看到具体要发的内容和平台。
Cline 和 Cursor、Windsurf 接 MCP 有什么不一样？
协议层都是 HTTP 远程服务器的 url + headers，接入地址和 token 通用。差别在配置文件的位置和字段：Cline 区分 IDE 插件版（globalStorage 里的 JSON）和独立 CLI 版（~/.cline/mcp.json）两条完全不同的路径，还多了一个决定传输协议的 type 字段；Cursor 是项目级 .cursor/mcp.json 和全局级 ~/.cursor/mcp.json 两层，支持 ${env:变量名} 插值；Windsurf（现 Devin Desktop）按新旧助手分成 legacy Cascade 和 Devin Local 两套体系。已经在其中一边配过的可以参考《Cursor 接 MCP 自动发布内容》或者《Windsurf 接 MCP 自动发布内容》，JSON 结构大同小异，主要是粘贴的文件和字段名不一样。
不同 AI 客户端接 PublishPort 的方式大同小异，Cursor 怎么接看《Cursor 接 MCP 自动发布内容》，字节 Trae 怎么接看《Trae 怎么接 MCP 自动发布内容》；MCP 发布服务器背后的完整机制拆解见《MCP 内容发布服务器到底是怎么工作的》。本文若有出入或过时，以 PublishPort 文档为准。