一句话回答：Claude 发布内容到社交平台，目前的主流路子是给每个平台单独跑一个 MCP server（比如小红书用 xiaohongshu-mcp，抖音用另一个），在
claude_desktop_config.json里逐个加配置。平台越多，要维护的 server、登录态、配置项就越多。另一种做法是只接一个 MCP，让 AI 自己读命令行工具的--help去操作本机已登录的账号，新增平台不用再装新 server。
上周有个做知识付费的朋友让 Claude 帮他把一篇长文拆成小红书笔记发出去，写稿子那步很顺，Claude 三分钟出了六张卡片的文案。卡住的是发布——他找了个开源的小红书 MCP，装上、扫码登录、改配置文件，折腾了小半天才让 Claude 真正把内容传上去。第二天他想再加个知乎账号，发现得再重复一遍这一整套流程，装另一个 server，另外配置。
这不是他一个人的问题。Claude 能写、能搜、能规划，但“把内容真的发出去”这一步，卡在的从来不是 AI 的能力，是工程配置。
Claude 发内容到社交平台，现在的路子是“一个平台一个 MCP”
开源社区已经把这条路走通了。以小红书为例，xiaohongshu-mcp 是目前最活跃的方案：它跑一个本地 Go 程序，用浏览器自动化登录并操作小红书网页版，再把发布、搜索、评论这些动作包装成 MCP 工具，供 Claude Code、Cursor 这类客户端调用。抖音、公众号也各有对应的开源 MCP 项目，思路类似：一个平台，一个专门的 server。
接入方式是标准 MCP 流程：Claude Desktop 在 macOS 上读 ~/Library/Application Support/Claude/claude_desktop_config.json，Windows 上读 %APPDATA%\Claude\claude_desktop_config.json（官方配置指南有详细步骤）；Claude Code 则用 claude mcp add 命令逐个添加。每加一个平台，就要在这份配置里新增一段 command、args、env。
这条路是真实可用的——xiaohongshu-mcp 在 GitHub 上开源一年多，社区反馈的问题主要是登录态过期需要重新扫码，而不是账号被批量封禁。工具本身没问题，问题在于它只解决一个平台。
每多接一个平台，配置成本是线性往上叠的
如果只发小红书，装一个 MCP 完全够用。但矩阵运营的人很少只用一个平台。假设要同时覆盖小红书、抖音、知乎、公众号：
| 维度 | 一个平台一个 MCP | 一个 MCP 接多个平台 |
|---|---|---|
| 需要跑的 server 数量 | N 个（每平台一个进程） | 1 个 |
| Claude 配置文件里的条目 | N 段独立配置 | 1 段 |
| 新增一个平台的成本 | 找/装/配一个新 server | 无需新装，能力清单加一行 |
| 登录态维护 | 每个 server 各自处理 | 统一在本机账号管理里处理 |
claude mcp list 里看到的工具 |
一堆同类名字，难分辨 | 两个通用工具 |
四个平台就要维护四个进程、四份账号登录状态、四段配置。哪个 server 更新了参数、哪个的登录态过期了，都得挨个排查。这不是 Claude 能力不够，是每接一个新平台就要重新走一遍“找 MCP、装、配、调”的流程，工作量跟着平台数量线性增加。
PublishPort 的模型：AI 是适配器，--help 就是 schema
我们的做法反过来：不给每个平台单独写一个 MCP，而是给 Claude 只暴露两个工具——local_bash(cmd)，在你本机执行任意命令；list_capabilities()，返回一句话的能力清单，比如“opencli xiaohongshu 小红书，支持搜索/查询/创作者数据/内容发布“。
Claude 想操作某个平台，自己跑一句 <工具> -h 查用法，再用 local_bash 执行。它不需要一个专门为“发布”这个动作定制的接口，命令行工具自带的帮助文档就是它需要的全部 schema。新增一个平台，我们只在能力清单里加一行描述，上游 CLI 具体怎么实现，这层完全不碰。
这套方案的底层执行仍然是开源社区在维护的那批 CLI 工具（opencli 这类），跑在你自己电脑上，用你已经登录好的真实浏览器账号——发布动作没有变魔法，变化的只是 Claude 那边的接入方式，从“一堆专用 MCP”变成“一个通用接口”。想直接体验这套接入方式，可以看 接入文档。
接进 Claude 的具体步骤
- 装本机客户端：在自己电脑上装好 GUI 客户端，它负责探测各平台登录状态、管理底层 CLI 工具。
- 登录目标平台：在客户端里对小红书、知乎、公众号这些账号完成一次真实登录，登录态留在本机浏览器里。
- 拿到 MCP 接入地址：客户端会给出一个可以直接粘进 Claude 配置的连接信息。
- 添加到 Claude：Claude Code 用
claude mcp add加一次；Claude Desktop 在配置文件里加一段，重启生效。 - 验证工具已连上：新建对话，看输入框旁的工具数量图标，应该能看到
local_bash和list_capabilities两个工具，点开确认可用。
一个真实场景走一遍
假设让 Claude 把同一篇产品更新写成小红书笔记 + 知乎回答两种版本并发出去。Claude 先调 list_capabilities()，看到小红书和知乎都在清单里；分别跑 opencli xiaohongshu -h、opencli zhihu -h 确认发布命令的参数（标题、正文、图片路径怎么传）；按各平台的语言习惯改写内容——小红书要短句多分段配封面图，知乎要有观点有论据；最后用 local_bash 分别执行两条发布命令。整个过程 Claude 没有调用任何“小红书专属”或“知乎专属”的工具，用的是同一套 local_bash + list_capabilities。
安全模型：token 是唯一闸门
local_bash 能在你的电脑上跑任意命令，这意味着中转用的鉴权 token 一旦泄露，等同于这台机器被远程接管，不是“能发个帖子”那么轻。token 要当成密码级别的凭证保管，不要贴进公开的 prompt、仓库或聊天记录里；如果怀疑泄露，第一时间在客户端里吊销重新生成。这套模型把安全责任收敛到一个点上——好处是好管理，代价是这一个点必须管好，没有侥幸空间。
接入前检查清单
- 本机客户端装好，目标平台账号已完成一次真实登录
- Claude Desktop / Claude Code 的 MCP 配置里能看到
local_bash、list_capabilities两个工具 - 中转 token 只保存在本机安全的地方，没有出现在任何会被分享或提交的文本里
- 先用一个低风险平台（比如自己的小号）跑通一次完整流程，再接生产账号
- 内容仍然过一遍人工审阅，尤其是涉及敏感词、平台专属合规要求的部分
更完整的 MCP 内容发布服务器工作原理，可以看这篇 MCP 内容发布服务器到底是怎么工作的；关于为什么本机执行比云端服务器更抗封，见 为什么本地真实环境发布比云端自动化更靠谱。
常见问题 / FAQ
Claude 发布内容到社交平台需要自己写 MCP 服务器吗？
不需要。用现成的单平台 MCP（比如 xiaohongshu-mcp）或者用 PublishPort 这类统一接入方案都不用自己写代码，装好、登录、加进 Claude 配置就能用。只有需要非常定制的功能时才值得自己动手写一个 MCP server。
用 MCP 连 Claude 发小红书、抖音会不会被封号？
单看工具本身，xiaohongshu-mcp 开源一年多没有出现批量封号的反馈，主要问题是登录态过期需要重新扫码。真正的风险来自使用方式：内容重复、违禁词、引流这类行为是平台明确打击的对象，跟用没用 MCP 关系不大。
一个 MCP 配置只能对接一个平台吗？
看具体实现。社区里大多数开源 MCP 项目确实是一对一的，加一个平台就要装一个新 server。也有像 PublishPort 这样只暴露 local_bash 和 list_capabilities 两个通用工具的方案，新增平台只是能力清单加一行，不用新增 server 连接。
Claude Desktop 和 Claude Code 配置 MCP 的方式一样吗？
不完全一样。Claude Desktop 是直接编辑 claude_desktop_config.json 这份 JSON 文件；Claude Code 更常用命令行 claude mcp add 添加，也支持写进项目里的 .mcp.json 让团队共享同一套工具配置。两者最终都是往 MCP server 列表里加一条记录。
小红书、抖音都没有开放发布 API，Claude 到底是怎么发上去的？
走的是浏览器自动化：MCP server 在后台操作一个已登录的浏览器（或复用你本机的登录态），模拟填写标题、正文、上传图片、点击发布这一整套网页操作，不是调用官方接口——因为这些平台压根没有对外开放发布接口。
用 Claude 发布内容还需要人工看一遍吗？
需要。AI 起草和自动发布省的是操作时间，不是审核责任。发布前过一遍内容是否符合平台规则、有没有敏感表述，这一步不建议跳过，尤其是接入生产账号之后。