效率工具 | 面条的草稿箱

Slim Tools：为 AI 智能体减负的统一 MCP 工具网关在使用 AI Agent（如 Claude、Cursor 等）时，你是否遇到过因为加载了太多 MCP 或 OpenAPI 工具，导致上下文窗口（Context Window）被严重占用、Token 消耗飞涨的情况？Slim Tools 提供了一个巧妙的解决方案：它将所有上游工具统一封装进一个极简的 MCP 接口中

Sat, 23 May 2026 12:18:47 GMT

Slim Tools：为 AI 智能体减负的统一 MCP 工具网关

在使用 AI Agent（如 Claude、Cursor 等）时，你是否遇到过因为加载了太多 MCP 或 OpenAPI 工具，导致上下文窗口（Context Window）被严重占用、Token 消耗飞涨的情况？

Slim Tools 提供了一个巧妙的解决方案：它将所有上游工具统一封装进一个极简的 MCP 接口中。

核心特性：

• 统一入口：无需向 AI 暴露所有工具，只需提供一个 Slim Tools 的 MCP URL（https://slim.tools/mcp）。
• 按需探索：AI 代理在运行阶段仅能看到 discover_tools（工具搜索）和 execute_code（沙盒代码执行）两个核心能力。
• 高效联动：AI 通过搜索找到匹配的工具，然后在沙盒中运行代码来组合并调用这些上游 API（如 GitHub、Notion、Slack、Figma 等）。
• 简化授权：统一管理所有上游服务的 OAuth 授权，无需重复配置。

通过这种“运行时发现”的设计，AI 代理无需在上下文里“背负”沉重的工具集，不仅让 Prompt 更加清爽，也让 Agent 的响应速度大幅提升。

原文链接：http://slim.tools

#AIAgents #MCP #开发者工具 #效率工具

Slim Tools

Slim Tools | Tool Orchestration Runtime for AI Agents

Move MCP and OpenAPI tool orchestration out of model context and into one sandboxed runtime.

以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策

Sun, 18 Jan 2026 02:00:29 GMT

以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型

这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策。

作者回顾了今年的变化：从最初“有些提示能一次跑通就很惊喜”，到现在“默认就该一次跑通”。在这种前提下，他甚至不再逐行读代码，而是看执行/修改流，关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

文章也给了不少可复用的工作方法：

• 先从 CLI 做起：任何产品先做命令行版本，方便代理直接运行验证，形成闭环；核心逻辑稳了再上 UI（比如扩展、App）。
• 关键决策是生态与依赖：语言/框架/依赖选对了，代理更容易一次完成；作者常用 TypeScript（Web）、Go（CLI）、Swift（macOS/iOS）。
• 更偏向“对话式协作”，而不是复杂流程：先和模型聊清楚、让它探索代码、共创方案，满意后再让它开干；他认为“Plan mode”更像旧时代不得已的手段。
• 对比 codex 与 Opus：codex 常会先长时间读代码再动手，虽然更慢但更稳，尤其适合大型功能和重构；Opus 更“急”，适合小改动但更容易漏上下文。
• 迭代式构建，不依赖回滚：不喜欢 checkpoint/频繁 revert，更多是让模型继续改、继续朝更好的方向“绕山而上”。
• 自动化与多项目并行：同时推进多个项目，用队列把想法排进去；瓶颈往往是人而不是编排系统。
• 配置思路：提高工具输出 token 上限、合理设置自动压缩阈值，让模型能一次读更多文件；作者强调新压缩机制更可靠，甚至像一次“复查”。

如果用一句话总结：当“写代码”越来越像可并行外包给代理的体力活，工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上；而真正影响交付速度的，往往是推理等待时间和你是否想清楚要做什么。

原链接：https://steipete.me/posts/2025/shipping-at-inference-speed
#AI编程 #Codex #开发工作流 #效率工具 #软件工程

steipete.me

Shipping at Inference-Speed | Peter Steinberger

Why I stopped reading code and started watching it stream by.

一份配置，多端通用：MCP Config 转换器mcp-config 是一个参考实现：把“同一份 MCP Server 配置”一键转换成不同应用所需的配置文件或命令，避免在 Claude Desktop、Cursor、VS Code 等多处重复手工改配置

Tue, 23 Dec 2025 14:51:40 GMT

一份配置，多端通用：MCP Config 转换器

mcp-config 是一个参考实现：把“同一份 MCP Server 配置”一键转换成不同应用所需的配置文件或命令，避免在 Claude Desktop、Cursor、VS Code 等多处重复手工改配置。

它解决什么问题

• 只维护一份 MCP Server 定义（支持远程 HTTP / 本地 stdio）
• 按目标客户端输出对应格式：JSON / CLI / TOML
• 适配 30+ 客户端格式，减少迁移与同步成本

怎么用（概念流程）

• 将仓库的 src/ 复制到你的项目中
• 使用 getClients() 查看支持的客户端
• 用 transformConfig({ server, client }) 生成目标客户端需要的配置字符串（例如 Cursor 的 JSON，或 Claude Code 的添加命令）

支持范围（示例）

• JSON 类：Claude Desktop、Cursor、Windsurf、VS Code/Copilot、JetBrains、Zed、Warp、Perplexity Desktop 等
• CLI 类：Claude Code、Amp、OpenAI Codex CLI 等

适合谁

• 同时在多个 IDE/客户端里用 MCP 的开发者与团队
• 想把“配置维护”从手工劳动变成可复用工具链的人

原链接：https://github.com/iannuttall/mcp-config

#MCP #配置管理 #开发工具 #TypeScript #效率提升

GitHub

GitHub - iannuttall/mcp-config: Turn one MCP server setup into the right format for lots of apps.

Turn one MCP server setup into the right format for lots of apps. - iannuttall/mcp-config