MCP-stama

一句话定位

把"给 agent 加工具"这件事从 Node/Python 进程改成单个 Rust 二进制：同一套 grep、git 状态、 Docker 诊断工具，内存从 200MB 降到 10MB 以内，工具响应从百毫秒级降到微秒级。

做这个东西的人

StamManif（GitHub 账号），Apache-2.0，2026-08-13 发布 v0.1.0。作者无公开背景。

判断：这是 MCP 生态典型的"性能洁癖"型项目——痛点不是功能缺失，而是主流 MCP server （Node/Python）又慢又重。作者选择用 Rust 把所有通用工具重写一遍，赌"启动速度和内存占用 值得被认真对待"。

它到底能做哪几件事

• fast_grep → 基于 ignore crate 的全文搜索，自动尊重 .gitignore，跳过二进制/隐藏文件
• git_snapshot → 纯 Rust（gix/gitoxide）读 git 状态，不调用外部 git 可执行文件
• docker_watcher → 用 bollard + sysinfo 看容器和系统状态
• auto-configurator → --install-cursor / --install-claude 两秒自动注入编辑器配置
• 纯 stdio JSON-RPC 2.0 → 日志全走 stderr，stdout 只留协议帧

它明确不做：不接数据库、不接外部 API、不做任何"业务工具"。 它只做三件编码 agent 最常用的本地操作，并把它们做得比现有实现快一个量级。

它在替代什么旧行为

现在装一个 MCP server 的体验是：npm install 或 pip install，拉进来上百个依赖， 起一个 Node/Python 常驻进程，冷启动 1-3 秒，常驻内存 180-350MB（以上为 README 自报的对比数据）。 一个编码 agent 通常挂着 5-10 个 MCP server，编辑器因此变卡， agent 每次工具调用都要等进程醒来。

mcp-stama 替代的是这一整套：一个 <10MB 的静态二进制，冷启动 <2ms（自报）， 工具调用 p50 在 300µs-5ms（自报）。把"MCP 工具链"从重依赖的解释型运行时， 换成单文件的编译型运行时。

商业模式

无。 Apache-2.0 开源，无托管、无定价页。

判断：这种"基础设施的再实现"通常靠三种方式活下来：被大项目吸收、进包管理器生态、 或靠企业支持。现在一个都没发生，它目前是纯粹的开发者口碑项目。

硬数字

• 4 star / 0 fork，repo 建于 2026-08-13
• HN：71 分、0 评论（2026-08-13 前后）——分数与评论、星数严重不匹配，真实成因不确定， 不排除刷分，需自行甄别
• 自报 benchmark（README 内嵌，可自行 --benchmark 复现）： docker_watcher p50 327µs / p99 1.66ms；git_snapshot p50 462µs / p99 1.36ms； fast_grep p50 5.05ms / p99 8.72ms；RSS 均 <10MB
• 对照数据（Node/Python MCP server）：冷启动 1.5-3s、p50 150-800ms、RSS 180-350MB—— 全部自报，未见第三方复现
• 下载量、用户数：未披露

四维评估

判断

方向是对的，但"快"本身还不是产品。 工具调用快不快，在 agent 的体感里排在 "工具对不对、上下文够不够"后面很多位。一个 p50 462µs 的 git_snapshot，和 p50 150ms 的 Node 实现，用户几乎感知不到差别——除非你有上百个 MCP server 在跑。

可迁移的规律：当生态里人人都在用同一个重实现时，用"少一个量级"的重新实现切入是成立的， 但前提是选对集成或收费的方式。 Rust 重写本身就是这条规律的产物——gitoxide（gix） 就是"用 Rust 重写 git 库函数"的著名案例，mcp-stama 在借它的现成成果。

必须警惕的数据问题：71 分、0 评论、4 star。HN 上正常的 70 分项目至少有几个评论， 这个组合非常反常。所有性能数字都是自报的，没有第三方复现。 在独立复现之前，这些数字只能当宣传看。

更大的问题：这些"通用工具"到底值不值得做成 MCP server？把 grep、git、docker 放进 agent 的工具箱，Cursor 自己就有等价物。它没回答"为什么 agent 要用你的 grep 而不是内置的"。

下一步看什么

① 有没有第三方独立复现性能数字，或有人公开跑过 --benchmark ② HN 那 71 分能不能被解释（比如被删帖、被质疑），星数三个月后是否和分数匹配 ③ 工具集会不会扩张——如果只停在"三件套"，它就是一次性项目； 如果长出"生态缺什么就补什么"的能力，才是个平台

可借鉴的做法

产品逻辑：做面向 agent 的基础设施时，性能是必要不充分条件。 先证明"为什么 agent 需要这个工具"（场景），再谈快。快是差异化，不是产品本身。

定价结构：无。

结论

暂不跟进。 工程上可能不错，但数据可疑（71 分、0 评论、4 star）、性能未独立复现、 产品切入点未证明。除非第三方复现了数字，否则按宣传品处理。三个月后验证。