一句话定义：MCP（Model Context Protocol）初始化握手是客户端与服务端建立连接后的第一轮往返。双方各自报出协议版本和原生能力（capabilities），谈妥之后才进入正常调用；后面能用哪些功能，基本在这一轮就定下来了。
这一轮到底交换了什么
MCP 跑在 JSON-RPC 2.0 上。连接（stdio 管道或 HTTP）打通后，客户端先发一个 initialize 请求，请求体里带三样东西：protocolVersion（我按哪个版本的规范说话）、capabilities（我这边支持哪些扩展能力）、clientInfo（我是谁、什么版本）。
服务端回一个 initialize 结果，结构对称：选定或回落的协议版本、服务端的 capabilities、serverInfo，还可以附一段 instructions 给模型看的说明。客户端收到后再补发一条 notifications/initialized，握手结束。在这之前发 tools/list 之类的请求是不合规的。
打个比方，这就是两个人见面交换名片。名片上写的不是“我很靠谱”，而是“我会说中文、我能修水管、我不喝酒”。对方收下名片，回去安排活儿时就知道该找你干什么、不该麻烦你什么。也像 USB 设备插上主机时的那次“枚举”：主机先问清楚你是什么设备、有几个端点，问明白了才给你分配驱动。没枚举过的设备，插着也等于没插。
关键点：声明，而不是讨价还价
capabilities 是各自单向广播，不是谈判条件。客户端不能要求“你必须支持 tools”，服务端也不能要求“你必须支持 sampling”。双方只是把支持的能力说清楚，然后各自按对方声明的能力决定行为。
服务端常见的声明项有 tools、resources、prompts、logging、completions；客户端常见的声明项有 roots（告诉服务端文件系统边界在哪）、sampling（允许服务端反过来请客户端跑一次模型生成）、elicitation（服务端可以回头向用户追问信息）。双方都留了 experimental 字段，新能力在草案阶段先挂在这里。
| 关注点 | 没谈成会怎样 | |
|---|---|---|
| 初始化握手 | 版本 + 能力清单 | 版本对不上就断开，能力没声明就当没有 |
| 鉴权（HTTP 传输层） | 你是谁、能不能进 | 直接拒绝连接 |
tools/list 等调用 | 具体有哪些工具、参数是什么 | 报错，或返回空列表 |
版本这一项是唯一带“谈”的意味的：客户端报出自己支持的版本，服务端回一个它选的版本；客户端如果接受不了，只能主动断开。所以版本号不是随便填的装饰。
对做工程的人意味着什么
写客户端或网关：不要假设对方一定有 tools。UI 该按 capabilities 渲染，不然会出现“工具面板空着但没人知道为什么”。同时，sampling、elicitation 这类能力等于把主动权交给服务端，声明前得先想好用户确认和审计怎么做。
写服务端：只声明你真正实现的能力。声明了 resources 却返回空，比不声明更糟——客户端会把它当功能缺失来排查。
排查故障：“连上了但什么都用不了”，十有八九卡在初始化阶段：版本不兼容、能力漏声明、忘了发 initialized 通知。看一眼第一轮往返的报文，通常比翻业务日志快。
规范细节以官方页面为准，不同传输方式在授权和会话终止上还有各自的规定。但那条主线不会变：握手这几行，决定了后面所有对话的边界。