一个简单但却强大的 MCP Server

2026-04-22

类别: 软件技术

介绍一个有意思的项目：algony-tony/mymcp。

它不是那种一上来就塞几十个 tool、再配一堆复杂编排的 MCP server，而是走了另一条路：能力面非常克制，但真正把“让 AI 安全地操作一台 Linux 机器”这件事做成了。

mymcp 是一个用 Python 写的 MCP server，面向 Claude Desktop、Claude Code、Cursor、Gemini CLI 这类 AI client，通过 Streamable HTTP 暴露 Linux 系统操作能力。

它的定位其实非常直接：

给 AI 一个受控的 Linux 操作入口。

为什么说它“简单”

这个项目最打动我的一点，就是它没有把自己做成一个“大而全平台”。

它默认只暴露 6 个 MCP tools：

tool	作用
`bash_execute`	执行 shell 命令
`read_file`	读文件
`write_file`	写文件
`edit_file`	按字符串替换编辑文件
`glob`	按模式找文件
`grep`	按内容搜索

你会发现，这 6 个工具本身都不花哨，甚至可以说非常朴素。

但问题在于：对于“让 AI 在 Linux 上完成实际任务”来说，这 6 个已经足够形成闭环了。

比如一个 agent 想排查线上服务问题，大概率就是下面这条链路：

grep 搜日志或配置；
glob 找到相关文件；
read_file 看内容；
必要时 edit_file 或 write_file 改配置；
bash_execute 重启服务、跑检查命令、看系统状态；

也就是说，mymcp 的“简单”不是功能弱，而是接口面很小，但组合起来很完整。

为什么说它“强大”

1. 真正把 Linux 控制面开放给了 AI

很多 MCP server 看起来功能不少，但真正能“干活”的闭环并不完整。

mymcp 不一样。只要你给的是 rw 权限 token，AI 基本就拿到了一个可控的 Linux 运维与自动化入口：

查文件；
改文件；
跑命令；
搜代码；
搜日志；
做批量操作；

这个能力面其实已经足够覆盖很多真实场景：

远程运维一台轻量 Linux 主机；
让 Claude Code 在另一台机器上做只读巡检；
给 agent 一个受控的“远程 shell + 文件系统”能力；
做部署前后的检查、配置修改、日志定位；

2. 权限模型足够实用

这个项目不是“有认证就算安全”，而是把权限做到了 token 粒度。

它支持两种角色：

ro：只读；
rw：可读可写；

这点非常重要，因为 MCP 真正危险的地方从来不是“能不能连上”，而是一旦连上以后，agent 能改到什么程度。

默认给只读 token，只有明确可信的客户端才给 rw，这个设计很务实。

3. 有 protected paths，不让 AI 直接改自己的命门

mymcp 会自动保护自己的安装目录和 audit log 目录，不允许通过文件类工具去读写这些路径。

这意味着 AI 不能直接：

读取 token 存储；
修改 MCP server 自己的代码；
篡改审计日志；

这种设计很关键。因为很多“给 AI 系统权限”的方案，问题不在功能不够，而在没有把最危险的那部分先隔离出来。

4. 有 audit log，出了问题能回看

项目支持 JSON Lines 格式的 audit log，记录每次 tool 调用的结果、耗时，出错时还会记错误码和错误信息。

这件事对 MCP server 尤其重要。因为一旦 AI 能执行命令、改文件，没有审计，后面很多问题都会变成“好像出过事，但不知道是谁、什么时候、用什么参数做的”。

mymcp 至少把这条线补上了。

5. 它连升级链路都想到了

这个项目不只是“能跑起来”，还认真做了部署和升级：

deploy/install.sh 一把安装；
自动建 venv；
自动注册 systemd 服务；
deploy/upgrade.sh 支持查看版本、升级、dry-run、rollback；
还支持离线 wheels 升级；

这一点很像真正面向“放到服务器上长期跑”的项目，而不是一个停留在 demo 阶段的 MCP server。

更有意思的是，它还专门考虑了从 MCP client 自己触发升级这种场景：也就是让 agent 通过 bash_execute 调用升级脚本，升级过程自动 detach，服务短暂重启后再连回来。

这就不是“玩具式 MCP”了，而是已经开始考虑真实运维过程里的自举问题。

这个项目有一个很好的取舍

我觉得 mymcp 最值得学的地方，不是某个单点功能，而是它做了一个很好的取舍：

把 MCP server 的职责控制在一个非常清晰的边界内：

不去做复杂工作流编排；
不去堆很多业务 tool；
不去绑定某个单独 AI 产品；
就专注做“受控的 Linux 能力暴露层”；

这使得它有几个优点：

容易理解；
容易部署；
容易审计；
容易和不同 client 组合；
容易做权限分层；

很多时候，工程上真正强的东西，不是“功能特别多”，而是边界清楚、默认可用、风险点提前处理过。

一个很现实的提醒

当然，这类项目的前提永远都是：它很强，所以你必须认真对待安全。

README 里也明确提醒了几件事：

新 token 默认应该优先只给 ro；
rw 只给可信 client；
最好开 audit；
网络侧要放在防火墙后面，必要时再加 TLS / 反向代理；

尤其要注意一点：bash_execute 本身不受 protected paths 机制约束。

所以这类 MCP server 的安全，不是“装上就安全”，而是“默认给最小权限，再逐步放开”。

我是怎么用的

我自己的用法，基本分成两类：

对于生产环境，或者比较重要的服务器，我只给大模型开只读权限，让它帮我做信息摸排、问题排查和应用观测。这样可以快速把现场情况摸清楚，但不会让它直接动系统。
对于自己拿来折腾、试验的服务器，我会放得更开一点，直接把运维动作几乎都交给大模型。一句话让它安装一个开源项目、跑起一个应用，甚至开发完以后顺手部署上去，能省掉不少重复又琐碎的部署运维操作。

说白了就是：重要环境让它看，实验环境让它干。