MCP 技术分享：从协议握手到 LangGraph 多 Server 调用

AI Agent 落地时，最常见的需求不是“再换一个模型”，而是让模型安全、稳定地访问外部能力。查询数据库、读取文件、调用业务 API、执行计算、搜索知识库，这些操作都需要一个统一的工具边界。

Model Context Protocol，简称 MCP，目的就是把这部分集成标准化。它把能力提供方抽象为 Server，把能力使用方抽象为 Client，再用 JSON-RPC 和明确的初始化流程统一工具、资源、提示词、生命周期和传输。

从工程角度看，MCP 的价值不是“让模型更聪明”，而是让工具调用从一堆私有约定，变成可发现、可复用、可测试的协议能力。

这篇文章不会停留在概念介绍，而是以一个可运行的 Python 示例集为主线，完整跑通过：

需要特别说明的是，MCP Python SDK 2.x 已经将旧版 FastMCP 改名为 MCPServer：

两者不能混用。本文的代码和测试都以 MCP 2.2.0 为准。

MCP 的整体架构设计清晰易懂，只要吃透三个核心角色的定位，就能基本理解整套协议的设计思路与运行逻辑：

Host 是用户真正使用的应用，例如 IDE、聊天客户端、桌面 Agent 或企业工作台。Host 负责模型、会话、用户权限和交互体验。

Client 由 Host 创建，负责连接一个 MCP Server。它管理协议握手、请求发送、响应解析、能力协商和连接关闭。

在 Python 中，核心对象通常是 ClientSession：

Server 暴露具体能力。MCP 中最常见的能力有三类：

除了这三类能力，Server 还参与协议初始化、能力声明、生命周期管理和传输协商。

如果把 Agent 比作应用层，那么 MCP 解决的是应用层和工具层之间的标准接口问题。

这里还没有注册工具，但它已经具备一个完整 MCP Server 的基础元数据：

title：面向开发者展示的服务名称，便于直观识别

description：简单阐述服务核心能力与用途

instructions：面向大模型与客户端的功能说明，辅助能力调用

version：服务版本标识，便于后续迭代兼容、版本管控

客户端通过 stdio 启动 Server，然后初始化会话：

这一步看起来简单，但它决定了后续能不能调用工具、读取资源以及使用某些扩展能力。

一个常见错误是把调试日志直接打印到 stdout。对于 stdio 传输，stdout 是 JSON-RPC 数据通道，任何额外输出都可能破坏协议流。调试信息应该写 stderr，这也是示例项目统一遵守的约束。

Tools 是 MCP 体系中使用频率最高的核心能力，主要用于承载各类可变的业务操作。SDK 提供了简洁的装饰器注册方式，能够自动完成参数校验、工具描述生成。

函数名、类型标注和 docstring 会被 SDK 转换成工具名称、输入 Schema 和描述。客户端可以先获取工具列表：

返回结果中的 content 是协议内容块。对于普通文本结果，可以这样读取：

来源：稀土掘金　原文