← 返回博客

Cursor 接 MCP 自动发布内容:项目级配置文件里,token 到底该怎么放

·Cursor MCPmcp.json 配置AI IDE 发布MCP 配置教程AI 自动发布

Cursor 接 MCP 自动发布内容:项目级配置文件里,token 到底该怎么放

一句话回答:Cursor 的 MCP 支持很完善,装 GitHub、Notion、Stripe 这类官方插件一键就能连上,但发布文章类的 MCP 官方几乎没有;想让 Cursor 把写完的文章真正发到掘金、CSDN、语雀,得自己在 mcp.json 里手动接一个走 HTTP 的发布 MCP,而且要留意项目级配置文件(.cursor/mcp.json)不能带着 token 一起提交进 git 仓库。

用 Cursor 的 Agent 模式把一个功能改完,顺手把改动思路、踩过的坑写成一篇技术笔记,这半小时的写作 Cursor 自己就能包办。可笔记写完之后想发到掘金、CSDN 存档,还是得退出编辑器,开浏览器登录后台,把 Markdown 一段段贴过去、图挨个传、标签手动选。代码这一步已经交给 AI 了,“发出去”这一步怎么还停在十年前的复制粘贴。

这不是 Cursor 的 MCP 生态不行,它的 Marketplace 一键装、支持 OAuth、工具/资源/Prompt 全套协议能力都覆盖了,只是没人把“发布”做成一个官方插件。

Cursor 的 MCP 插件市场什么都有,就是没有“发文章”

打开 Cursor 的 Customize 页面能看到 Marketplace 里一堆现成插件:GitHub(建 PR、查代码)、Notion(读文档)、数据库(直接查表)、Stripe(管订阅),点一下 Add to Cursor 就能走 OAuth 授权连上,官方文档里管这类叫“一键安装“。

翻遍这些插件,没有一个是“把 AI 写好的文章发到内容平台”。原因不难理解:GitHub、Notion 这类平台本来就有开放的官方 API,插件作者接起来省事;掘金、CSDN、语雀这类内容平台大多没有对普通用户开放的发布接口,官方也就没有动力做这个插件。结果是 Cursor 里配 MCP 这件事本身很成熟,唯独“发布”这一环空着。

PublishPort 的思路:不按平台注册插件,让 AI 自己当适配器

PublishPort 没有照着 Cursor Marketplace 的思路给掘金、CSDN、语雀各写一个插件,而是给 AI 两个通用工具:list_capabilities() 告诉 Cursor 这台设备当前登录了哪些平台账号;local_bash(cmd) 把具体的发布命令下发到本机执行,跑的是驱动真实登录态的开源命令行工具。要不要发某个平台、这个平台要传哪些参数,Cursor 自己读一遍命令的 --help 就知道,不需要提前给它塞一整套按平台写死的工具定义。

好处是覆盖面不受“这个平台今年愿不愿意开放官方 API、有没有人愿意做插件”摆布。装好 PublishPort 客户端,用真实浏览器登录要发布的平台账号,就能在「接入 AI」页面拿到一条可以直接接进 Cursor 的 MCP 地址,掘金、CSDN、语雀这些没有官方插件的平台照样能发。

具体怎么接:先想清楚放项目级还是全局级

Cursor 官方文档里配置 MCP 服务器分两个位置:项目目录下的 .cursor/mcp.json 只在这个项目里生效,用户主目录下的 ~/.cursor/mcp.json 在所有工作区都生效。PublishPort 走的是远程 HTTP 服务,对应文档里“Remote Server”的配置格式:

{
  "mcpServers": {
    "publishport": {
      "url": "<PublishPort 接入 AI 页面给的 MCP 接入地址>",
      "headers": {
        "Authorization": "Bearer ${env:PUBLISHPORT_TOKEN}"
      }
    }
  }
}
  1. PublishPort 客户端,用真实浏览器登录要发布的平台账号——掘金、CSDN、语雀,连上哪个算哪个。
  2. 在客户端「接入 AI」页面复制生成的 MCP 接入地址,这条地址本身就是鉴权凭证,按官方文档的方式保管。
  3. 只在写博客这一个项目里用,就建 .cursor/mcp.json;平时不管切到哪个项目都想让 Cursor 能发文章,就建 ~/.cursor/mcp.json。两边都配了同名服务器时,Cursor 以项目级配置优先。
  4. 把上面这段 JSON 粘进去,url 换成第 2 步拿到的地址。token 别直接写死在 JSON 里,按 Cursor 支持的 ${env:变量名} 插值语法把真实值放进 shell 的环境变量,配置文件里只留一个引用。

选项目级还是全局级,唯一要多想一步的是:项目里的 .cursor/mcp.json 是一个会被 git 追踪到的普通文件,如果嫌麻烦直接把 token 明文写进去再 git add .,这条鉴权凭证就跟着代码一起进了仓库历史,尤其这个项目要开源或者给别人协作时,风险不是“可能”而是“一定”。按上一步的插值写法,把 token 放进环境变量、.cursor/mcp.json 加进 .gitignore,这个坑就绕开了。

一个具体例子:功能写完,笔记同时发到掘金和语雀

代码改完、技术笔记也写完之后,跟 Cursor 的 Agent 说一句“把这篇笔记发到掘金和语雀”。它会先调 list_capabilities() 确认这台设备上掘金和语雀是不是都在线,再去查这两个平台发文各自要传哪些必填参数——掘金的分类标签不能瞎填,语雀要指定知识库和文档路径,这些细节跟直接调 local_bash 手搓命令没有区别,AI 自己会先读清楚再动手。确认没问题后分两次调 local_bash 真正执行发布,两条发布回执(成功与否、文章链接)会分别传回来,方便确认两边是不是都真的发出去了,而不是其中一个悄悄失败。

边界:这条路省的是体力活,不是审核和判断

不建议把这条链路做成“写完直接发、没人看一眼”的自动流水线,内容质量和平台合规判断最好留一道人工确认。也不能保证账号从此不被限流——真实设备、真实登录态去掉的是最明显的自动化信号,但发帖节奏还是得照真人的样子来,短时间内往多个平台连续发同一篇文章,节奏拿捏不好照样会被平台盯上。

接进去之前,值得先过一遍这份清单:

常见问题 / FAQ

Cursor 里 MCP 显示已连接,但工具列表是空的(No tools found)怎么办?

这通常说明服务器进程从没真正启动成功,或者启动后立即崩溃了,本地进程型(command)常见于路径写错或缺环境变量,远程服务型(url)常见于地址填错或者把远程配置写成了本地命令的格式,Cursor 社区论坛上这个报错的讨论帖也印证了这几种常见原因。先去 Cursor 的 MCP 日志面板看具体报错,PublishPort 走的是纯 HTTP 远程服务,配置里只有 urlheaders,不涉及本地命令和环境变量缺失这类问题,多数情况下是接入地址复制错了或者过期了。

项目里的 .cursor/mcp.json 和全局的 ~/.cursor/mcp.json 都配了同名服务器,Cursor 听哪个?

以项目级配置为准。Cursor 允许两个位置同时定义 MCP 服务器,当服务器名字冲突时项目目录下的 .cursor/mcp.json 优先生效,全局配置里的同名项会被忽略。想临时用不同的接入地址测试,改项目级配置比改全局的更安全,不会影响到其他项目。

.cursor/mcp.json 要不要提交到 git 仓库?

不建议直接提交明文 token。这个文件本身可以提交(方便团队共享哪些 MCP 服务器要配),但里面涉及密钥的字段应该用 ${env:变量名} 引用环境变量,真正的密钥值不出现在文件里;或者干脆把 .cursor/mcp.json 加进 .gitignore,另外维护一份 .cursor/mcp.json.example 给协作者参考着自己填。

Cursor 和 Trae 接 MCP 的方式有什么不一样?

底层协议一样,PublishPort 在两边都是走 url + headers 的 HTTP 远程配置,接入地址和 token 通用。差别在配置文件的作用域:Trae 的 MCP 配置是账号级别的,Cursor 多了项目级配置这一层,也支持 ${env:变量名} 插值语法把密钥和配置文件分开存放,Trae 目前没有对应的插值机制。已经在 Trae 里接过一次的可以参考《Trae 怎么接 MCP 自动发布内容》,两边的 JSON 结构可以直接照抄,只是粘贴的位置和文件不一样。

同时装了好几个 MCP 服务器,Cursor 里工具列表被截断了怎么办?

Cursor 对分配给工具描述的上下文有限制,不是按固定数量硬切,而是按累计的描述文本量自动截断——挂的 MCP 服务器越多、暴露的工具越多,越容易被截掉排在后面的。遇到这种情况,先把当前任务用不到的 MCP 服务器在设置里临时关掉,只留发布相关的这一个,能确认是不是这个原因导致的。


不同 AI 客户端接 PublishPort 的方式大同小异,字节 Trae 怎么接可以看《Trae 怎么接 MCP 自动发布内容》,扣子和 Dify 这类 no-code 工作流平台怎么接看《扣子、Dify 智能体自动发布内容怎么做》;MCP 发布服务器背后的完整机制拆解见《MCP 内容发布服务器到底是怎么工作的》。本文若有出入或过时,以 PublishPort 文档为准。