第一次接触 MCP，很多人会把它理解成"给 AI 调工具的协议"。然后问题很快就来了：既然都有 Tool，为什么还需要 Resources 和 Prompts？本地程序为什么常用 stdio，线上服务又为什么推荐 Streamable HTTP？如果一个 Agent 同时连接 GitHub、数据库和内部知识库，它到底在连接谁，又怎么知道有哪些工具可以调用？
这些问题看似分散，其实都指向同一个核心：MCP 解决的不是某个工具怎么调用，而是 AI 应用如何用统一方式发现、连接和使用外部能力。
以下讨论以当前 MCP 2026-07-28 规范为基础。这个版本进一步强化了无状态 HTTP、能力发现和可缓存的列表结果。
Tools、Resources、Prompts，区别在"谁控制什么"
理解这三个概念，最简单的方法不是背定义，而是看控制权。
**Tool 是给模型"做事"的。**例如搜索订单、创建工单、查询天气、执行 SQL。模型看到 Tool 的名称、描述和输入 Schema 后，可以根据当前任务决定是否调用，因此它更接近"能力"或"函数"。
**Resource 是给应用"提供材料"的。**例如项目文件、数据库 Schema、Git 历史、内部文档。Resource 通常通过 URI 标识，Host 决定什么时候把这些内容加入模型上下文，因此它更像可读取的"资料"。官方也将 Resources 定义为 application-controlled。
**Prompt 是给用户复用工作方式的。**比如"代码审查""生成周报""分析事故原因"。它不是执行能力，而是一套预定义的消息或指令模板，通常由用户主动选择。
假设你做一个 GitHub MCP Server：create_issue 应该是 Tool；repo://README.md 可以是 Resource；"Review this PR"则适合做 Prompt。
判断时问三个问题就够了：这是让模型执行动作，还是给模型提供内容？还是提供一套可复用的交互模板？
stdio 适合"Agent 和 Server 在同一台机器"
stdio 可以理解成最直接的本地管道。
Agent 启动 MCP Server 子进程，然后通过标准输入发送请求，通过标准输出接收响应。例如一个桌面 AI 编程助手启动本地文件 MCP Server：
Agent → stdin → MCP Server → stdout → Agent
这种方式的优势是简单。不需要端口，不需要部署 HTTP 服务，也通常不需要额外考虑网络认证。官方 SDK 将 stdio 定位为本地、由进程启动的集成方式。
所以它特别适合 CLI、IDE、桌面应用、本地文件访问，以及开发和调试阶段。
但如果 Server 需要被多人访问、部署在云端、经过网关或独立扩缩容，stdio 就会变得别扭。它解决的是本地进程通信，并不是远程服务治理。
Streamable HTTP 适合真正的远程 MCP 服务
把 MCP Server 做成公司级服务时，Streamable HTTP 更自然。
例如企业内部部署一个 Salesforce MCP Server。几十个 Agent 都需要访问它，这时你希望有统一域名、鉴权、日志、限流、负载均衡和水平扩容。这些正是 HTTP 基础设施已经解决很多年的问题。
MCP 2026-07-28 又进一步把协议核心改为无状态模式：请求可以独立处理，不再依赖之前的协议级 Session；Streamable HTTP 请求还可以通过 Mcp-Method、Mcp-Name 等 Header 被网关直接路由。
因此可以用一个简单经验判断：
Server 跟着 Agent 一起运行，优先考虑 stdio；Server 是独立网络服务，优先考虑 Streamable HTTP。
这也是为什么 MCP 官方目前把两者作为主要传输方向：stdio 面向本地部署，Streamable HTTP 面向远程部署。
一个 Agent 连接多个 Server，靠的是 Host 做编排
另一个常见误区，是想象 Agent 自己维护一条"万能 MCP 连接"。
更准确的结构是：
Agent / Host → MCP Client A → GitHub Server
→ MCP Client B → Database Server
→ MCP Client C → Files Server
Host 可以管理多个 MCP Client，而每个 Client 对应一个 Server。这样每个 Server 保持独立，Host 再把可用能力汇总给模型。MCP 的架构设计本来就强调多个 Server 的组合与隔离。
真正需要设计的是工具目录。
假设 GitHub Server 和 Jira Server 都暴露一个 search Tool，只把两个 search 塞给模型，很容易混淆。Host 往往需要保留来源信息，甚至映射成类似 github.search、jira.search 的命名，然后在模型发起调用时，把请求路由回原来的 Server。
所以"连接多个 MCP Server"的难点并不在连接数量，而在能力聚合、命名冲突、权限控制和调用路由。
Tool Discovery，不等于让模型猜工具
MCP Server 不需要在 Prompt 里告诉模型："我有五个工具，你记一下。"
它有正式的发现机制。
Client 可以调用 tools/list，Server 返回当前可用 Tool 的名称、描述和输入 Schema；如果数量很多，还可以分页。模型随后根据这些描述决定调用哪个 Tool。
这里还要区分两个容易混淆的概念。
server/discover 是发现这个 Server 支持什么协议版本和能力 ；tools/list 才是发现它具体提供哪些 Tools。在新版 MCP 中，前者是可选的能力预发现，后者才直接对应 Tool Discovery。
同理，Prompts 有 prompts/list，Resources 有 resources/list。新版规范还让这些列表带缓存信息，避免客户端每次请求都重新拉取整个能力目录。
真正需要理解的，是 MCP 的分层
如果只记住 Tool、stdio、HTTP 这些名词，很快还是会乱。
更实用的方式，是把 MCP 看成三层。
最上面是能力层：Tools 负责行动，Resources 提供上下文，Prompts 提供可复用交互模板。
中间是协议层：负责发现能力、描述参数、调用方法和返回结果。
最下面是传输层：stdio 解决本地进程通信，Streamable HTTP 解决远程服务通信。
一个 Agent 可以连接多个 Server，是因为 Host 在这些层之上完成连接管理、能力聚合和路由。
因此，设计 MCP 系统时不要先问"我要写几个 Tool"。先画一张图：哪些能力属于哪个 Server，它运行在哪里，谁应该看到它，谁有权调用它，Agent 又如何发现它。
这张图画清楚之后，Tools、Resources、Prompts、stdio、Streamable HTTP 和 Tool Discovery，往往都会自然找到自己的位置。