「Slim Tools」给 AI Agent 的紧凑 MCP 网关：运行时发现工具、减少上下文负担

当一个 agent 同时接入 GitHub、Linear、Notion、Stripe、Figma、Slack 这类服务时，问题很快就会从“有没有工具”变成“上下文里塞了太多工具”。Slim Tools 解决的正是这个膨胀点：把 MCP 和 OpenAPI 服务先连接到一起，再给 Claude、Cursor、Codex 等客户端一个紧凑的 MCP URL，让 agent 在运行时发现和调用真正需要的能力。

它的核心定位是 a smaller runtime tool surface for AI agents。官网示例里，客户端侧只暴露 discover_tools 和 execute_code 这样的窄接口；Slim Tools 在后面维护授权源、缓存索引和真实上游调用。这样 agent 不必在每轮对话里背着几十个甚至上百个工具定义，而是先按意图搜索能力，再用一段受控执行去组合上游工具。

把工具发现推迟到运行时

这个思路对长上下文和多服务自动化很有用。比如你想让 agent 创建 GitHub 仓库，再创建 Railway project 并关联 repo，传统做法可能要把 GitHub、Railway 的一堆工具都暴露给模型；Slim Tools 的路径是先让 agent 查询“create a github repository”“create a railway project”，拿到 typed callables 后再执行组合动作。

从产品页看，Slim Tools 支持 MCP 和 OpenAPI 两类上游，面向 Claude、Cursor、Codex 这类 MCP client，也提供 OAuth 连接服务的能力。它不是一个替代所有 MCP server 的工具，而更像 MCP gateway：把授权、索引、发现和调用放到中间层，让前端 agent 看到的接口更小、更稳定。

需要注意的是，这种工具会持有你授权的上游服务凭据。Slim Tools 的隐私页写明会处理账号信息、workspace 配置、上游服务设置、OAuth client metadata、access / refresh token、使用日志和诊断数据；它也明确说 Google 用户数据不会被出售、用于广告或训练 AI 模型。对要接入真实生产账号的团队来说，最好先按最小权限配置 scopes，再逐步开放给 agent。