教程 · 分步实操
怎么用 MCP 把工具接给 AI 助手：4 步跑通（2026）
结论在前：MCP 解决的是「同一个工具被不同客户端复用」——把工具写成一个本地小服务，客户端按标准协议调用，不必为每个助手各写一遍。下面 4 步先跑通再自己写。
先用现成的 server 跑通链路，理解数据怎么走，再决定要不要自己写。这样排错时你能分清是配置问题还是工具本身的问题，也能提前看清权限边界，避免一上来就把范围开得太大。
分步做法
认清三种角色
宿主（你用的助手）负责发起；客户端负责和某个 server 通信；server 提供具体工具。通信走 JSON-RPC，常见本地传输是标准输入输出。
先跑通一个现成 server
挑一个官方示例（如文件系统类）先用命令行直接启动，确认它能正常响应，别急着接到助手。
在客户端里登记 server
把 server 的启动命令与参数写进客户端配置。注意工作目录与权限范围，只放开你确实需要的目录。
验证一次工具调用
让助手调用一次工具并看返回结果；失败时先看客户端日志里 server 是否成功握手，再查参数。
跳过命令行验证：直接接助手，出错时分不清是配置还是 server 本身的问题。
权限开太大：文件系统类 server 只放开必要目录。
路径用相对路径：客户端的工作目录与你手动跑时可能不同，用绝对路径更稳。
没看握手日志：连接失败多半是启动命令或环境变量的问题。
自检清单
常见问题
MCP 和普通插件有什么不同？
插件通常绑定某一个客户端；MCP 把工具做成独立 server，多个客户端可以复用同一套工具，减少重复开发。
本地跑 MCP server 安全吗？
取决于你给的权限。文件系统类 server 建议只放开必要目录；涉及写操作的工具要确认调用来源可信。
连接失败先查什么？
先看客户端日志里 server 有没有成功握手。多半是启动命令、工作目录或环境变量的问题，而不是协议本身。
需要自己写 server 吗？
先用现成的示例跑通链路更省事；只有当你要接入自有的内部系统时，再按协议自己实现一个 server。
来源参考
以上为官方文档/定价页；操作步骤与数值口径为 2026-10-08 核对所得，产品会变，请回源核对当日。
下一步：想先理解协议怎么工作，读 MCP 是怎么工作的；想看容器里怎么跑 Agent，读 声明式 Docker Agent。