先给结论AI Agent接上工具之后依然难用问题通常不是模型不够聪明而是工具这一层太乱。我过去带过好几个工具接入项目最常见的状态是OpenAPI文档塞给Agent函数调用也配了Demo能跑一上真实业务就崩。崩的地方不是模型而是工具定义含糊、返回内容超长、各家平台协议各搞一套。MCPModel Context Protocol解决的正是工具接入的标准化问题——它像一套通用“插头”让公司内部系统用统一协议被Agent发现、调用、返回结果。这篇文章是一个实战拆解穿插可直接复用的代码适合正在排查Agent工具接入问题的开发者也适合准备把内部系统安全接入AI的架构师。1. 先聊清楚Agent“接工具”到底卡在哪1.1 工具调用的三大坑先说最常见的现象你给Agent接了一个查询接口模型也知道这个工具的存在但实际跑起来不是参数传错就是结果返回一坨没用的JSON最后模型只能靠猜。我总结下来问题基本集中在三个地方。第一个坑是工具定义不够“模型友好”。很多团队直接把内部接口的参数名抄过来比如cust_id、flag、page_size。模型不是你们公司的老员工它不知道cust_id到底要传数字还是字符串也不知道flag代表什么含义。工具描述写得太模糊模型就只能瞎猜猜错之后你会看到一连串的“工具调用失败重新尝试”。第二个坑是上下文爆炸。Agent每次决定要不要调用工具都要把工具说明和参数结构塞进提示词里。如果你接入的工具一多或者某个接口的OpenAPI文档特别长模型有限的上下文窗口很快就被挤占。更糟糕的是工具返回结果往往带着大量无关字段比如一次工单查询返回了全套对象处理人、创建时间、历史备注、内部标记全在里面。模型处理这些噪点数据不仅费token还会被无关字段干扰。第三个坑是结果格式语义不一致。有的接口返回JSON有的返回XML还有的返回一段HTML片段。模型为了从这些结构里提取关键信息要做大量额外解析。工单状态字段可能叫status也可能叫state还可能叫currentStatus。模型不是一个小型ETL工具你让它每次调用都猜字段效果自然好不了。1.2 为什么每个Agent平台都在造轮子更麻烦的是不同Agent平台对“工具”的定义完全不一样。比如某个平台用函数调用协议另一个平台用工具调用协议还有的平台倾向于给Agent塞一段“可以执行的指令文本”。同一个公司内部系统想同时接入多个Agent能力就要写多套适配层。我见过一个团队内部API已经挺规范了结果为了同时对接两个Agent平台写了两个适配服务每个服务里都是重复的参数映射、错误处理、字段转换。本质原因就是工具接入缺少统一标准。模型厂商各自发展出自己的工具协议但企业内部系统不可能跟着每个平台改一遍。MCP的意义就在这里它试图定义一个模型无关、传输无关的标准化接口让系统接入一次到处复用。与其说是“把工具接给Agent”不如说是“给每个Agent都准备一个统一的插头”。1.3 MCP是什么用USB-C类比MCP全称Model Context Protocol核心思路可以拿USB-C来理解。过去各种设备都有自己的充电接口现在换成一个通用口。MCP就是AI应用和工具系统之间的USB-C只要工具端实现了这个协议任何支持MCP的Agent客户端都可以直接接入。MCP架构里通常有三个角色模型也就是大语言模型本身宿主也就是Agent运行环境或客户端服务器也就是你业务系统的协议封装层。宿主负责和模型对话同时通过MCP客户端与MCP服务器通信。业务系统不需要理解模型逻辑只需要实现MCP服务器的能力列表和调用接口。这意味着被接入的系统既不关心模型是哪个厂商也不关心宿主是什么产品只需要守好协议这一端。对做基础设施的团队来说这是很大的解耦收益。2. MCP的核心模型与工作方式2.1 从“工具列表函数调用”到“MCP Server/Client”如果你之前了解过函数调用你会发现MCP并没有发明特别玄乎的东西本质上还是“声明能力、接收调用、返回结果”。但它把这套过程整理成了标准协议并且明确区分了Server和Client的职责。MCP Client跑在宿主侧负责发现MCP Server、发送请求、接收结果。MCP Server跑在业务侧负责向Client声明自己能干什么、怎么调用。在链路里宿主把MCP Server提供的工具列表和描述交给模型模型根据用户需求决定调用哪个工具宿主再把调用请求转给MCP Server。整个过程基于JSON-RPC 2.0消息格式。这个设计的好处是协议层不关心你的业务逻辑到底是什么。你可以封装一个查询工单的工具也可以封装一个提交审批的动作工具可以是只读查询也可以是高风险写操作。业务系统只需要考虑如何在MCP Server里安全地暴露这些能力。2.2 三大核心能力Tools、Resources、PromptsMCP协议不是只定义了工具调用它还规定了另外两类能力Resources和Prompts。刚开始接触时容易混淆我用一个场景说清楚。以工单系统为例Tools是“动作”比如“根据工单ID查询状态”模型决定什么时候调用调用后会产生结果。Resources是“数据源”比如“最近未完成工单列表”它们像是可以被读取的上下文Agent可以在回答问题时主动消费。Prompts是“提示模板”比如“标准故障排查流程”它们用来规范模型处理某类任务的方式。实际接入时最常见的还是Tools因为大多数企业系统希望让Agent具备“干活”的能力。但Resources也很值得重视很多高频、只读的数据与其让模型反复调用工具不如作为Resource直接注入上下文。比如内部知识库、服务目录、值班名单这些内容不经常变做成Resource比做成Tool更合适。2.3 传输层与生命周期stdio、SSE、initialize握手MCP支持多种传输方式最常用的两个是stdio和SSE/HTTP。stdio模式下MCP Server作为宿主启动的子进程存在Client和Server通过标准输入输出交换消息。这种方式非常适合本地开发、命令行工具、桌面Agent客户端因为不需要暴露网络端口也没有跨域和鉴权问题。SSE/HTTP模式适合远程部署。MCP Server可以独立跑在某个内部服务器上通过HTTP端口对外提供能力客户端通过网络连接。企业级落地时通常用这种模式因为工具服务可以独立扩展、独立部署、独立升级。无论哪种传输一次完整会话都要先完成initialize握手。客户端发起初始化请求带上协议版本和客户端能力信息服务器返回支持的能力和服务器信息。握手通过之后Client才能调用tools/list获取工具列表再进一步发起tools/call。这一步很容易被忽略很多排查案例里工具列表为空或调用超时其实是握手阶段没走通。3. 实战写一个MCP Server把公司工单系统接进Agent3.1 环境准备与项目结构我用一个简化但完整的例子演示整个接入过程把某内部工单系统封装成MCP Server再写一个Client完成发现和调用。我用Python实现原因是MCP官方Python SDK比较成熟代码量也少。先创建项目目录mkdir mcp-ticket-server cd mcp-ticket-server python -m venv .venv source .venv/bin/activate pip install mcp[cli] httpx项目结构不需要太复杂mcp-ticket-server/ ├── server.py ├── client.py └── internal_api.pyinternal_api.py模拟内部系统的真实HTTP调用server.py把内部API包装成MCP Toolclient.py用来快速验证整条链路。生产环境里internal_api.py可能是一个跨系统的SDK也可能是一组HTTP封装。3.2 实现工单查询工具先用FastMCP封装一个查询工单状态的能力。FastMCP是MCP SDK提供的一个高层封装代码写起来接近普通函数定义非常直观。# server.py from typing import Any from mcp.server.fastmcp import FastMCP mcp FastMCP( ticket-service, instructions提供工单系统查询能力。工单ID格式为 TK-日期-序号例如 TK-20250617-001。 ) def _query_ticket_api(ticket_id: str) - dict[str, Any]: # 实际生产环境请替换为内部工单系统的HTTP请求 return { ticket_id: ticket_id, status: processing, assignee: 客服-王工, updated_at: 2025-06-17T14:30:0008:00, summary: 支付模块偶发 5xx 报错正在排查, customer_name: **科技 } mcp.tool() def get_ticket_status(ticket_id: str) - dict[str, Any]: 根据工单ID查询工单状态、处理人、最近更新时间。 Args: ticket_id: 工单ID格式为 TK-20250617-001。 if not ticket_id or not ticket_id.startswith(TK-): return { error: invalid_ticket_id, expected_format: TK-YYYYMMDD-NNN, } return _query_ticket_api(ticket_id) mcp.tool() def search_tickets(keyword: str, limit: int 5) - list[dict[str, Any]]: 按关键词搜索工单标题返回最近匹配的工单列表。 Args: keyword: 搜索关键词例如“支付”。 limit: 返回数量最大为10。 limit min(max(limit, 1), 10) return [ { ticket_id: TK-20250617-001, status: processing, summary: f支付模块日志出现{keyword}相关报错, } ] if __name__ __main__: mcp.run(transportstdio)这里有两个值得注意的点。第一instructions字段是我后期迭代时加的高频技巧它告诉MCP Server在把工具描述提供给模型时可以附带一句“工单ID格式说明”。模型不用猜参数传错率会明显下降。第二工具函数里的docstring和参数注释会被SDK解析成为模型看到的能力描述。描述写不清楚等于把模型扔进黑盒。启动服务的方式很简单python server.py这个进程在stdio模式下不会主动输出日志而是等待Client通过标准输入发起请求。你可以在终端看到它挂在那里这属于正常现象。3.3 扩展把公司内部API包成Resource除了Tools我再展示一下Resources的用法。比如“最近工单概况”这个信息Agent经常需要在回答前快速了解当前服务情况与其反复调用工具不如把它做成一个可读取的Resource。# server.py 追加 mcp.resource(ticket://recent) def recent_tickets() - str: 最近工单概况供模型直接读取。 return \n.join([ TK-20250617-001 processing 支付模块偶发5xx, TK-20250617-002 waiting 用户反馈账单下载失败, ])这样设置之后模型端可以把ticket://recent当作一个“数据源上下文”来消费。实际接入时你可以把内部运维手册、服务目录、值班表等都做成Resources帮助Agent在回答前建立背景知识。不过要提醒你Resource不能滥用。如果内容变化太频繁或者每次访问成本很高就不适合全部塞进Resource。高频动态数据仍然应该走Tool让模型按需查询。3.4 在Agent侧挂载MCP Client写一个简单的Client来验证整个服务是否正常。你需要确认Client与Server能力匹配协议版本兼容。# client.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params StdioServerParameters( commandpython, args[server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await session.list_tools() print(discovered tools:, [t.name for t in tools]) result await session.call_tool( get_ticket_status, arguments{ticket_id: TK-20250617-001}, ) if result.isError: print(call failed:, result.content) else: # 结果是一个内容块列表第一个通常是文本 for item in result.content: text getattr(item, text, None) if text: print(text) if __name__ __main__: asyncio.run(main())运行Clientpython client.py正常情况下你会先看到discovered tools: [get_ticket_status, search_tickets]然后看到工单查询结果。如果这一步通了说明MCP Server和Client链路是完整的。如果你用的是桌面端Agent客户端大部分实现支持在配置文件里声明mcpServers本质上是让宿主帮你启动这样一个stdio子进程并完成同样的握手。你可以把server.py包装成一条启动命令配置进去。自己写Client只是为了调试链路更可控生产环境里你不见得需要自己实现Client。4. 代码之外的工程细节权限、安全与性能4.1 别把所有工具一股脑暴露很多团队一上来就把企业内部API全量包成MCP Tool模型立刻获得了巨大操作面。这是最危险的用法。工具一旦暴露给模型模型就能在用户请求的引导下发起调用而模型并不真正理解权限边界。我建议按“最小暴露面”原则设计工具清单。一个内部系统不是所有接口都需要暴露也不是所有接口都适合暴露给Agent。白名单要人工审核每一类工具都要明确以下内容表格列出建议工具名称内部API操作类型建议暴露范围审批要求工单查询GET /tickets/{id}只读全员可用无需工单修改状态POST /tickets/{id}/status写操作仅管理员需要二次确认删除工单DELETE /tickets/{id}高危禁止暴露禁止客户信息查询GET /customers/{id}只读白名单用户需要审计另外不要在MCP Server内部省略鉴权。很多人觉得“反正只有Agent客户端能连”就放松了内部认证。可Agent可能被提示词注入诱导去调用某个高危工具比如“帮我删掉昨天的工单”。如果Server层没有权限校验最后一道防线就没了。实际接入时MCP Server应该像任何内部API服务一样做身份认证、参数校验、权限判断和审计日志。4.2 返回结果的结构化给模型“省点力气”模型能稳定处理的数据结构通常比我们想象中更简单。我建议所有Tool返回统一的结构至少包含状态、数据和元信息三层{ status: ok, data: {}, meta: { truncated: false, next_cursor: null } }如果查询结果很大不要让模型一次性吞下全部数据。服务端可以先做截断或分页返回前面若干条并把总条数和下一页游标放进meta。模型需要更多数据时再调用另一个分页工具继续取。我试过把工具返回值从“原生接口JSON”改成“摘要化文本”之后Agent回答准确率有了肉眼可见的提升。原因是原生接口里无关字段太多模型容易把一个不相干的值当成关键信息。对于只读查询类工具你甚至可以直接生成一版“人话摘要”给模型效果往往更好。4.3 并发与连接管理stdio模式方便但每次启动都是一个子进程。一个MCP Server进程被启动后通常对应一个客户端会话。如果你在Web服务里每次请求都新建一个stdio子进程会带来很大的资源开销。生产环境建议优先用SSE/HTTP模式部署远程MCP Server把连接管理交给专门的HTTP服务框架。对于并发要求高的工具要注意Server端的接口实现是否支持异步避免一个慢查询阻塞其他工具调用。另外要给工具调用设超时时间尤其某些内部API本身响应就很慢Agent等待超时后会误以为工具不可用反复重试放大问题。5. 常见问题与排错速查5.1 握手失败、工具列表为空、调用超时我把实践中遇到最多的问题排查整理成了速查表现象可能原因处理办法initialize握手失败协议版本不兼容升级SDK核对MCP协议版本工具列表为空Server端没有注册Tool或装饰器没生效检查工具函数是否被mcp.tool()装饰调用时报参数格式错误参数类型与Schema不一致检查函数签名与docstring参数名尽量语义化调用超时内部API响应太慢在Server端增加缓存给内部调用设置合理超时中文内容乱码stdio默认编码不一致确保Server进程以UTF-8编码输出环境变量正确设置工具描述是乱码docstring没有被官方识别改用英文中文双语描述避免奇怪的换行这里特别说一下参数错误。MCP Server从模型手里拿到的参数是JSON格式FastMCP会把它们映射到Python函数参数。如果模型传了None或字符串数字类型转换可能失败。我的经验是在公司内部工具的参数定义里尽量都用字符串不要用复杂嵌套结构。模型对简单的扁平参数最稳定嵌套太深容易出问题。5.2 上下文太长怎么办工具接入越多模型需要感知的工具描述就越多上下文压力随之增加。我常用的手段有三种。第一精简工具描述。描述不是写文档不要长篇大论。每个工具控制在两三句话内把关键约束放在开头。第二给工具分组。让Agent只在特定任务场景下才加载某组工具而不是把所有工具都平铺给模型。第三对返回结果做摘要。工具返回结果不要一次性全给能返回标题列表的就不要返回正文全文。另外可以利用MCP协议里的Resource能力把那些经常变化的公共背景数据放到单独资源里而不是跟随每次工具调用重复发送。上下文管理是Agent应用落地里最吃功夫的地方没有一劳永逸的配置只有持续观察和裁剪。5.3 避坑心得我自己踩过几次比较深的坑分享出来你也许能少走弯路。第一不要在MCP Server里写复杂状态。MCP Tool的设计哲学是无状态优先。如果需要跨多轮记住用户选择应该把状态放到宿主侧或业务系统里而不是依赖MCP Server进程的全局变量。第二不要在工具返回里塞Markdown表格。有些模型对表格的解析不稳定遇到复杂表格容易丢字段。返回纯文本或者扁平JSON更稳妥。第三不要把内部错误堆栈直接返回给模型。模型会一本正经地阅读堆栈并给出误导性结论。Server侧要做错误归一化把内部异常转换成“工具调用失败业务原因是XXX”这样清晰的信息。第四一定要加审计日志。记录模型实际调用过哪些工具、传了哪些参数、结果是什么。这不仅是合规要求也是排查模型行为异常最直接的手段。我见过一些诡异问题最后都是靠审计日志发现模型在一次长对话里连续调用了十几次查询工具把内部系统流量打爆了。6. 从一个小工具到全公司接入落地建议6.1 分阶段接入策略我不建议一开始就搞“全系统统一接入平台”太高估组织推进力了。比较稳妥的做法是先选一个只读、低风险、调用链路短的系统比如工单查询、服务目录、状态页跑通端到端流程。第一个阶段只需要一个MCP Server、两三个Tool。主要是验证协议通不通、模型吃不吃这套描述、内部网络能不能稳定连接。第二个阶段再接入带写操作但可回滚的场景比如工单评论、状态流转。写操作一定要在Server层做二次确认和权限校验。第三个阶段才考虑统一配置管理、多Server发现、全公司规范化推广。过程中的关键不是技术复杂度而是“让模型真的把工具用对”。每个阶段都要收集模型调用工具的日志看哪些描述模型总是理解错误然后反过去改工具描述。工具接入不是一次性开发而是持续优化提示词和参数Schema的过程。6.2 可观测性与审计落地MCP之后很快会面临一个新问题如何知道Agent到底在干什么。MCP协议本身只负责通信不负责观测。我建议在MCP Server层埋点把每条工具调用记录到内部日志系统。重点记录请求ID、会话ID、工具名称、入参、出参摘要、耗时、是否成功。有了日志你才能回答几个关键问题模型是不是总在重复调用同一个工具是不是传入了异常参数是不是在深夜自动触发批量操作这些问题靠网关日志和内部平台监控都能发现。MCP不是魔法接入只是第一步之后的数据运营决定了这个能力是好用还是灾难。6.3 最后说点个人体会真把MCP接入到公司系统之后我最大的感受是协议本身不复杂复杂的是你终于开始认真思考“工具到底应该长什么样”。过去大家写API对象是工程师字段全一点没关系现在写工具对象是模型和不懂系统的最终用户描述必须精准返回必须克制权限必须前置。我个人在给公司系统接Agent时踩得最重的一跤是把所有数据库查询都包装成了工具。模型有时候会拿一个模糊的用户名去查全表业务数据库根本扛不住。后来我给每个工具都加了成本预估字段并把工具描述改成“必须带上明确ID才能调用”效果才稳定下来。这件事教会我MCP的“插头”只是连接标准化真正的质量还是要靠工具设计者的克制和判断。接进去之前先问自己一句这个工具真的需要给模型吗如果答案不是非常坚定就先不要接入。
先给结论AI Agent接上工具之后依然难用问题通常不是模型不够聪明而是工具这一层太乱。我过去带过好几个工具接入项目最常见的状态是OpenAPI文档塞给Agent函数调用也配了Demo能跑一上真实业务就崩。崩的地方不是模型而是工具定义含糊、返回内容超长、各家平台协议各搞一套。MCPModel Context Protocol解决的正是工具接入的标准化问题——它像一套通用“插头”让公司内部系统用统一协议被Agent发现、调用、返回结果。这篇文章是一个实战拆解穿插可直接复用的代码适合正在排查Agent工具接入问题的开发者也适合准备把内部系统安全接入AI的架构师。1. 先聊清楚Agent“接工具”到底卡在哪1.1 工具调用的三大坑先说最常见的现象你给Agent接了一个查询接口模型也知道这个工具的存在但实际跑起来不是参数传错就是结果返回一坨没用的JSON最后模型只能靠猜。我总结下来问题基本集中在三个地方。第一个坑是工具定义不够“模型友好”。很多团队直接把内部接口的参数名抄过来比如cust_id、flag、page_size。模型不是你们公司的老员工它不知道cust_id到底要传数字还是字符串也不知道flag代表什么含义。工具描述写得太模糊模型就只能瞎猜猜错之后你会看到一连串的“工具调用失败重新尝试”。第二个坑是上下文爆炸。Agent每次决定要不要调用工具都要把工具说明和参数结构塞进提示词里。如果你接入的工具一多或者某个接口的OpenAPI文档特别长模型有限的上下文窗口很快就被挤占。更糟糕的是工具返回结果往往带着大量无关字段比如一次工单查询返回了全套对象处理人、创建时间、历史备注、内部标记全在里面。模型处理这些噪点数据不仅费token还会被无关字段干扰。第三个坑是结果格式语义不一致。有的接口返回JSON有的返回XML还有的返回一段HTML片段。模型为了从这些结构里提取关键信息要做大量额外解析。工单状态字段可能叫status也可能叫state还可能叫currentStatus。模型不是一个小型ETL工具你让它每次调用都猜字段效果自然好不了。1.2 为什么每个Agent平台都在造轮子更麻烦的是不同Agent平台对“工具”的定义完全不一样。比如某个平台用函数调用协议另一个平台用工具调用协议还有的平台倾向于给Agent塞一段“可以执行的指令文本”。同一个公司内部系统想同时接入多个Agent能力就要写多套适配层。我见过一个团队内部API已经挺规范了结果为了同时对接两个Agent平台写了两个适配服务每个服务里都是重复的参数映射、错误处理、字段转换。本质原因就是工具接入缺少统一标准。模型厂商各自发展出自己的工具协议但企业内部系统不可能跟着每个平台改一遍。MCP的意义就在这里它试图定义一个模型无关、传输无关的标准化接口让系统接入一次到处复用。与其说是“把工具接给Agent”不如说是“给每个Agent都准备一个统一的插头”。1.3 MCP是什么用USB-C类比MCP全称Model Context Protocol核心思路可以拿USB-C来理解。过去各种设备都有自己的充电接口现在换成一个通用口。MCP就是AI应用和工具系统之间的USB-C只要工具端实现了这个协议任何支持MCP的Agent客户端都可以直接接入。MCP架构里通常有三个角色模型也就是大语言模型本身宿主也就是Agent运行环境或客户端服务器也就是你业务系统的协议封装层。宿主负责和模型对话同时通过MCP客户端与MCP服务器通信。业务系统不需要理解模型逻辑只需要实现MCP服务器的能力列表和调用接口。这意味着被接入的系统既不关心模型是哪个厂商也不关心宿主是什么产品只需要守好协议这一端。对做基础设施的团队来说这是很大的解耦收益。2. MCP的核心模型与工作方式2.1 从“工具列表函数调用”到“MCP Server/Client”如果你之前了解过函数调用你会发现MCP并没有发明特别玄乎的东西本质上还是“声明能力、接收调用、返回结果”。但它把这套过程整理成了标准协议并且明确区分了Server和Client的职责。MCP Client跑在宿主侧负责发现MCP Server、发送请求、接收结果。MCP Server跑在业务侧负责向Client声明自己能干什么、怎么调用。在链路里宿主把MCP Server提供的工具列表和描述交给模型模型根据用户需求决定调用哪个工具宿主再把调用请求转给MCP Server。整个过程基于JSON-RPC 2.0消息格式。这个设计的好处是协议层不关心你的业务逻辑到底是什么。你可以封装一个查询工单的工具也可以封装一个提交审批的动作工具可以是只读查询也可以是高风险写操作。业务系统只需要考虑如何在MCP Server里安全地暴露这些能力。2.2 三大核心能力Tools、Resources、PromptsMCP协议不是只定义了工具调用它还规定了另外两类能力Resources和Prompts。刚开始接触时容易混淆我用一个场景说清楚。以工单系统为例Tools是“动作”比如“根据工单ID查询状态”模型决定什么时候调用调用后会产生结果。Resources是“数据源”比如“最近未完成工单列表”它们像是可以被读取的上下文Agent可以在回答问题时主动消费。Prompts是“提示模板”比如“标准故障排查流程”它们用来规范模型处理某类任务的方式。实际接入时最常见的还是Tools因为大多数企业系统希望让Agent具备“干活”的能力。但Resources也很值得重视很多高频、只读的数据与其让模型反复调用工具不如作为Resource直接注入上下文。比如内部知识库、服务目录、值班名单这些内容不经常变做成Resource比做成Tool更合适。2.3 传输层与生命周期stdio、SSE、initialize握手MCP支持多种传输方式最常用的两个是stdio和SSE/HTTP。stdio模式下MCP Server作为宿主启动的子进程存在Client和Server通过标准输入输出交换消息。这种方式非常适合本地开发、命令行工具、桌面Agent客户端因为不需要暴露网络端口也没有跨域和鉴权问题。SSE/HTTP模式适合远程部署。MCP Server可以独立跑在某个内部服务器上通过HTTP端口对外提供能力客户端通过网络连接。企业级落地时通常用这种模式因为工具服务可以独立扩展、独立部署、独立升级。无论哪种传输一次完整会话都要先完成initialize握手。客户端发起初始化请求带上协议版本和客户端能力信息服务器返回支持的能力和服务器信息。握手通过之后Client才能调用tools/list获取工具列表再进一步发起tools/call。这一步很容易被忽略很多排查案例里工具列表为空或调用超时其实是握手阶段没走通。3. 实战写一个MCP Server把公司工单系统接进Agent3.1 环境准备与项目结构我用一个简化但完整的例子演示整个接入过程把某内部工单系统封装成MCP Server再写一个Client完成发现和调用。我用Python实现原因是MCP官方Python SDK比较成熟代码量也少。先创建项目目录mkdir mcp-ticket-server cd mcp-ticket-server python -m venv .venv source .venv/bin/activate pip install mcp[cli] httpx项目结构不需要太复杂mcp-ticket-server/ ├── server.py ├── client.py └── internal_api.pyinternal_api.py模拟内部系统的真实HTTP调用server.py把内部API包装成MCP Toolclient.py用来快速验证整条链路。生产环境里internal_api.py可能是一个跨系统的SDK也可能是一组HTTP封装。3.2 实现工单查询工具先用FastMCP封装一个查询工单状态的能力。FastMCP是MCP SDK提供的一个高层封装代码写起来接近普通函数定义非常直观。# server.py from typing import Any from mcp.server.fastmcp import FastMCP mcp FastMCP( ticket-service, instructions提供工单系统查询能力。工单ID格式为 TK-日期-序号例如 TK-20250617-001。 ) def _query_ticket_api(ticket_id: str) - dict[str, Any]: # 实际生产环境请替换为内部工单系统的HTTP请求 return { ticket_id: ticket_id, status: processing, assignee: 客服-王工, updated_at: 2025-06-17T14:30:0008:00, summary: 支付模块偶发 5xx 报错正在排查, customer_name: **科技 } mcp.tool() def get_ticket_status(ticket_id: str) - dict[str, Any]: 根据工单ID查询工单状态、处理人、最近更新时间。 Args: ticket_id: 工单ID格式为 TK-20250617-001。 if not ticket_id or not ticket_id.startswith(TK-): return { error: invalid_ticket_id, expected_format: TK-YYYYMMDD-NNN, } return _query_ticket_api(ticket_id) mcp.tool() def search_tickets(keyword: str, limit: int 5) - list[dict[str, Any]]: 按关键词搜索工单标题返回最近匹配的工单列表。 Args: keyword: 搜索关键词例如“支付”。 limit: 返回数量最大为10。 limit min(max(limit, 1), 10) return [ { ticket_id: TK-20250617-001, status: processing, summary: f支付模块日志出现{keyword}相关报错, } ] if __name__ __main__: mcp.run(transportstdio)这里有两个值得注意的点。第一instructions字段是我后期迭代时加的高频技巧它告诉MCP Server在把工具描述提供给模型时可以附带一句“工单ID格式说明”。模型不用猜参数传错率会明显下降。第二工具函数里的docstring和参数注释会被SDK解析成为模型看到的能力描述。描述写不清楚等于把模型扔进黑盒。启动服务的方式很简单python server.py这个进程在stdio模式下不会主动输出日志而是等待Client通过标准输入发起请求。你可以在终端看到它挂在那里这属于正常现象。3.3 扩展把公司内部API包成Resource除了Tools我再展示一下Resources的用法。比如“最近工单概况”这个信息Agent经常需要在回答前快速了解当前服务情况与其反复调用工具不如把它做成一个可读取的Resource。# server.py 追加 mcp.resource(ticket://recent) def recent_tickets() - str: 最近工单概况供模型直接读取。 return \n.join([ TK-20250617-001 processing 支付模块偶发5xx, TK-20250617-002 waiting 用户反馈账单下载失败, ])这样设置之后模型端可以把ticket://recent当作一个“数据源上下文”来消费。实际接入时你可以把内部运维手册、服务目录、值班表等都做成Resources帮助Agent在回答前建立背景知识。不过要提醒你Resource不能滥用。如果内容变化太频繁或者每次访问成本很高就不适合全部塞进Resource。高频动态数据仍然应该走Tool让模型按需查询。3.4 在Agent侧挂载MCP Client写一个简单的Client来验证整个服务是否正常。你需要确认Client与Server能力匹配协议版本兼容。# client.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params StdioServerParameters( commandpython, args[server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await session.list_tools() print(discovered tools:, [t.name for t in tools]) result await session.call_tool( get_ticket_status, arguments{ticket_id: TK-20250617-001}, ) if result.isError: print(call failed:, result.content) else: # 结果是一个内容块列表第一个通常是文本 for item in result.content: text getattr(item, text, None) if text: print(text) if __name__ __main__: asyncio.run(main())运行Clientpython client.py正常情况下你会先看到discovered tools: [get_ticket_status, search_tickets]然后看到工单查询结果。如果这一步通了说明MCP Server和Client链路是完整的。如果你用的是桌面端Agent客户端大部分实现支持在配置文件里声明mcpServers本质上是让宿主帮你启动这样一个stdio子进程并完成同样的握手。你可以把server.py包装成一条启动命令配置进去。自己写Client只是为了调试链路更可控生产环境里你不见得需要自己实现Client。4. 代码之外的工程细节权限、安全与性能4.1 别把所有工具一股脑暴露很多团队一上来就把企业内部API全量包成MCP Tool模型立刻获得了巨大操作面。这是最危险的用法。工具一旦暴露给模型模型就能在用户请求的引导下发起调用而模型并不真正理解权限边界。我建议按“最小暴露面”原则设计工具清单。一个内部系统不是所有接口都需要暴露也不是所有接口都适合暴露给Agent。白名单要人工审核每一类工具都要明确以下内容表格列出建议工具名称内部API操作类型建议暴露范围审批要求工单查询GET /tickets/{id}只读全员可用无需工单修改状态POST /tickets/{id}/status写操作仅管理员需要二次确认删除工单DELETE /tickets/{id}高危禁止暴露禁止客户信息查询GET /customers/{id}只读白名单用户需要审计另外不要在MCP Server内部省略鉴权。很多人觉得“反正只有Agent客户端能连”就放松了内部认证。可Agent可能被提示词注入诱导去调用某个高危工具比如“帮我删掉昨天的工单”。如果Server层没有权限校验最后一道防线就没了。实际接入时MCP Server应该像任何内部API服务一样做身份认证、参数校验、权限判断和审计日志。4.2 返回结果的结构化给模型“省点力气”模型能稳定处理的数据结构通常比我们想象中更简单。我建议所有Tool返回统一的结构至少包含状态、数据和元信息三层{ status: ok, data: {}, meta: { truncated: false, next_cursor: null } }如果查询结果很大不要让模型一次性吞下全部数据。服务端可以先做截断或分页返回前面若干条并把总条数和下一页游标放进meta。模型需要更多数据时再调用另一个分页工具继续取。我试过把工具返回值从“原生接口JSON”改成“摘要化文本”之后Agent回答准确率有了肉眼可见的提升。原因是原生接口里无关字段太多模型容易把一个不相干的值当成关键信息。对于只读查询类工具你甚至可以直接生成一版“人话摘要”给模型效果往往更好。4.3 并发与连接管理stdio模式方便但每次启动都是一个子进程。一个MCP Server进程被启动后通常对应一个客户端会话。如果你在Web服务里每次请求都新建一个stdio子进程会带来很大的资源开销。生产环境建议优先用SSE/HTTP模式部署远程MCP Server把连接管理交给专门的HTTP服务框架。对于并发要求高的工具要注意Server端的接口实现是否支持异步避免一个慢查询阻塞其他工具调用。另外要给工具调用设超时时间尤其某些内部API本身响应就很慢Agent等待超时后会误以为工具不可用反复重试放大问题。5. 常见问题与排错速查5.1 握手失败、工具列表为空、调用超时我把实践中遇到最多的问题排查整理成了速查表现象可能原因处理办法initialize握手失败协议版本不兼容升级SDK核对MCP协议版本工具列表为空Server端没有注册Tool或装饰器没生效检查工具函数是否被mcp.tool()装饰调用时报参数格式错误参数类型与Schema不一致检查函数签名与docstring参数名尽量语义化调用超时内部API响应太慢在Server端增加缓存给内部调用设置合理超时中文内容乱码stdio默认编码不一致确保Server进程以UTF-8编码输出环境变量正确设置工具描述是乱码docstring没有被官方识别改用英文中文双语描述避免奇怪的换行这里特别说一下参数错误。MCP Server从模型手里拿到的参数是JSON格式FastMCP会把它们映射到Python函数参数。如果模型传了None或字符串数字类型转换可能失败。我的经验是在公司内部工具的参数定义里尽量都用字符串不要用复杂嵌套结构。模型对简单的扁平参数最稳定嵌套太深容易出问题。5.2 上下文太长怎么办工具接入越多模型需要感知的工具描述就越多上下文压力随之增加。我常用的手段有三种。第一精简工具描述。描述不是写文档不要长篇大论。每个工具控制在两三句话内把关键约束放在开头。第二给工具分组。让Agent只在特定任务场景下才加载某组工具而不是把所有工具都平铺给模型。第三对返回结果做摘要。工具返回结果不要一次性全给能返回标题列表的就不要返回正文全文。另外可以利用MCP协议里的Resource能力把那些经常变化的公共背景数据放到单独资源里而不是跟随每次工具调用重复发送。上下文管理是Agent应用落地里最吃功夫的地方没有一劳永逸的配置只有持续观察和裁剪。5.3 避坑心得我自己踩过几次比较深的坑分享出来你也许能少走弯路。第一不要在MCP Server里写复杂状态。MCP Tool的设计哲学是无状态优先。如果需要跨多轮记住用户选择应该把状态放到宿主侧或业务系统里而不是依赖MCP Server进程的全局变量。第二不要在工具返回里塞Markdown表格。有些模型对表格的解析不稳定遇到复杂表格容易丢字段。返回纯文本或者扁平JSON更稳妥。第三不要把内部错误堆栈直接返回给模型。模型会一本正经地阅读堆栈并给出误导性结论。Server侧要做错误归一化把内部异常转换成“工具调用失败业务原因是XXX”这样清晰的信息。第四一定要加审计日志。记录模型实际调用过哪些工具、传了哪些参数、结果是什么。这不仅是合规要求也是排查模型行为异常最直接的手段。我见过一些诡异问题最后都是靠审计日志发现模型在一次长对话里连续调用了十几次查询工具把内部系统流量打爆了。6. 从一个小工具到全公司接入落地建议6.1 分阶段接入策略我不建议一开始就搞“全系统统一接入平台”太高估组织推进力了。比较稳妥的做法是先选一个只读、低风险、调用链路短的系统比如工单查询、服务目录、状态页跑通端到端流程。第一个阶段只需要一个MCP Server、两三个Tool。主要是验证协议通不通、模型吃不吃这套描述、内部网络能不能稳定连接。第二个阶段再接入带写操作但可回滚的场景比如工单评论、状态流转。写操作一定要在Server层做二次确认和权限校验。第三个阶段才考虑统一配置管理、多Server发现、全公司规范化推广。过程中的关键不是技术复杂度而是“让模型真的把工具用对”。每个阶段都要收集模型调用工具的日志看哪些描述模型总是理解错误然后反过去改工具描述。工具接入不是一次性开发而是持续优化提示词和参数Schema的过程。6.2 可观测性与审计落地MCP之后很快会面临一个新问题如何知道Agent到底在干什么。MCP协议本身只负责通信不负责观测。我建议在MCP Server层埋点把每条工具调用记录到内部日志系统。重点记录请求ID、会话ID、工具名称、入参、出参摘要、耗时、是否成功。有了日志你才能回答几个关键问题模型是不是总在重复调用同一个工具是不是传入了异常参数是不是在深夜自动触发批量操作这些问题靠网关日志和内部平台监控都能发现。MCP不是魔法接入只是第一步之后的数据运营决定了这个能力是好用还是灾难。6.3 最后说点个人体会真把MCP接入到公司系统之后我最大的感受是协议本身不复杂复杂的是你终于开始认真思考“工具到底应该长什么样”。过去大家写API对象是工程师字段全一点没关系现在写工具对象是模型和不懂系统的最终用户描述必须精准返回必须克制权限必须前置。我个人在给公司系统接Agent时踩得最重的一跤是把所有数据库查询都包装成了工具。模型有时候会拿一个模糊的用户名去查全表业务数据库根本扛不住。后来我给每个工具都加了成本预估字段并把工具描述改成“必须带上明确ID才能调用”效果才稳定下来。这件事教会我MCP的“插头”只是连接标准化真正的质量还是要靠工具设计者的克制和判断。接进去之前先问自己一句这个工具真的需要给模型吗如果答案不是非常坚定就先不要接入。
