MCP 是什么：从协议概念到落地的完整指南
MCP（Model Context Protocol）解决的是一个很具体的问题：模型如何以统一方式连接外部工具和数据。在它出现之前，每接一个工具都要为某个客户端单独写一套适配；现在，只要实现一个 MCP Server，主流客户端都能复用。
为什么需要 MCP
大模型本身只会生成文本。要让它读取文件、查询数据库、操作浏览器，必须由外部程序把能力暴露给模型。早期做法是每个应用各自定义函数调用格式，换一个客户端就要重写一遍集成。
MCP 把这件事抽象成协议：工具提供方实现 Server，应用实现 Client，双方按统一的消息格式通信。这样一来，工具的能力描述、调用参数和返回结果都有固定结构，客户端不需要认识每一个具体工具。
Host、Client 与 Server
理解 MCP 先要分清三个角色。Host 是用户直接使用的应用，例如桌面客户端或编辑器；Client 是 Host 内部负责与某个 Server 通信的连接；Server 则是暴露具体能力的程序。一个 Host 可以同时连接多个 Server，每个 Server 对应一个 Client 连接。
这种分层让能力可以按需组合：文件系统、GitHub、浏览器、数据库分别作为独立 Server 运行，Host 只负责把可用工具汇总给模型。
- Host：承载对话与模型调用的应用，负责权限与用户确认。
- Client：Host 与单个 Server 之间的协议连接。
- Server：以标准方式声明工具、资源与提示词，并处理调用。
三类核心能力
MCP Server 可以暴露三种能力，它们的控制权不同。Tools 由模型决定是否调用，通常对应有副作用的操作，例如写文件、发请求；Resources 是只读上下文，由应用选择性地提供给模型；Prompts 则是预置的提示词模板，通常由用户主动选择。
实际落地时，大多数 Server 以 Tools 为主。设计工具时要像设计 API 一样克制：名称明确、参数少而稳定、返回结构可解析，并把高风险操作拆成需要显式确认的步骤。
传输方式与部署形态
本地场景通常使用标准输入输出作为传输，Server 由 Host 作为子进程启动，适合访问本机文件和开发环境。远程场景使用基于 HTTP 的传输，Server 独立部署，便于团队共享和统一鉴权。
选择哪种形态取决于数据边界：涉及本地文件与凭证的工具适合本地运行；需要多人共用、集中审计的工具更适合远程部署。两种形态可以并存，同一个 Host 同时连接本地和远程 Server。
接入前要评估的安全问题
MCP 把外部能力直接交给模型，风险也随之放大。一个能读写文件或执行命令的 Server，如果没有目录限制和确认机制，模型的一次误判就可能造成实际影响。
因此接入前至少要确认：Server 的来源是否可信、权限范围是否最小化、危险操作是否需要人工确认、日志是否可追溯。生产环境不建议直接启用来源不明的 Server。
- 限制 Server 可访问的目录、网络与凭证范围。
- 对写操作、命令执行和外部请求保留人工确认。
- 记录调用参数与结果，便于排查异常行为。
- 优先选择官方或维护活跃的 Server。
从哪个 Server 开始
如果想先体验，文件系统和 GitHub 这两类 Server 最容易看到效果：前者让模型读写本地资料，后者让它理解仓库与 Issue 上下文。调试阶段可以配合官方 Inspector 查看工具列表并直接发起调用。
体验之后，再根据实际工作流决定是使用现成 Server，还是把内部系统封装成自己的 Server。后者通常才是 MCP 在团队中真正产生价值的地方。
