MCP 解决了什么，又没有解决什么？
MCP 很容易被讲成一句话：
AI 时代的 USB-C。
这个比喻有用，但也有点危险。
它会让人误以为：只要插上 MCP Server，Agent 就自然拥有了一套安全、可靠、可治理的工具系统。
不是。
MCP 解决的是连接问题。
Runtime 解决的是治理问题。
这两件事不能混在一起。
MCP 真正解决了什么
先说它解决了什么。
MCP 把 LLM 应用和外部能力之间的连接标准化了。按照官方规范，MCP 有 Host、Client、Server 这几个角色：
Host：LLM 应用，比如 IDE、聊天应用、Agent 产品
Client：Host 内部连接某个 Server 的协议客户端
Server：暴露 resources、prompts、tools 等能力
以前每接一个工具都要写一套私有 adapter。
接 GitHub，写一套。
接 Notion，写一套。
接浏览器，写一套。
接数据库，写一套。
接内部工单系统，再写一套。
MCP 的价值是把这些能力先放进同一套协议形态里：
resources/list
resources/read
prompts/list
prompts/get
tools/list
tools/call
对 Agent 产品来说，这很重要。
因为工具生态不可能全靠你自己写。未来团队内部会有 MCP Server，第三方工具会有 MCP Server，开发者本地也会有一堆 MCP Server。
没有标准协议，工具接入会碎成一地。
tools/list 让发现变标准
MCP Tools 规范里，Client 可以通过 tools/list 发现 Server 暴露了哪些工具。工具会带上名称、描述、输入 schema 等信息。
这解决了一个很实际的问题：
Runtime 不需要预先写死所有工具。
Server 可以独立升级。
工具列表可以动态变化。
模型上下文可以按需暴露工具说明。
比如一个 GitHub MCP Server 可以暴露：
search_issues
read_pull_request
create_issue
comment_on_issue
一个文件系统 MCP Server 可以暴露：
list_files
read_file
write_file
一个设计工具 MCP Server 可以暴露：
get_node
export_asset
read_variables
这些工具的发现方式统一了。
这是 MCP 的大功劳。
tools/call 让调用变标准
tools/call 解决的是调用入口。
模型决定调用哪个工具，Runtime 把调用转给 MCP Client，Client 发给对应 Server，Server 执行后返回结果。
大概是：
Model tool call
↓
Agent Runtime
↓
MCP Client
↓
MCP Server
↓
Tool result
这让外部工具像'可插拔能力'一样进入 Agent 产品。
以前一个工具要接入 Agent，需要同时考虑协议、schema、鉴权、调用、返回、错误。MCP 至少把协议层和能力描述层压平了。
开发体验会好很多。
这也是为什么 MCP 会流行。
它解决的痛点是真的。
但 MCP Server 不是 Agent
第一个误区：把 MCP Server 当 Agent。
MCP Server 暴露能力，不负责完成用户目标。