请结合一次典型的工具调用过程，说明 MCP（Model Context Protocol）的整体工作流程，包括客户端、服务端等参与方各自承担的职责。

回答思路

1. 【回答框架 1】MCP 采用客户端-服务端架构。客户端通常是 AI 应用或宿主环境，负责发起请求、管理会话并处理用户意图；服务端是提供工具、资源或提示的外部程序，通过标准协议暴露能力。协议核心是 JSON-RPC 2.0 消息，通过标准化传输层（如 stdio 或 HTTP）交换。
2. 【回答框架 2】完整流程通常为：客户端先完成初始化握手，交换协议版本与能力声明，建立会话。随后客户端将用户请求或模型生成的工具调用意图转换为 MCP 格式的工具调用请求，发送给服务端。服务端执行对应的工具逻辑，返回结构化结果。客户端接收后，将结果注入到模型上下文，使模型能结合工具输出生成最终回答，并可能更新会话状态。
3. 【回答框架 3】关键机制在于能力协商与动态发现：初始化阶段客户端和服务端各自声明支持的能力，如工具列表、资源订阅等。客户端可通过 tools/list 获取可用工具，并按需调用。整个过程中，上下文信息以标准化结构传递，确保跨平台一致性和可扩展性。
4. 【回答框架 4】实际落地时，工作流还要考虑错误处理、超时、权限控制与日志追踪。每次请求都应包含请求标识以关联结果；对于长任务或流式响应，MCP 支持对应的通知机制。最后，整个链路的状态管理由客户端负责，服务端尽量保持无状态，以实现水平扩展与隔离。
5. 【关键点 1】MCP 基于 JSON-RPC 2.0，客户端负责发起会话与调度，服务端提供工具并执行。
6. 【关键点 2】初始化握手包含协议版本协商和能力交换，是后续调用的前提。
7. 【关键点 3】工具调用路径为客户端请求、服务端执行、结果回传并注入模型上下文。
8. 【关键点 4】MCP 支持动态工具发现（tools/list）与错误码，适配多种传输层。
9. 【关键点 5】实际部署需关注权限、超时、重试和日志，服务端通常设计为无状态。
10. 【易错点 1】不能将 MCP 简化为普通 API 调用，它强调上下文管理和能力协商。
11. 【易错点 2】不要忽略初始化失败或能力不匹配导致后续调用异常。
12. 【易错点 3】流式或长耗时任务需使用对应通知机制，不能简单等待单个响应。