Gemini CLI 接 MCP 自动发布内容：写 url 还是 httpUrl，差一个字就连不上

一句话回答：Gemini CLI 接 MCP 自动发布内容，核心就一步：用 gemini mcp add --transport http 添加，或者在 settings.json 里写 httpUrl 字段。别照抄 Cursor、Cline 那类客户端的 url 写法，Gemini CLI 里的 url 指的是 SSE 端点，协议对不上就是连不上。另外这条命令默认把配置写进当前项目目录，接入地址等于钥匙，小心跟着代码一起提交。

周末用 Gemini CLI 把一个小工具重构完，顺手让它把“为什么这么改”写成一篇 800 字的技术笔记。笔记是写出来了，想贴到掘金和 CSDN 存档，还是得开浏览器、登录后台、一段段粘贴。代码交给 AI 了，“发出去”这一步却还停在手工活上。

Gemini CLI 是终端里的 AI，本身没有“发布”按钮，要让它碰得到内容平台，只能靠 MCP。接起来不复杂，但有三处细节跟别的客户端不一样，第一次接多半会卡在其中一处。

Gemini CLI 接 MCP 和别的客户端哪里不一样

多数 GUI 客户端接远程 MCP 都是 mcpServers 加一个 url。Gemini CLI 的 settings.json 同样用 mcpServers，但把传输协议拆成了三个字段，按官方文档：

• command：本地 stdio 进程
• url：SSE 端点
• httpUrl：HTTP streaming 端点，也就是 Streamable HTTP

PublishPort 的接入地址是 Streamable HTTP（Claude Code 那边的接入命令也是 --transport http）。把 url 当成“通用地址字段”填进去，Gemini CLI 会拿 SSE 的方式去连，对不上。症状是 gemini mcp list 里这一条显示 Disconnected，而不是弹一个醒目的报错。

这一点和 Cline 那篇讲的 type 字段是同一类坑：协议选择藏在一个不起眼的字段里，选错了不明说。

让 AI 用你自己的账号发，而不是给每个平台写插件

PublishPort 给 AI 的是两个通用工具：list_capabilities() 告诉 Gemini 这台电脑上登录了哪些平台，local_bash(cmd) 把发布命令经官方中转下发到你本机执行，驱动的是你自己浏览器里的真实登录态。具体某个平台要传什么参数，Gemini 自己读命令的 --help 就行，不用你给每个平台配一个插件。

装好 PublishPort 客户端，登录要发的平台账号，到「接入 AI」页生成接入地址。这条地址本身就是钥匙，后面会说怎么保管。

具体接入：一条命令，或者手改 settings.json

命令行方式，推荐加 -s user：

gemini mcp add -s user --transport http publishport "<接入 AI 页面给的接入地址>"
gemini mcp list

gemini mcp list 能看到这一条的连接状态，显示 Connected 就通了。进入 Gemini CLI 之后，输入 /mcp 还能看到它暴露了哪些工具。

手改配置，用户级文件在 ~/.gemini/settings.json：

{
  "mcpServers": {
    "publishport": {
      "httpUrl": "<接入 AI 页面给的接入地址>",
      "timeout": 120000
    }
  }
}

timeout 默认是 600000 毫秒（10 分钟），发布类操作一般用不了这么久，调短一点，卡住时能早点知道。这个值是我自己的取舍，不是官方推荐值，按你发的内容大小改。

默认写进项目目录，接入地址可能被提交

gemini mcp add 的 --scope 默认值是 project，也就是写进当前目录的 .gemini/settings.json。接入地址就在这个文件里，如果这个目录是 git 仓库，一次 git add . 就可能把它提交上去。仓库一旦公开，任何人拿到这条地址都能调用你这台电脑。

两个处理办法：加 -s user 写进 ~/.gemini/settings.json；或者坚持写项目级，就把 .gemini/settings.json 加进 .gitignore。已经提交过的话，去客户端重新生成接入地址，旧的作废。

一个具体例子：技术笔记同时发到掘金和 CSDN

笔记写完，对 Gemini CLI 说一句“把这篇笔记发到掘金和 CSDN”。它会先调 list_capabilities() 看这两个平台是否在线，再各自读发文命令的 --help，确认必填参数后用 local_bash 分别执行。两个平台的细节差异（比如 CSDN 标题是位置参数）各有坑，掘金自动发布和CSDN 自动发布分别拆过。最后两条发布回执各自传回终端，你能确认是不是两边都发出去了。

权限怎么收：别开 trust，用 includeTools 收窄

Gemini CLI 的每个 MCP 服务器配置里有个 trust 选项，设为 true 会跳过这个服务器所有工具调用的确认。官方文档的原话是只对“完全由你自己控制的服务器”使用。发布是有副作用的操作，发什么、发到哪，我建议每次都留一道人工确认，所以保持默认的 false。

想更精细一点，可以用 includeTools / excludeTools 做白名单黑名单。比如你只想让 Gemini 先看能力、不让它直接执行命令：

"publishport": {
  "httpUrl": "<接入地址>",
  "includeTools": ["list_capabilities"]
}

这样 Gemini 只能查询。等你确认流程没问题，再放开 local_bash。注意工具的实际名字以 /mcp 列出来的为准，别按我写的猜。

最后说清边界：用真实设备和真实登录态，不等于账号从此不会被限流。短时间往多个平台连发同一篇内容，平台照样可能处理，发布节奏还是按真人来，内容质量和合规也要自己把关。

接入前过一遍这份清单：

• 用的是 httpUrl 或 --transport http，不是 url
• gemini mcp list 显示 Connected
• 配置写在 ~/.gemini/settings.json，或者项目级文件已加入 .gitignore
• trust 保持 false，发布前能看到要发的内容
• 接入地址当密码保管，怀疑泄露就重新生成

常见问题 / FAQ

gemini mcp list 显示 Disconnected 怎么办？

先看写的是不是 url：Gemini CLI 里它是 SSE 端点，PublishPort 用的是 Streamable HTTP，要改成 httpUrl，或者用 --transport http 重新添加。其次确认 PublishPort 客户端在后台运行、状态是本地执行器已连接。再就是接入地址有没有复制完整或已被重新生成。

url 和 httpUrl 到底该用哪个？

按服务端用的协议选：SSE 端点用 url，Streamable HTTP 端点用 httpUrl。PublishPort 的接入地址是后者。

项目级和用户级配置有什么区别，哪个优先？

项目级是当前目录下的 .gemini/settings.json，只在这个项目里生效；用户级是 ~/.gemini/settings.json，所有项目通用。官方文档对 gemini mcp add 的默认 scope 写的是 project。两边同名服务器的合并规则我没有逐条验证，建议只在一处配置，避免排查时两边打架。

Gemini CLI 和 Cursor、Codex 接 MCP 有什么不同？

接入地址是同一条，差别在字段和入口。Cursor 看 Cursor 那篇，Codex 看 Codex 那篇。Gemini CLI 的特点是用 httpUrl 区分协议，并且命令默认写项目级。

能不能让 Gemini 自动执行发布，不用每次确认？

技术上把 trust 设成 true 就行，但不建议。发出去的内容撤回成本高，留一道确认比省这几次点击划算。

其它 AI 客户端怎么接，可以看《MCP 内容发布服务器到底是怎么工作的》。接入细节以 PublishPort 文档为准，Gemini CLI 的字段如有变动，以官方文档为准。