MCP 是什么？Model Context Protocol 如何连接 AI Agent、Tools、API 与 JSON Schema？

截至 2026 年 7 月 28 日，MCP 官方新规范已同步支持 TypeScript、Python、Go、C# 4 个 Tier 1 SDK，这意味着你现在建设 MCP Server 时，应优先按规范和客户端兼容性设计，而不是围绕某一个应用的私有配置开发。官方规范发布说明

症状：你能让 AI Agent 调用一个工具，却说不清 Host、Client、MCP Server 和实际 API 谁负责什么，远程部署后还出现认证、超时或权限失控。
最快解法：把 MCP 当成一条连接生命周期来验收：先确认角色，再完成传输与能力协商，随后发现 JSON Schema、调用工具、执行 API，最后补齐权限、审计和运行维护。

这篇适合 3 类人：

• MCP Server 开发者：需要正确暴露工具、参数和返回结构。
• Agent 平台工程师：需要让多个客户端和模型接入同一套业务能力。
• 运维与安全团队：需要部署、认证、审计并限制工具权限。

先把 MCP Model Context Protocol 的角色分清

MCP 是连接 AI 应用与工具、资源、提示模板的开放协议。它不是模型，也不替代 Function Calling。典型链路是：MCP Client 发现 Server 暴露的工具 Schema，模型根据用户任务选择工具，Client 或平台发起调用，Server 执行实际业务逻辑，再把结果返回给模型。

官方架构将系统分成 Host、Client 和 Server：Host 是承载 AI 应用的容器，负责管理多个 Client、生命周期、用户确认和安全策略；每个 Client 通常维护与某一个 Server 的隔离连接；Server 则暴露工具、资源或提示模板，并连接数据库、文件系统或远程 API。MCP 官方架构说明

你可以用一个“工单查询”场景理解：

• Host 接收你的自然语言请求，并决定哪些 MCP Server 可以参与。
• Client 向工单 MCP Server 获取可用工具和参数规则。
• AI Agent 根据工具名称、描述和 Schema 生成工具调用意图。
• MCP Server 校验参数，调用内部工单 API。
• API 返回工单状态，Server 将结果整理成 MCP 响应。
• Client 把结果交给 Host，模型再生成最终答复。

这里有一个容易被忽视的边界：模型通常不直接建立网络连接，也不应该持有所有 API 密钥。Host 负责安全和生命周期，Client 负责协议转发，Server 负责能力实现。把这 3 层混在一个脚本里，初期能跑，后续很难做权限隔离和问题定位。

一次连接会经历哪些阶段？

你可以把完整流程画成下面这条时间轴：

Host
  │ 创建并管理 Client
  ▼
MCP Client
  │ 选择传输、声明版本与能力
  ▼
MCP Server
  │ 返回能力与工具目录
  ▼
Tool Schema
  │ 模型选择工具并生成 arguments
  ▼
tools/call
  │ Server 校验参数并执行 API
  ▼
结构化结果 / 错误 / 超时 / 取消
  │
  └── Client 回传 Host，模型继续推理

1．启动：选择传输并建立边界

本地 MCP Server 常用 stdio。Client 启动一个子进程，通过 stdin 和 stdout 传递以换行分隔的 JSON-RPC 消息；这种方式适合本机脚本、开发工具和不需要公网访问的个人环境。stdio 与 Streamable HTTP 传输规范

远程服务则通常采用 Streamable HTTP。每次请求发送到 MCP 端点，响应可以是 JSON 对象，也可以是请求范围内的 SSE 流。它更适合团队共享、容器部署、反向代理和负载均衡，但你必须额外处理身份认证、网络暴露、请求路由和日志。Streamable HTTP 规范

需要特别注意版本差异。早期 MCP 版本使用 initialize / initialized 握手和连接级会话；2026 年 7 月 28 日规范转向无状态协议核心，初始化握手和 Mcp-Session-Id 已退出新版本主流程，客户端如需提前了解能力，可使用 server/discover。因此，不能把旧教程中的初始化字段直接当成所有 MCP 实现的永久要求。2026-07-28 规范变更说明

2．发现：读取工具目录和 JSON Schema

Server 会通过工具列表告诉 Client：有哪些工具、工具做什么、需要哪些输入，以及在支持时返回什么结构。工具定义通常包含：

• name：稳定、唯一、便于日志检索的名称；
• description：告诉模型什么时候该用、什么时候不该用；
• inputSchema：描述参数类型、必填项、枚举值和嵌套关系；
• outputSchema：在实现支持时，描述工具返回结果的结构。

MCP 使用 JSON Schema 做协议消息和工具参数的结构校验。规范默认支持 JSON Schema 2020-12；但 Schema 只负责“数据长什么样”，不负责解释业务含义。MCP 基础规范中的 JSON Schema 说明

例如，一个查询部署状态的工具，不应只写成“查询状态”，而应明确：

• environment 是字符串，且只能取 staging 或 production；
• service 是必填字符串；
• 不接受任意脚本内容；
• 返回值包含状态、版本和更新时间字段。

工具描述同样重要。两个工具的 Schema 可能都只有一个字符串参数，但描述如果没有说明范围、风险和适用条件，AI Agent 仍可能选错工具。开发时不要只验 Schema 是否通过，还要用真实任务测试工具选择率和误调用情况。

MCP 工具调用由谁执行？

当模型决定调用工具时，调用阶段至少包含 4 个动作：

1. 模型生成工具意图：选择工具名，并生成符合 inputSchema 的参数。
2. Client 或 Host 转发：检查该工具是否在允许列表中，必要时要求用户确认。
3. Server 校验并执行：再次验证参数，调用数据库、内部 API、文件系统或自动化脚本。
4. Server 返回结果：将文本、资源链接或结构化内容交给 Client，再由 Host 放回模型上下文。

因此，Function Calling 与 MCP 的关系是“分层协作”，不是互相替代。Function Calling 是模型供应商常见的工具调用表达方式；MCP 是客户端与工具服务之间的标准连接协议。模型可以产生一次工具调用，但是否通过 MCP 传输、由哪个 Server 执行，属于应用架构决定。

错误处理要在 Server 侧设计，而不是让模型自行猜测。至少要区分参数校验失败、业务拒绝、认证失败、上游 API 错误、超时和用户取消。官方生命周期文档建议为请求设置超时，并在超时后取消未完成请求，避免一个失控任务长期占用连接和执行资源。生命周期、超时与错误处理说明

幂等性也不能省略。读取工具通常可以安全重试；创建订单、删除资源、发布代码等写入操作，则应携带幂等键或执行前确认。否则，模型重复调用一次，后端可能真的产生两次变更。

⚠️ 注意：不要把“返回了 JSON”误认为“已经具备结构化输出”。真正可维护的工具结果应有稳定字段、明确错误类型和可验证结构；否则模型仍要从自然语言中猜状态。

权限、凭据与长期运行如何落地？

MCP Server 至少要把工具分为 3 类：

• ✅ 只读工具：查询数据库、读取构建状态、检索日志，可默认开放，但仍需限制数据范围。
• ⚠️ 写入工具：创建任务、修改配置、提交代码，应加入用户确认、项目范围和审计记录。
• ❌ 破坏性工具：删除资源、吊销凭证、发布生产版本，应默认关闭，采用白名单和二次确认。

凭据应保存在 Host、受控执行环境或服务端密钥系统中，不能写进 inputSchema、提示词、公开配置文件或工具描述。远程 MCP Server 还要补充身份认证、请求签名或令牌校验、租户隔离、速率限制和审计日志。Schema 约束的是参数格式，不等于授权系统。

本地服务迁移到远程的 6 步

1. 盘点本地依赖：列出文件路径、环境变量、系统命令、网络地址和用户权限。
2. 拆分执行层：把 MCP 协议适配、业务逻辑和实际 API 调用分成独立模块。
3. 固定工具契约：为每个工具补齐名称、描述、inputSchema、错误类型和返回结构。
4. 替换传输方式：从 stdio 改为 Streamable HTTP 端点，并确认客户端支持的规范版本。
5. 补齐运行保护：设置认证、超时、取消、日志、幂等键和破坏性操作确认。
6. 做兼容验收：使用官方 SDK 或兼容客户端完成发现、调用、错误返回和重连测试，记录规范版本与客户端版本。

如果服务要部署在负载均衡后面，优先检查客户端和 Server 是否都支持当前无状态协议流程。2026 年 7 月 28 日规范允许请求落到不同实例，但你的业务层仍可能依赖本地文件、进程内缓存或登录会话；协议无状态不代表整个应用天然无状态。官方传输与路由说明

用条件分支选择部署方案

• 若只有个人本机使用，工具依赖本地文件或开发环境，且不需要团队共享：选 stdio 本地 MCP Server。
• 若多个用户、多个 AI 客户端需要共享同一套业务工具：选远程 Streamable HTTP，并把认证、租户隔离和审计作为上线前置条件。
• 若核心数据在内网，但部分工具需要公网访问：选混合模式，内网 Server 保留数据访问能力，公网层只暴露经过白名单控制的工具。
• 若工具需要访问 Xcode、代码签名、macOS 自动化或本机图形环境：不要为了“统一云化”强行迁移到 Linux；先评估远程 Mac 作为受控执行节点。
• 若任务是长期稳定的大规模后台负载，且不依赖苹果专属资源：优先比较自建服务器或常规云主机，MCP 只负责协议连接，不决定底层算力方案。

如果你还在做 MCP Server 部署环境检查，建议先记录 4 项：客户端支持的协议版本、工具发现结果、实际 API 延迟、失败后的取消行为。涉及基础设施选型时，可进一步查看 Kvmjet 的基础设施说明，不要把所有 MCP Server 都默认部署在 Mac 上。

FAQ：接入前最容易混淆的 5 个问题

MCP 和大模型到底是什么关系？

MCP 是连接 AI 应用与外部工具、资源和提示模板的开放协议，不是大模型，也不负责生成答案。大模型通常只负责理解任务和选择工具，Host 与 MCP Client 负责连接、权限、参数传递和结果回收，MCP Server 则负责暴露能力并执行具体业务逻辑。

MCP Server 怎样把现有 API 提供给 AI Agent 使用？

你需要在 MCP Server 中为 API 包装一个工具定义，提供稳定的工具名、用途描述和 inputSchema。收到 tools/call 后，Server 先校验参数，再调用内部 API，最后把文本或结构化结果封装成 MCP 响应。API 密钥应留在服务端，不应放进 Schema。

为什么 MCP 工具定义普遍采用 JSON Schema？

JSON Schema 可以描述参数类型、必填字段、枚举值和嵌套结构，使 Client 能在调用前完成校验，也让模型知道工具需要哪些参数。它解决的是数据结构约束，不等于工具语义；工具描述、错误信息和权限策略仍会影响 AI Agent 是否正确选用工具。

MCP 工具调用时，究竟是谁在执行操作？

模型只提出工具选择和参数，真正执行的是 MCP Server 或其后端执行环境。Client 或 Host 负责把请求转发给 Server，并将结果重新放入模型上下文。因此，数据库写入、代码构建、文件修改和第三方 API 请求的权限边界，都必须在 Server 与执行环境中控制。

本地 MCP Server 如何迁移成远程服务？

先把依赖本机文件、环境变量和标准输入输出的部分拆出来，再改用 Streamable HTTP 暴露统一端点。随后补上身份认证、请求超时、取消、日志、审计和反向代理配置，并用兼容客户端重新验证能力发现、工具调用和错误返回，不能只搬运启动命令。

如果你的当前方案是把 MCP Server 直接绑在个人电脑上，常见缺点是电脑休眠会中断连接、家庭网络或办公网络缺少稳定入口、凭据和权限容易散落在本机配置中；如果改用普通云主机，又可能无法访问 Xcode、代码签名、macOS 自动化或苹果专属工具链。对于需要让 MCP 工具持续访问这些资源的团队，租用 Kvmjet 的远程 Mac，通常比临时维护一台个人 Mac 更容易形成固定的运行节点、权限边界和交付流程。需要确认是否适合你的任务，可先通过 远程 Mac 部署需求咨询 核对工具依赖、常驻方式和团队访问路径。