Toolport：把 MCP 配置、权限边界和 token 税一起收拾掉

现在看 MCP 生态，会越来越明显地遇到三个重复问题：

每个 AI client 都要单独配一遍 server；
一接多几个 server，tool definition 就先把上下文吃掉一大块；
OAuth、API key、危险工具和审计信息散在各个 client 里，越用越难管。

今天想记下的 tsouth89/toolport，切的就是这三个点，而且切法很像一个真正打算长期运维的本地基础设施件。

它不是某个单独 agent 的插件，也不是一个只会“列出所有 MCP server”的目录站，而是一个 local-first MCP gateway：

把 server 接入、工具发现、客户端分配、凭据注入和风险提示，统一收进同一层。

按 GitHub 仓库页、README 和 latest release 在 2026-07-02 能看到的公开信息，这个项目当前大约有 50 stars、11 forks。GitHub 仓库主语言当前显示为 TypeScript，但实际核心结构是 Tauri 桌面端 + Rust gateway。仓库创建于 2026-06-19，最近一次公开代码推送时间是 2026-07-02。最新 release 是 v0.9.4，发布时间为 2026-07-01，代码许可证是 MIT。

项目概览

属性	详情
仓库	tsouth89/toolport
定位	面向多个 AI client 的本地 MCP gateway
Stars	50
Forks	11
仓库主语言	TypeScript
实际核心结构	Tauri 桌面端 + Rust gateway
仓库创建时间	2026-06-19
最近公开代码推送	2026-07-02
最新版本	v0.9.4
版本发布时间	2026-07-01
代码许可证	MIT
核心思路	一个入口接多个 MCP server，再按客户端按需暴露工具

它解决的首先不是“怎么连上 MCP”，而是“连上以后怎么不失控”

很多 MCP 工具现在已经不缺“能不能连”的能力，真正麻烦的是连上之后的膨胀。

如果你同时在 Codex、Claude、Cursor、VS Code、Gemini CLI 之类的环境里工作，很快会发现：

同一个 GitHub、Sentry、Stripe 或数据库 server，要重复配置很多次；
某些 client 会把整套工具定义在每次请求前都灌进 context；
某些账号凭据只能散落在各自配置里；
你很难说清楚“这个 client 到底能看见哪些 server，哪些危险工具被暴露了”。

Toolport 的判断是：

把 MCP 当作一层共享基础设施，而不是每个 client 自己偷偷维护的小配置。

这也是它最像成熟工具的地方。

最有辨识度的是 lazy discovery：先只暴露 3 个 meta-tools

README 里最值得注意的，不是“支持多少客户端”，而是它对 token 税的处理方式。

项目不是把所有下游工具一次性丢给 agent，而是默认使用 lazy discovery。也就是 gateway 先只暴露三个 meta-tools：

toolport_status
toolport_search_tools
toolport_call_tool

agent 先搜索，再按需调用，而不是先把整份工具目录塞进上下文。

这个设计非常对味。

因为 MCP 生态的一个真实问题就是：工具越多，并不一定越能做事，但几乎一定越先涨上下文成本。

Toolport 在 README 里给出的基准测试非常直接：3 个 server、62 个工具时，工具定义本身就可能先吃掉大约 24000 tokens；切到这种按需发现的模式后，定义成本可以压到几百 token 量级。项目给出的结果是，在相同任务成功率前提下，总 token 使用最高可降低到九成左右。

这类收益不是“模型更聪明”式的模糊优化，而是 context surface 真的变窄了。

它把“多 client 共用一套 server”做成了第一公民

我觉得 Toolport 第二个很实用的点，是它没有把自己写成某个单一 agent 的配套件。

README 里当前列出的自动接入客户端已经很多，包括：

Codex
Claude Desktop
Claude Code
Cursor
VS Code
Gemini CLI
Windsurf
Continue
Zed
Warp

还有其他一批桌面端或 CLI 客户端。

这意味着它的价值不是再给某一个宿主补功能，而是把“一次接入，多处复用”这件事单独抽出来。

对于同时使用多个 client 的人来说，这个抽象层很有意义。你不需要分别记住每个工具的 JSON、TOML 或 YAML 结构，也不需要重复粘贴同一套 OAuth 或 API key 说明。

README 里甚至明确提到：可以直接把不同客户端文档里的 server config 片段粘进去，它会尝试识别格式并预填字段。这种细节很小，但非常像真实使用者会在乎的摩擦点。

按 client 分 profile，比“全量暴露”靠谱得多

MCP 工具一旦多起来，另一个非常现实的问题是权限边界。

不是每个 AI client 都应该看到同一组 server。更具体一点说，也不是每个 coding agent 都应该顺手就摸到支付、生产数据库、工单系统或 destructive tool。

Toolport 在这里提供的是 per-agent scoping。你可以按 profile 给某个 client 只分配它应该看到的 server，而不是默认全开。

这个思路的价值很大，因为它把边界建立在 gateway 层，而不是寄希望于“模型自己别乱用”。

如果一个 client 根本看不到某个 tool，它就没有误调用的机会。这比提示词里写“请谨慎”要硬很多。

它对 secrets 和安全提示的态度，比很多同类项目更工程化

Toolport 另一个明显更像基础设施的地方，是它没有把安全只停留在 marketing 词汇上。

README 里提到的几层能力都挺务实：

OAuth 或 API key 只在 gateway 层配置一次；
凭据保存在系统 keychain，而不是散在 client 配置文件里；
可以统一隐藏 destructive tools；
会记录调用、延迟和错误率；
会对工具定义变化、可疑 schema 或描述做完整性/投毒检测；
会对 tool 返回内容里的注入式文本做“外部数据”标记，而不是把它们当指令。

这里最重要的其实不是“它能不能百分之百防住”，而是：

它承认 gateway 在路径上，就应该承担一部分安全和治理职责。

这比很多只强调连接成功、却完全不讨论调用边界和审计的项目成熟得多。

这个项目已经不只是概念，release 也在补实用性细节

最新的 v0.9.4 release 很能说明项目现在的关注点。

这次公开说明里比较关键的两点是：

当某个下游 server 因为 HTTP 429 进入重试等待时，不再把同一个 server 上的其他 agent 请求一起堵死；
registry.json 现在会保留最近一次可恢复的备份，主文件损坏或误删时能自动回退。

这不是最花哨的 feature，但很关键。

因为本地 gateway 一旦真的进入日常工作流，最烦人的就不再是 demo 能不能跑，而是：

一个 server 限流时会不会拖垮其他请求；
配置文件坏掉后是不是整套连接一起失忆。

这类修补说明作者已经开始面对“工具被连续使用后的坏天气”，而不只是展示 happy path。

一个小细节很有意思：品牌叫 Toolport，内部名字还保留了 Conduit

如果你读 README，会发现现在对外名称已经是 Toolport，但内部二进制、环境变量和部分说明里仍能看到 conduit-gateway、CONDUIT_PROFILE 这一套名字。

这其实透露出一个很真实的状态：

项目还在快速演进，品牌和内部实现并不是一次性完全收口的。

我反而觉得这不是坏事。对使用者来说，只要文档把这层讲清楚，这种“重命名过渡期”完全可以接受；而且它也提醒你，这仍然是一个在积极迭代中的项目。

它适合什么样的人

我觉得 Toolport 特别适合下面这类使用场景：

同时使用多个 AI client；
已经接了不止一个 MCP server；
很在意上下文预算，不想让工具定义先吃光 token；
想把凭据管理、工具边界和调用审计统一收口；
希望把“哪个 client 能看到什么”做成明确配置，而不是习惯或口头约定。

如果你只偶尔接一个本地 server，也许手写配置就够了；但只要工具数量开始上升，或者 client 不止一个，Toolport 这种中间层就会开始显得很值。

小结

tsouth89/toolport 吸引我的地方，不只是它做了一个 MCP gateway。

更重要的是，它把几个原本分散的问题收到了同一个设计里：

工具定义过胖带来的 token 税；
多 client 重复配置带来的摩擦；
secrets、危险工具和审计边界混乱带来的运维负担。

它给出的答案也很克制：不是再造一个更大的 agent 平台，而是在 agent 与下游 MCP server 之间放一层本地、共享、可治理的 gateway。

对已经进入多客户端、多 server 工作流的人来说，这比“再多一个会调用工具的 agent”更像真正长期有用的基础设施。