我用MCP搭了个AI工具链,两周干完了一个季度的活

上个月老板丢给我一个需求：把团队里三个不同系统的数据接进来，让AI能统一提问。如果按传统做法，先拉接口、做清洗、写中间层，三个系统至少三个月。我选了另一个路子——用MCP（Model Context Protocol）搭了一个工具链。两周跑通了。

不是什么伟大发明。就是用MCP Server把每个系统包装成一个工具，让大模型自己决定调哪个。

去年刚开始看MCP的时候，我直觉反应是"又一个协议标准"。GitHub上搜了一下，readme写得花里胡哨的，每个都说自己是下一代AI基础设施。我一个一个关掉了。

真正让我改观的是项目里一个具体的场景：我们的客服系统想查询订单状态。传统做法是训练一个模型去理解订单数据库，但训出来不准确，还费钱。MCP的思路完全不同——不需要模型理解你的数据库，只需要给模型一个SQL查询工具，它自己写SQL去查。

我当时的表情就是，靠，这么简单？

选框架不是选最强的，是选你最懂的那个。

先说环境。我们团队用的Python + FastAPI，所以MCP Server也用Python写。MCP官方出了Python SDK，pip install mcp就装好了。

核心结构就三层：

第一层，MCP Server。每个系统对应一个Server，暴露几个工具函数（tool）。比如订单系统暴露get_order、search_orders、get_refund_status。每个tool就是一个普通Python函数加个@mcp.tool()装饰器。

第二层，MCP Client。搭在AI应用层，负责发现Server有哪些tool可用，把请求转给合适的Server。这层就是几行配置代码。

第三层，LLM调度。AI收到用户问题后，自己判断"这个问题需要调什么工具"，然后调Client去执行，把结果塞回上下文。

为什么我花了三周？因为我中间走了弯路：想把三个系统硬编码进一个Server里。后来拆成了三个独立的Server，每个只管自己的事，反而好维护了。

第一个坑是工具设计。我以为暴露越多的tool越好，所以把每个表的每个字段都加了读接口。结果AI反而懵了——tool太多了，它不知道选哪个。

后来参考了OpenAI的function calling最佳实践，把tool数量控制在每个Server不超过6个，名字用动词开头（get_order而不是order）。

第二个坑是上下文管理。MCP的tool调用返回结果直接塞进LLM上下文，但订单数据动辄几KB，一次查10个订单就把上下文撑爆了。解决方案：让tool返回摘要而非全量数据，详情只在用户明确要求时才返回。

第三个坑是权限。MCP没有内置的权限模型，谁调哪个tool完全靠应用层控制。我们临时加了一层白名单——敏感操作（退款、改价）不在tool里暴露，只暴露读接口。

上线两周，每天大概500次tool调用，准确率92%左右（人工抽查）。跟之前三个系统各开一个管理后台比，客服处理一个问题的时间从平均8分钟降到了2分钟。

当然不完美。偶尔AI会调用错tool——用户问"我的订单什么时候到"，它去调了退款工具查物流。但大部分情况的回答比以前准确，因为数据是实时的。

如果你团队不到10人，别想着自研AI工具链。MCP这套够用了。

技术选型最大的坑不是选错框架，是花了两周研究框架一行代码没写。MCP让我在两周内从零到上线，这个速度比任何框架特性都重要。

不是技术多先进，是思路对——让AI用自己的方式去解决问题，而不是你逼它用你的方式。