夜雨聆风只读 MCP 小工具，从预检到报价到底怎么交付
很多草稿把预检、白名单、脱敏、权限、日志、报价拆成很多篇。单看每篇都能讲通，但连续发出去会显得像同一套方法在反复换标题。这篇我把它合成一次完整交付复盘。
假设客户想把业务系统接到 AI 助手里，让员工用自然语言查询报销、订单或客户资料。第一版我不会做写入，也不会开放原始接口，而是先做一个只读 MCP 小闭环：能查、能控、能脱敏、能审计、能验收。
这篇的结论
只读小工具不是“包一层接口”这么简单。真正要交付的是：预检能判断能不能接入，工具 schema 能限制问题范围，权限能按人控制数据，脱敏能保护敏感字段，日志能定位问题，报价能覆盖后续维护。
01 先用预检判断项目能不能做
预检不是打印环境变量，而是把项目最容易失败的地方提前暴露出来。很多 AI 小工具不是模型不行，而是凭证缺失、接口没权限、字段范围没说清、样例数据拿不到。
02 接口不要直接给 AI，先封成白名单工具
原始接口通常参数太多、字段太宽、权限太粗。更稳的做法是把高频查询封成少数白名单工具，每个工具只做一件事，只收必要参数，只返回最小字段。
{ "tool": "search_expense_reports", "input": {"date_from": "2026-06-01", "date_to": "2026-06-30", "status": "pending"}, "returns": ["单号", "申请人", "部门", "金额区间", "状态", "更新时间"], "blocked_fields": ["手机号", "银行卡", "身份证", "完整审批备注"] }这样设计的好处是，AI 只能在你定义好的边界里查。它不能绕过权限，也不能随口要求返回全部字段。
03 权限和脱敏要写在工具层，不靠提示词兜底
04 报价别按开发时间算，要按交付边界算
如果只按写接口的时间报价，这类项目很容易亏。真正耗时间的是前面的预检、字段梳理、权限边界、测试问题集、部署说明和后续维护。
05 哪些需求我会直接劝退
没有登录态、没有权限接口、没有样例数据、上来就要自动审批或自动写入、客户不愿意确认字段边界，这几类需求不适合第一版接 AI。先做只读，不是保守，而是让项目真的能交付。
如果你正在做类似的小工具：
先把输入、处理、输出和验收标准写在一张表里。
再决定要不要接 AI、要不要做后台、要不要报价。
真正能收费的，不是概念，而是能稳定跑通的一个小闭环。
