企业官网建设流程全解析

学了半天MCP，绕来绕去就是没搞明白它和普通API调用到底差在哪。直到我把一个请求从用户输入到工具执行完完整整追了一遍，才意识到MCP的核心根本不是那堆协议名词，而是一条非常明确的调用链：模型发起的请求，怎么找到工具、怎么传参、怎么执行、怎么把结果拿回来。这篇文章就把这条调用链彻底拆开讲透，顺便把搭建、配置、排错这些实操环节一并整理出来。适合刚接触MCP的AI应用开发者，也适合那些已经在用Cursor、Claude Code但始终对原理一知半解的人。

1. 为什么会出现MCP：AI应用的工具调用困境

1.1 没有MCP的时候，工具调用是怎么做的

在MCP出现之前，想让大模型调用外部工具，基本只有一条路：自己在代码里写function calling。拿一个简单的天气查询功能来说，流程大概是这样的：

1. 在代码里定义一个get_weather(city)函数
2. 把函数名、参数描述、函数功能一起塞进System Prompt
3. 大模型在生成回复时，如果判断需要查询天气，就会输出一个结构化的JSON，里面标明函数名和参数
4. 你的应用解析这个JSON，调用对应的函数
5. 把函数的返回结果重新拼到对话上下文里，让大模型基于结果继续生成

这套流程本身没问题，但一旦工具数量多了，问题就暴露了：每接入一个新工具，都要手动写函数定义、手动维护参数说明、手动处理返回格式。更重要的是，工具的描述信息是写在Prompt里的，而Prompt是有长度限制的，工具一多，还没聊几句上下文就被工具描述占满了。

1.2 MCP改变了什么：从“告诉模型”到“让模型自己发现”

MCP全称Model Context Protocol，它的核心思路是把工具调用从“一次性写死在Prompt里”变成“运行时动态发现和调用”。你可以把MCP理解成一套USB接口的标准：设备不需要提前告诉电脑自己有什么功能，插上之后电脑通过枚举就能发现设备能力，然后按标准协议读写数据。

回到AI应用的场景里，MCP Server就是那个外接设备，MCP Client是电脑上的接口控制器，而大模型则是用户。模型不再需要提前知道所有工具的具体细节，而是在需要的时候通过标准化的协议去“枚举”MCP Server提供了哪些工具、每个工具长什么样、怎么调用。这就是为什么现在Claude Code、Cursor、Dify这些工具都能通用同一套MCP配置——协议标准化了，任何遵守协议的Server都能即插即用。

1.3 MCP、Function Calling、Agent Skill三者到底啥关系

这个问题几乎每个学MCP的人都会纠结。我的理解是这样的：

Function Calling是一个能力，指的是模型能根据用户意图输出结构化调用来触发外部函数。它是底层的模型能力。

MCP是一套协议，它定义了工具怎么被发现、怎么被调用、结果怎么返回。它不依赖某个特定的模型能力，任何支持工具调用的模型都能接MCP。

Agent Skill是一套提示工程方案，它用自然语言描述“什么时候该用这个技能”和“怎么用”，本质上是给模型提供更高质量的执行指令。Skill和MCP不是对立的，而是可以配合的：Skill负责说清楚“什么时候用、怎么用”，MCP负责把“用”这个动作落地到某个具体工具。

一句话总结：MCP解决的是“工具怎么暴露给模型”的问题，Skill解决的是“模型怎么更好地使用工具”的问题，Function Calling是这一切的底层支撑。

2. 核心调用链：一个请求从发起到执行完毕的完整旅程

2.1 调用链全景：七步走完一次工具调用

现在进入这篇文章最核心的部分。我画了很多遍图之后发现，一次完整的MCP工具调用，不管底层Server用什么语言写的、走的是stdio还是HTTP，最终都逃不过这七个环节：

用户输入 → Agent（大模型）决策 → MCP Client发现工具 → 组装请求 → 传输 → MCP Server执行并返回 → Agent整合结果

你需要记住的关键点在于：真正决定调用走不走得通的核心，只在这条链路的中间四环——模型怎么决定用工具、Client怎么把模型意图转成协议请求、Server怎么解析并执行、结果怎么原路返回。这四环串起来了，MCP就通了。

2.2 模型决策：工具描述怎么影响模型的选择

整个调用链的起点，并不是用户输入的那句话，而是模型看到的那份“工具清单”。MCP Client在初始化时会向Server发起一次tools/list请求，拿到一个JSON数组，里面包含所有工具的名称、描述、输入参数的JSON Schema。这份清单会被塞进模型的上下文里，模型就是根据这些信息来决定“现在该不该调工具、调哪个工具、参数怎么填”。

这里有个很多人容易忽略的细节：工具描述写得好不好，直接决定模型调得准不准。同一个功能，如果一个Server写的是“get_data”，另一个写的是“根据城市名获取实时天气数据，城市名支持中英文，例如北京、Shanghai”，后者被模型正确调用的概率会高非常多。这就是为什么很多MCP Server的坑不是出在执行逻辑上，而是出在工具描述写得不够清楚。

2.3 MCP Client：模型和Server之间的翻译官

在Claude Desktop、Cursor这类应用里，MCP Client是内置的，你不需要自己写。但理解它的工作方式依然很重要，因为它是整条调用链中承上启下的关键环节。

Client做的事情，本质上就是把“模型想调工具”这个意图，翻译成标准化的JSON-RPC请求，然后塞进传输层发给Server。这里涉及的协议方法就这么几个：

• initialize：客户端和服务端握手，确认协议版本和双方能力
• tools/list：获取工具列表
• tools/call：调用指定工具并传入参数
• resources/list、resources/read：访问服务端暴露的资源（比如文档内容、数据库数据）

下面是一段完整的JSON-RPC通信过程，你感受一下：

// 第一步：握手 {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"demo-client","version":"1.0.0"}}} // 第二步：发现工具 {"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}} // 第三步：调用工具 {"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_weather","arguments":{"city":"北京"}}}

2.4 MCP Server：工具的真正执行者

Server这端收到tools/call请求后，第一件事是根据请求里的工具名找到对应的处理函数，然后把arguments里的参数解析出来，执行真正的业务逻辑，最后把结果包装成标准格式返回。

这个返回格式需要特别说明一下，因为新手最容易在这里犯错误。MCP协议规定，返回内容是一个content数组，数组里的每个元素可以是有固定结构的文本、图片或资源引用：

{ "jsonrpc": "2.0", "id": 3, "result": { "content": [ { "type": "text", "text": "北京当前气温25摄氏度，晴，西北风3级" } ], "isError": false } }

为什么需要这个统一格式？因为只有当结果以这种标准化结构返回时，大模型才能稳定地从里面提取关键信息，再结合用户的原始问题生成最终答案。很多人自己写工具调用时返回格式非常随意，一会儿返回纯文本一会儿返回嵌套JSON，模型解析起来就会时灵时不灵。

2.5 调用链为什么要这么设计：一次失败带来的启发

我自己早期写过一个不规范的MCP Server，当时图省事没有遵循协议，直接在工具函数里把业务结果打印到了控制台，然后想着“反正Client能看到服务端日志”。实际跑的时候模型完全不知道工具执行成功没有，因为协议定义的是结果必须通过content字段返回，而不是通过标准输出返回。那次排查花了我整整一个下午，最后才发现是我自己把返回格式写错了。

这个经历让我对MCP调用链有了一个非常深刻的认识：MCP的调用链本质上是一套“契约”。每个环节都有明确的输入输出约定，只要有一个环节不遵守约定，整个链路就会中断或者返回错误结果。协议本身不复杂，复杂的是你是否愿意按照它的规矩来。理解了这个，后面遇到任何MCP的问题，你都只需要顺着调用链一项一项排查就行：模型有没有选对工具？Client有没有发出正确的tools/call？Server有没有收到？Server执行完后有没有按格式返回？

3. 动手搭建：从零实现一个MCP Server并接入客户端

3.1 方案选型：走stdio还是走HTTP/SSE

搭建MCP Server第一步要选传输方式。目前最常见的有两种：

stdio方式：客户端直接启动Server进程，双方通过标准输入输出进行JSON-RPC通信。这种方式的优点是本地部署简单，不需要开端口，适合开发调试。缺点是无法远程访问，Server必须和Client在同一台机器上。

HTTP/SSE方式：Server启动一个HTTP服务，客户端通过SSE（Server-Sent Events）接收消息，通过HTTP POST发送消息。优点是支持远程部署，一台服务器可以被多个客户端共享，适合生产环境。

我个人的建议是：学原理、做实验阶段，直接用stdio就完了，配置最简单，出问题也好排查。等真正要把MCP能力部署到服务器上给团队用的时候，再切换成HTTP方式。

3.2 实操：用TypeScript写一个最小可用的MCP Server

下面这个示例会创建一个只有两个工具的MCP Server：一个获取当前时间，一个做加法运算。代码非常简单，但是麻雀虽小五脏俱全，所有关键协议环节都在里面了。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { z } from "zod"; // 创建MCP Server实例 const server = new McpServer({ name: "demo-tools", version: "1.0.0" }); // 定义一个获取当前时间的工具 server.tool( "get_current_time", "获取当前服务器时间，返回ISO格式的日期时间字符串", {}, async () => { const now = new Date().toISOString(); return { content: [{ type: "text", text: now }] }; } ); // 定义一个整数加法工具 server.tool( "add", "计算两个整数的和", { a: z.number().describe("第一个加数"), b: z.number().describe("第二个加数") }, async ({ a, b }) => { const sum = a + b; return { content: [{ type: "text", text: String(sum) }] }; } ); // 使用stdio传输启动 const transport = new StdioServerTransport(); await server.connect(transport); console.error("MCP Server started");

这里特别说明两个容易被新手忽略的细节：

第一，server.tool()这个方法一共接收四个参数，分别是工具名、工具描述、参数Schema、以及执行函数。工具名和工具描述会被模型看到，直接影响模型选不选这个工具，所以要写清楚。我之前见过有人把描述写成内部注释风格，比如“service method for internal use”，结果模型死活不肯调用这个工具，因为模型根本判断不出来它到底是干嘛的。

第二，日志不要往标准输出里打。stdio模式下，标准输出是用来传输JSON-RPC协议消息的，你在这里打日志会直接污染协议数据流，导致Client解析失败。正确的做法是用console.error打印日志，这样日志会输出到标准错误流，和协议数据分离开来。

3.3 编译并接入Claude Code或Cursor

上面那段代码是TypeScript写的，直接用之前需要编译成JavaScript。在项目根目录执行：

npm install @modelcontextprotocol/sdk zod npx tsc index.ts --outDir dist --module NodeNext --moduleResolution NodeNext --target ES2022

编译完成后，你需要把这个Server接入一个支持MCP的客户端进行验证。以Claude Code为例，在配置文件（claude_desktop_config.json）里加一段：

{ "mcpServers": { "demo-tools": { "command": "node", "args": ["/绝对路径/dist/index.js"] } } }

配置完成后重启客户端，在聊天窗口问一句“现在几点”，如果配置成功，模型就会自动发现get_current_time这个工具，然后调用它，把所有步骤走完。这也是验证你调用链是否打通的最快方式。

3.4 如何接入外部现成的MCP Server

有很多MCP Server是不需要自己写的，直接用别人已经封装好的就行。开发中最常用到的几类：

• Playwright MCP：让AI直接控制浏览器，做自动化测试、页面抓取
• Figma MCP（以及国内的蓝湖、MasterGo MCP）：让AI读取设计稿内容，辅助前端开发
• Blender MCP：让AI操作Blender建模
• 数据库MCP：将各种数据库暴露成工具，让AI直接查询数据
• 浏览器工具MCP（Chrome MCP等）：提供浏览器扩展能力

以Playwright MCP为例，在Claude Code里接入只需要一行命令：

claude mcp add playwright -- npx @playwright/mcp@latest

如果你用的是Cursor，需要在配置文件里指定npx命令和包名。原理上和你自己写的Server完全一样，都是通过标准协议暴露工具，区别只是工具的底层实现是别人封装好的。

3.5 MCP工具市场：去哪找更多现成的Server

很多人问“MCP工具市场在哪里”，目前还没有一个官方统一的“应用商店”概念，但实际上生态里已经有了几个聚合地：

• 官方/社区聚合网站：比如modelcontextprotocol.io官方的Server列表、PulseMCP、Smithery等社区平台，上面按照分类整理了大量的现成MCP Server，从数据库到设计工具到支付接口都有
• GitHub搜索：直接搜awesome-mcp或者mcp-server，能找到大量开源项目
• 各大SDK生态：Spring AI Alibaba、LangChain、Dify等框架的官方仓库里都维护了接入MCP的最佳实践和示例

我的建议是：能用现成的就用现成的，优先看Star数和文档完善度，别自己重复造轮子。只有当现有Server不满足你的特定业务逻辑时，才值得写一个自定义Server。

3.6 在Dify等低代码平台中配置MCP

除了代码方式接入，现在很多低代码/AI应用平台也支持通过图形化界面的方式配置MCP。以Dify为例，你可以在“工具”页面添加自定义工具，选择“MCP标准协议”，然后把Server的地址或命令填进去。平台会自动去拉取工具列表，然后把工具变成可视化节点，直接在Agent工作流里拖拽使用。

这种方式对非开发人员特别友好，不需要理解JSON-RPC，不需要写代码，只需要知道Server地址就够了。但当配置出现问题的时候，你依然需要回到调用链的思维去排查：工具列表有没有拉取成功？参数映射对不对？返回结果格式有没有被平台正确解析？

4. 调用链上的常见坑：排错实录与避坑指南

4.1 “工具消失了”：tools/list阶段出问题

这是最常见、也最莫名其妙的一种情况：昨天还好好的工具，今天客户端里就是找不到。顺着调用链排查会发现，问题往往出在Server进程启动失败了——可能是端口被占用、依赖包没安装、Node版本不兼容，Server根本没成功跑起来。但客户端只显示“工具列表为空”，不会告诉你是Server挂了。

排查方法：先在命令行手动执行一次Server启动命令，看看有没有报错，能不能正常输出协议数据。如果手动启动都报错，那问题百分百在Server本身。

4.2 模型怎么都不调用工具：问题出在提示词和工具描述

很多人遇到“工具明明加载出来了，但模型就是不调用”的情况。顺着调用链看，问题通常出在模型决策这一步：要么是工具描述太模糊，模型判断不出来这个工具和当前用户需求有什么关系；要么是用户的问题和目标工具的功能之间存在较大的语义鸿沟。

我踩过一次具体的坑：给一个数据库MCP Server配置了工具，工具名是query_db，描述是“执行SQL查询”。我用的时候问模型“上个月销售额是多少”，模型每次都不走工具，直接回答说“我没有该数据”。后来我把描述改成了“根据用户业务问题生成SQL并查询数据库，常用于统计报表、销售数据分析、用户行为分析等场景”，模型立马就学会调用工具了。

细品一下这里面的差异：工具名和描述是模型判断“该不该用”的唯一依据。描述写得越贴近用户的实际口语表达场景，模型的命中率就越高。

4.3 参数格式不对：JSON Schema写得太随意

MCP Server的参数定义用的是JSON Schema，而这个Schema直接决定了模型能生成出什么样的参数。如果你把参数定义得太宽松，比如允许任意字符串，模型传参就容易乱套；如果定义得太严格，模型又可能因为搞不清该填什么而放弃调用。

我的建议是：每个参数都要写清楚类型、必填与否和描述，能用枚举值约束的就用枚举值。比如定义一个“查询类型”参数，可以明确写enum: ["sales", "user", "product"]，这样模型就没法自由发挥了。参数Schema写得越规范，调用链就越稳。

4.4 网络与认证问题：HTTP方式下的特殊坑

从stdio切到HTTP方式后，会遇到一类新问题：认证和网络策略。MCP现在已经开始支持OAuth认证，但不同平台对这个认证流程的支持程度不一。有的客户端只会弹出一个链接让你去浏览器授权，有的根本不弹，直接报401。

我在用某平台接入远程MCP服务时遇到过很诡异的问题：本地用curl测试接口是通的，但客户端连接就是超时。排查到最后发现是防火墙只允许了HTTP的18888端口，却把SSE长连接的超时时间设置得太短，连接刚建好就被掐断了。这类问题光看MCP日志看不出来，需要回到网络层排查。

4.5 工具越多越好？上下文窗口够用吗

还有一个容易被忽略的问题：MCP Server暴露出的每个工具描述都会占用模型的上下文窗口。当你接入的Server越来越多、每个Server的工具越来越多，模型的可用上下文就会被大量消耗，直接影响对话质量和上下文连贯性。

我实际测试过：一个工具描述平均600到1000字符，10个工具就是1万字符左右。如果一个模型上下文是2万字符，那还没开始聊正经内容，一半就没了。所以不要让Server暴露太多无关工具，尽量保持工具列表精简。这也是为什么你在生产环境应该把多个小Server合并成一个大Server，而不是动不动就新开一个。

5. 基于调用链的MCP学习路线：从零到能干活

5.1 阶段一：先把最小调用链跑通

很多人的MCP学习都倒在了“一上来就研究协议细节”上面。我建议反过来，先把最小调用链跑通再说。具体操作就三步：

1. 用现成的MCP Client（Claude Code、Cursor这些）接入一个现成的MCP Server，比如Playwright
2. 在聊天窗口发一个需要调用工具的诉求，比如“打开百度搜索MCP”
3. 观察整个调用过程，看模型是怎么选工具、传参数、解读结果的

这个阶段的目标不是理解所有细节，而是建立对调用链的整体直觉。你需要在脑子里形成一张图：用户说了什么 → 模型想到了什么工具 → 工具收到了什么参数 → 返回了什么结果 → 模型最后回复了什么。

5.2 阶段二：读懂代码，自己写一个Server

跑通现成链路之后，强烈建议照着第三节的示例代码自己撸一个Server出来。不用一上来就写多复杂，两个简单工具就够了。重点不是写多好的代码，而是通过写这个过程，反过来理解协议层的设计意图。

写的过程中你会自然地搞清楚这些问题：工具描述应该写到什么详细程度？参数Schema为什么必须严格定义？返回格式为什么必须是content数组？理解这些之后，你在调试排错时就不会再一头雾水了。

5.3 阶段三：场景化集成，解决真实问题

等到自己写过Server，对协议和调用链有了手感，就可以去搞场景化集成了。挑一个你实际工作里遇到的高频痛点，把它做成MCP工具。比如：

• 如果你是前端开发，接一个Figma MCP或者蓝湖MCP，让AI能直接读设计稿规范
• 如果你是测试，接一个Playwright MCP，让AI帮你自动跑回归用例
• 如果你是后端，把你们的内部接口封装成一个MCP Server接入公司内部的AI辅助平台
• 如果你用Spring AI Alibaba做应用，可以直接按官方文档把第三方MCP服务注册进去，然后在应用里通过Agent调用

这个阶段的核心任务，是把MCP调用链嫁接到真实业务场景中，让AI的能力不再停留在“聊天”层面，而是真正能操作真实世界的工具。

5.4 阶段四：进阶，深入协议和框架生态

到了这个阶段，你已经具备独立开发和排障的能力了。再往后走，可以开始研究一些进阶话题：MCP的采样机制、OAuth认证的安全细节、资源模型的用法、分布式部署方案、以及在多Agent框架里通过MCP编排多个AI智能体协作。

我个人觉得，如果只是用MCP，完全没必要把协议文档啃完。但如果你想在团队里做技术选型、或者开发一个给很多人用的MCP Server，那协议文档里的生命周期、错误处理、版本兼容这些章节还是值得认真读一遍的，因为生产环境对稳定性的要求比个人实验高得多。

最后说点实在的

我学MCP的过程走了不少弯路，前期最大的问题就是没有建立调用链的整体视角，陷入到一个一个协议细节里出不来。后来有一次调试一个数据库MCP，我对着日志把七个环节一个一个过，才发现问题出在很简单的参数类型不匹配上，那一刻突然就通了：MCP的核心从来不复杂，复杂的是它被封装在各式各样的框架和平台里，让人看不到底层的链路。

如果让我给一条最实用的建议，那就是：遇到任何MCP相关的问题，都把这条调用链默写在纸上，然后从第一环开始逐个检查。模型决策有问题就看工具描述，Client发请求有问题就看客户端日志，Server执行有问题就看服务端日志，返回结果有问题就看内容格式。掌握这个思路，比背一百个配置项都有用。