夜雨聆风最近MCP也是比较火爆，有粉丝留言说：
“我以前以为 MCP 工具就是把一个接口包起来，后来发现最难的是让它边界清楚。”
一个企业 AI 小工具能不能稳定，很多时候不是模型问题，而是工具定义一开始就太含糊。工具说不清，AI 调用时就容易猜；返回值太杂，回答就容易飘。
MCP 工具不是把接口名包一层就完了。真正可交付的工具，要把名称、描述、参数、必填字段、错误返回、最小字段和脱敏规则都设计清楚，让 AI 用得对，也让客户看得懂。
01 MCP 工具的名字和描述，决定 AI 会不会用错
工具名称不要写得太泛，比如 query、search、call_api 这种名字，模型很难判断该什么时候用。更稳的写法是围绕业务动作命名，比如：
search_departments、get_staff_summary、preflight_connection、resolve_actor_access。
描述也要明确告诉 AI：这个工具能做什么，不能做什么，返回哪些字段，是否只读，是否会脱敏。不要假设模型会从代码里理解边界，边界要写在工具说明里。
02 参数设计越克制，工具越不容易失控
参数不是越灵活越好。企业工具的第一目标不是让 AI 想怎么调就怎么调，而是让它在有限边界内稳定完成任务。
几个关键点：
第一，能用枚举就不要放任意字符串，比如身份类型、查询范围、状态类型。
第二，能拆成明确字段就不要塞一个自由文本。
第三，count、page、date 这类参数要有范围。
第四，涉及敏感输出时，一定要有 includeSensitive 这类显式开关，并且由工具层再做权限校验。
03 返回值要给最小可用结果，不要把整包数据丢出来
列表工具只返回列表需要的字段，比如 ID、名称、状态、父级 ID、是否启用。详情工具也要分层，默认返回摘要，需要更多字段时再设计单独工具或权限开关。
错误返回同样要结构化。比如 AUTH_FAILED、PERMISSION_DENIED、NOT_FOUND、NETWORK_ERROR、VALIDATION_ERROR。
AI 拿到明确错误码，才能把问题解释清楚，而不是胡乱猜测。
04 一个好工具，最后要能被人审一遍
写完工具后，你可以像做代码评审一样问四个问题：名字是否清楚，参数是否过宽，返回值是否过多，失败时是否能解释。如果这四个问题都能回答清楚，这个工具才像一个可交付组件。
企业 AI 小工具的技术可信度，不是来自接了多少接口，而是每个接口都被设计成可控、可测、可解释的工具。
可复制资产：一个工具 schema 的最小样例
这一段建议直接收藏，后面做交付、报价或复盘时可以拿出来复用。
name：search_objects，围绕业务动作命名。
description：说明只读、返回最小字段、默认脱敏。
inputSchema：keyword、count、actor，不放任意原始 SQL 或接口路径。
output：items、matched、errorType、traceId。
脱敏案例：同一个查询，如果叫 call_api，AI 会把它当万能接口；如果叫 search_readonly_objects，并写清只返回摘要，它的调用会稳定很多。
行业都在谈降本增效，程序员该怎么理解
最近刷到好多同行吐槽：公司一喊降本增效，就怕自己是那个 "被降的本"😱其实真不用先慌！换个角度想：这反而能帮你筛选出真正有价值的工作！别再闷头写重复代码、做可替代的基础任务了！赶紧把精力转向能直接提升业务效率的事 —— 比如优化核心流程、搭建可复用工具、主动帮业务部门解决实际问题！毕竟，能帮公司 "增效" 的人，才是永远不会被 "降" 的那个人！
你们公司降本增效有啥具体操作？有没有让你反而更忙了？来评论区唠唠
如果你也是：
正在把 AI 从聊天框接到真实业务流程里的程序员
希望先做安全、只读、可验收的小工具，而不是一上来做大平台的人
想把技术能力慢慢沉淀成案例、报价和第二收入的中年码农
回复「schema」可以拿一份 MCP 工具 schema 模板；先把工具契约写清楚，再去接真实接口。
我会继续把这些小工具的真实边界、技术细节和交付方法拆开写。
