什么是 MCP Server？一份通俗易懂的指南

摘要

MCP Server 是一个小型的标准化程序，通过统一协议而非一次性定制集成，把某一项具体能力 —— 数据库、日历、商品目录 —— 开放给 AI Agent 使用。Model Context Protocol（MCP）是 Anthropic 于 2024 年 11 月发布的开放标准，如今已成为 Agent 连接外部世界的默认方式：SDK 月下载量在十六个月内从约 200 万增长到 9700 万，OpenAI、Google、Microsoft、Amazon 都已上线对它的支持（Digital Applied，2026）。本指南将讲清楚 MCP Server 到底是什么、各部分如何协同工作，以及像 IntentLink 这样的网络在其中扮演什么角色。

"MCP Server" 到底指什么

Model Context Protocol（MCP）是协议标准本身，而 MCP Server 是这个标准的一种具体实现 —— 是一个暴露出一组明确能力（用 MCP 的术语来说是 tools、resources、prompts）的程序，任何兼容 MCP 的 AI Agent 都可以发现并调用这些能力。

业界常用"AI Agent 的 USB-C"来形容它，这个比喻基本站得住脚：在 MCP 出现之前，把一个 Agent 接入数据库或日历，意味着要为这个特定的 Agent 和这个具体的工具单独写一套集成代码。换一个 AI 厂商，这套集成就得重做一遍。MCP 用一套统一的连接器标准取代了这一切 —— 只需搭建一次 Server，任何兼容 MCP 的 Agent（Claude、基于 GPT-5 的 Agent、Gemini，或者自建的 Agent）都能直接接入。

这套协议由三个基本单元组成：

• Tools（工具） —— Agent 可以调用的函数，比如 search_products 或 get_calendar_events，大致相当于 API 端点。
• Resources（资源） —— Agent 可以读取的数据，比如一个文件或数据库表，大致相当于一次 GET 请求。
• Prompts（提示模板） —— Server 提供的可复用指令模板，让 Agent 知道如何正确使用其工具，而无需 Agent 开发者手写这部分引导逻辑。

具体来说，"MCP Server"就是连接另一端运行的那个程序，暴露出上述三种能力的某种组合。

MCP 出现前 vs. MCP 出现后

最后一行正是 MCP 迅速普及的现实原因：对大多数常见能力而言，开发者已经不需要再动手开发了 —— 能满足需求的 MCP Server 很可能已经存在。

MCP Server 是如何工作的，一步步拆解

抛开概念包装，MCP 其实是一个相当精简的协议：一个内置在 AI Agent 中的客户端，通过两种传输方式之一与 Server 通信 —— 本地运行的工具用 stdio，远程 Server 则用带 Server-Sent Events 的 HTTP。

1. 连接（Connect）。Agent 的 MCP 客户端与 Server 建立连接 —— 可能是本地进程，也可能是远程 URL。
2. 发现（Discover）。客户端询问有哪些能力可用。一次 tools/list 调用会返回 Server 暴露的所有工具，连同各自的参数和说明 —— 完全不需要人工翻文档。
3. 调用（Call）。Agent 根据对话内容判断某个工具相关，通过 tools/call 带上具体参数发起调用。
4. 执行（Execute）。Server 执行真正的业务逻辑 —— 一次数据库查询、一次搜索、一次 API 请求 —— 并返回结构化结果。
5. 回应（Respond）。Agent 把结果融入自己的回答。用户看到的是一段正常的对话回复，底层的工具调用完全不可见。

一次最简化的交互大致是这样：

// 1. Agent 询问有哪些能力可用
{"jsonrpc":"2.0","method":"tools/list","id":1}

// 2. Server 返回结果
{"result":{"tools":[{"name":"search_products","description":"...","inputSchema":{...}}]}}

// 3. Agent 调用某个工具
{"method":"tools/call","params":{"name":"search_products","arguments":{"query":"..."}}}

// 4. Server 返回结构化结果
{"result":{"content":[{"type":"text","text":"..."}]}}

这就是全部的心智模型了。鉴权、工具设计、错误处理 —— 其余的一切都只是搭建在这四步循环之上的实现细节。

一个 MCP Server 到底能做什么

取决于开发者想暴露什么能力。实际上，公开的 MCP Server 已经覆盖了绝大多数常见的商业软件类别：开发者工具（GitHub、数据库、云基础设施）、生产力与商业应用（CRM、日历、通信平台）、搜索与网页访问，以及 —— IntentLink 所在的赛道 —— 商业化，即把用户的请求匹配到相关的、可购买的商品或 offer。

截至 2026 年初，已有超过 5800 个覆盖这些类别的公开 MCP Server（Digital Applied，2026）—— 这也是为什么"我需不需要自己build一个"往往不是该问的第一个问题。对大多数常见能力而言，兼容的 Server 早已存在，真正要做的是挑选并接入它，而不是从零开始写一个。

MCP 为什么能在这么短时间内成为默认基础设施

这条采纳曲线值得单独看一看，因为它确实不寻常。Anthropic 于 2024 年 11 月以 MIT 协议开源了 MCP。十六个月后：

• SDK 月下载量从发布时的约 200 万，增长到 2026 年 3 月的 9700 万 —— 约 48 倍的增幅（Digital Applied，2026）。
• 作为对比，React 这个过去十年前端基础设施中被采纳最广泛的库之一，用了大约三年才达到月下载量 1 亿。MCP 用不到一年半就做到了。
• OpenAI、Microsoft Copilot、Google DeepMind、Amazon Bedrock 都在发布后大约十三个月内上线了对 MCP 的支持，让它从"Anthropic 的协议"变成了跨厂商的通用标准（Digital Applied，2026）。

这背后的原因与其说是炒作，不如说是一道算术题：MCP 并没有要求开发者学习一套全新范式，它只是把各团队原本就在各自摸索、彼此不兼容的集成方式标准化了。一旦所有主流厂商都支持同一个连接器标准，"只开发一次集成，而不是重复开发五次"就不再是可选项，而是必然选择。

IntentLink 在其中扮演什么角色

IntentLink 本身就是以 MCP Server 的形式提供服务 —— 专门为商业化场景打造。把 Agent 接入 IntentLink，search_products / search_travel 工具立刻可用，每条返回结果都已经附带一个可直接使用、可跟踪的购买链接。不需要为购物单独接一套集成，为旅行再接一套，为每个电商平台再各接一套。

这正是以上所有内容的实践版本：开发者不必只是了解"MCP Server 是什么"，而是可以当天下午就接入一个能把对话式意图直接转化为收入的 Server。如果这正是你关心的部分，这篇接入指南详细介绍了 MCP 和 REST 两条路径。

常见问题

查看文档