第五次搜索，还是没有

最近又有一个需求：让 Agent 帮我理解 Nacos 上的配置。

这不是第一次了。每次需要在 Agent Chat 里讨论某个服务的配置，我都会去找一下有没有现成的 Nacos MCP。理想状态很简单：Agent 能自己读取 namespace、找到相关配置、搜索关键字，然后我和它一起看配置、分析问题。

现实里，我找了不下五次，还是没有找到一个趁手的。

最后还是回到最原始的方式：打开 Nacos，复制配置，粘贴进 Chat。一个 config 文件还好；配置多起来，或者要比较 dev、test、prod 几个环境时，信息搬运就开始占据注意力。更别说发版之前，还得收集这次需要同步到 Nacos 的变更，再手动比对差异。

问题并不难，麻烦的是它总会重复出现。

后来我又遇到了 MySQL MCP 的问题。现成的工具当然有能用的，但它们往往把安全边界交给使用者和 prompt：连哪个库、能执行什么 SQL、会不会误写数据，都不够受控。

我不太喜欢这种感觉。

Agent 很会做事，也确实会偶尔理解错。让它直接拿到一个可以写库、可以跨库、可以随意切换上下文的入口，不是我想要的默认设置。

给“继续找”设一个截止时间

我现在给自己定了一个经验值：如果为了找一个工具，已经实打实花了『整整半天』，还是没找到合适的，那就该认真考虑自己做一个。

注意，这里的半天不是“这个需求挂在待办里半天”，而是真的花了一个『整整半天』去搜索、安装、配置、试用、看文档，然后发现每个方案都有一点水土不服。

这个判断不是说开源工具不值得用。恰恰相反，大部分时候我还是会优先找成熟方案。成熟工具意味着维护者、用户、文档、踩坑记录，没必要什么都从零开始。

但也不能因为“最好先找现成的”，就把它变成不可动摇的前提。

当一个需求足够贴身，而且会反复出现时，继续迁就一个不完全合适的工具，代价会慢慢积累：今天多复制几段配置，明天多确认一次环境，后天又花时间解释“这次不能执行写操作”。这些零散成本最后并不比写一个小工具低。

以前自己造工具，意味着要搭框架、补接口、写大量胶水代码。现在不一样了。你只要能把需求和边界想清楚，LLM 已经能帮你很快把骨架搭起来，把大部分机械劳动压缩掉。

真正稀缺的，不再是“有没有能力写”，而是“有没有决断不再继续凑合”。

Nacos：让配置自己走进对话

于是我做了 just-a-nacos-mcp。

https://github.com/xingyuli/just-a-nacos-mcp

它没有试图做成一个无所不能的 Nacos 管理客户端，只做几件和 Agent 协作最相关的事：

• 列出可访问的 namespace；
• 在指定 namespace 中列出配置，并按 dataId 或 group 模糊筛选；
• 获取一份配置的完整内容和元数据，例如类型、MD5、创建时间；
• 按配置内容搜索，找出包含某个关键字的配置。

这样一来，讨论就不再从“我先复制一份 YAML 给你”开始。

比如，Agent 可以先找出包含 redis 的配置；需要时再读取具体内容；如果要判断某次发布涉及哪些配置，也可以先把几个环境里相关配置拉出来，再做整理和比较。

它只读，不提供写操作。

这是刻意的选择。配置写错 namespace，或者在不该改的时候改了一份生产配置，后果并不会因为执行者是 Agent 而变轻。能做，不等于应该做。

MySQL：边界不能只写在 prompt 里

MySQL 那个工具的出发点也差不多，不过我更在意边界是否足够硬。

just-a-mysql-mcp

https://github.com/xingyuli/just-a-mysql-mcp

它可以让 Agent 浏览表结构、查看字段，以及执行只读查询。但“只读”不是写在工具说明里的建议，而是一层层做成实际约束：

• 一个 MCP 进程只绑定到指定数据库的 allowlist；
• 可以设置默认库，但访问到的每个库都必须在 allowlist 中；
• 只允许 SELECT、WITH ... SELECT、SHOW、DESCRIBE、EXPLAIN；
• 一次只能执行一条语句，USE 被拒绝；
• SQL 会通过 sqlglot 解析，解析失败也会 fail closed；
• 查询结果默认最多返回 100 行，最多不超过 1000 行，并明确标记是否被截断；
• 最好再配一个真正只读的 MySQL 账号，做第二层保险。

这里最关键的一点是：不要把安全要求全放在 prompt 里。

你当然可以告诉 Agent：“只能查 app_dev，不能写数据。”但这个约束是否真的生效，取决于它每一次有没有正确理解。相比之下，让工具从入口就只能看到 app_dev，并在 SQL 层面拒绝越界访问，才是一个更让我安心的默认值。

Agent 应该在明确的边界内变得更有能力，而不是在无限的权限里祈祷它始终小心。

小而专，不是重复造轮子

“自己造轮子”经常带着一点贬义，好像只要不是通用、成熟、被很多人使用的东西，就不值得做。

但我觉得这里要区分两件事。

如果你是在重做一个已经成熟、复杂、通用的问题，而且没有新的约束、没有新的场景，那大概率确实是在浪费时间。

但如果你要解决的是一个自己每天都在遇到的、边界明确的问题，一个小而专的工具反而可能比通用工具更好用。

它不需要考虑所有数据库方言，不需要支持所有 Nacos 版本，也不需要做一个完整的运维平台。它只需要服务好一个目的：让 Agent 在我允许的范围内，高效地拿到我需要的信息。

这也是我喜欢把它们叫作 just-a-* 的原因。

它们不是什么 MCP 平台，也不想成为 MCP 平台。它们只是刚好适合我现在工作流的两把小工具。

不要被旧习惯困住

传统开发里，我们习惯先找一个开源项目、成熟框架或者 SaaS，把需求尽可能塞进它已有的形状里。

这套习惯没有错，但在 Agent 时代，它不该再是唯一的路径。

当你已经确认需求会持续存在，现成工具又始终差一口气时，不妨停下来问一句：我到底是在节省时间，还是只是不愿意开始？

给搜索一个『整整半天』的机会，已经很公平了。半天之后还不趁手，就试着自己锻造一个。

不一定要做成开源项目，不一定要有完整 UI，也不一定要让所有人都能用。先做一把只适合自己的兵器就够了。

如果你也有从 Agent 中读取 Nacos 配置，或者在严格只读边界下查询 MySQL 的需求，可以试试上面两个 MCP。即便它们不完全适合你，我也希望它们至少能证明一件事：现在，做一个贴身的小工具，已经没有以前想象中那么遥远了。