实操干货！MCP Server开发从0到1

最近 Model Context Protocol ( MCP ) 概念大火，刚好它可以用 Node 或 Python 来编写，作为一名 web 前端程序猿，怎么可以错过这个工具的探索。文章是记录本人做 MCP Server 工具开发的时候遇到的一些问题，以及自己的一些关于 AI 的感想。

关注腾讯云开发者，一手技术干货提前解锁👇

鹅厂程序员面对面直播继续，每周将邀请鹅厂明星技术大咖深入讲解技术话题，更有精美周边等你来拿，记得提前预约直播～👇

🏃揭秘腾讯云爆款产品！抢跑618，开发者直播间限定福利，爆款低至1元起，手慢无！

01

MCP 协议简介

Model Context Protocol (MCP) 是由 Anthropic 提出的开放协议，旨在标准化 AI 大模型与外部数据源和工具的连接。官网称 MCP 为 AI 应用的 USB-C 端口，提供一种将 AI 模型连接到不同数据源、工具的标准化方法。目前，包括 Block、Apollo、Replit 等知名企业已开始采用 MCP 协议，显示出其在 AI 领域的重要地位和发展潜力。

简单来说，MCP 是一种客户端-服务器架构的协议，允许 LLM 应用程序（如 Claude、各种 IDE 等）通过标准化的接口访问外部数据和功能。这解决了 LLM 在实际应用中常见的一些痛点：

• 无法直接访问实时数据（如天气、股票行情等）；
• 无法执行外部操作（如发送邮件、控制设备等）；
• 无法访问用户的本地文件或其他私有数据（如性别、年龄、收入等）。

通过 MCP，这些限制得到了优雅的解决，同时保持了安全性和可扩展性。所以也有人说，MCP 是 AI 的 “Type-C”，统一接口接入各种工具。

图片

02

MCP 主要架构

MCP 采用客户端-服务器架构，主要包含以下几个组件：

• MCP 主机（Host）：如 Claude Desktop、IDE 或其他 AI 工具，通过 MCP 访问数据。
• MCP 客户端（Client）：与服务器保持 1:1 连接的协议客户端。
• MCP 服务器（Server）：轻量级程序，通过标准化的 MCP 协议公开特定功能。
• 本地数据源（Local Data Source）：计算机上的文件、数据库和服务，MCP 服务器可以安全访问这些内容。
• 远程服务（Remote Service）：通过互联网可用的外部系统（例如通过 API），MCP 服务器可以连接这些服务。

整个流程大致是这样：

目前，MCP 还处于发展初期，但其潜力巨大。更重要的是生态，基于统一标准下构筑的生态也会正向的促进整个领域的发展。概念是 2024 年底才提出，几个月不到，在 GitHub 上的 Star 数已经突破 20K，可为相当火热。

03

MCP 开发踩坑经历

以 查询今天广州天气 为例子，以下分享一下自己在开发 MCP Server 工具时踩过的坑。

https://github.com/modelcontextprotocol/quickstart-resources/tree/main/weather-server-typescript

3.1 环境

MCP 无论是开发，还是使用，都对 Node 版本有要求，要求 Node >= 18。所以如果你一开始用 Node < 18 进行包安装之后，就算后面切换成正确的 Node 版本，MCP Server 依然不能正确地跑起来。需要重新安装依赖包 modules。

建议：一开始就确认自己的环境是否正确，再进行安装。

3.2 调试

参考上文提到的 MCP 时序图，是 Client 端调用的 Server 。所以，要想断点调试，就必须需要 Client 在调用 Server 的时候启动断点调试 ( node --inspect )。目前看来，起码 Cursor 是不支持断点调试的，其它工具或许支持，有待探索。

官方提供了一个调试工具，不过该工具更多的是围绕 MCP 协议本身的调试，调试界面如下图：

其中，日志记录可以通过以下方法来输出：

const mcpServer = new McpServer({
  name: 'your-mcp-tool',
  version: '1.0.0',
}, {
  capabilities: {
    logging: {} // 开启日志记录，必须，不然报错
  }
});
async function main() {
  // ...
  mcpServer.server.sendLoggingMessage({
    level: 'info',
    data: 'Server started successfully',
  });
}

官方文档曾让我误解，包括 初始化 McpServer 的 capabilities 的 logging 的时候如果不传会报错，直到翻源码才发现正解 ......

建议：如果调试的时候有问题的话，可以先按上述方法来检验，然后可以去看文档，源码，已实现的 MCP 工具。

文档：https://modelcontextprotocol.io/docs/tools/debugging

源码：https://github.com/modelcontextprotocol/typescript-sdk

已实现的 MCP 工具：https://modelcontextprotocol.io/examples

3.3 使用

MCP 工具的使用倒是比较简单，关键是 Client 端最好是用上最新的版本来支持 MCP 的新特性，比如 Cursor ，需要更新之后才能方便地配置环境变量 env，因为我们一般需要把 token 或 API_KEY 之类的密钥传给工具来进行接口调用。如下图：

可以参考 Github MCP 的用法。

（https://github.com/search?q=repo%3Amodelcontextprotocol%2Fservers%20GITHUB_PERSONAL_ACCESS_TOKEN&type=code）

3.4 幻觉

有时候在使用 MCP 工具 的时候，不可避免会遇到它的幻觉问题，如下图：

根据工具，它已经拿到了最新时间 2025-03-27，但是在调用下一个 MCP 工具的时候，时间还是搞错成 2024 了。

建议：

• 方法一：丰富 prompt。在时间前面加上 「根据当前时间」，比如上图的就是，“根据当前时间，查今天广州天气”。
• 方法二：参数矫正。比如参数里只让模型提供月-日，年份由 MCP 工具 来补充。
• 方法三：使用 MCP Prompt 来丰富 prompt。不过这个因为比较少 MCP Client 支持，所以这里不过多介绍，有兴趣的同学可以看看官方文档。https://modelcontextprotocol.io/docs/concepts/prompts

兼容性如下图，可以看到大部分工具都只是支持 MCP Tools 而已：

3.5 错误重试

由于网络抖动，一旦出现失败，整个咨询过程就会失败，模型分析也会失灵，同时也浪费了模型资源。

建议：如果工具涉及到网络请求，可以考虑做错误重试机制，如设定重试次数和间隔时间，以免出现网络抖动或其它因素导致请求失败。

3.6 MCP 工具列表

最后贴一下一些比较好用的 MCP 工具：

• 官方推荐：https://modelcontextprotocol.io/examples
• mcp.so：https://mcp.so/

04

关于 AI 的感想

在看到 MCP 工具正确返回的时候，我内心是很兴奋的，如下图：

它不但理解了返回的 JSON 数据，还附带了自己对数据的理解，并给出了一些合适的建议。看起来是很美好是不是？

但是，当我自己去百度一下之后，我看到了下图的展示：

看到这个丰富的 UI 展示之后，我陷入了沉思。我一直希望通过 AI 对话实现各种各样的能力，给它配上各种工具（比如这次的 MCP 工具），让它功能越来越强大，自以为是地认为这是很牛逼的未来，但，真的是这样么？

偶然间看到了一篇文章，里面有一段话很是触动我：

做个比喻，我小学时代刚开始用电脑是Dos系统，那就是命令行输入和一行行的数据输出的文本来回交互，那个时代的应用软件以及体验，是完全无法和进入视窗时代，windos系统的应用比拟的。我们计算机的发展，给我们带来了各种更丰富友好的交互体验（各种radio box, check box, button, drow box控件到鼠标，触摸屏外设），为啥因为一个像人对话一样的想象，要把自己的应用反而导向到原始的仅有文字来回的交互呢？

是啊，为什么在交互设计上，我们要倒退回去呢？文章中引申出一个概念，值得思考：我们要 对话连接服务，还是服务融入对话？以下是我自己的一些思考：

对话连接服务，简单可以理解为在对话的过程中，可能给你一张图片，一个链接，甚至是一个电商小程序，点击即可跳转去选品。强调服务本身流程和专业性，对话作为辅助手段。专业用户对特定服务流程熟悉，可能更倾向直接在专业界面去进行操作，对话仅在遇到问题或特殊说明时介入。

服务融入对话，就是上文提到的，纯文字告诉我广州天气：以对话交互为核心，将服务功能融入自然语言对话。如通过与 AI 对话查询天气，AI 调用后台接口查询并在对话展示结果，降低使用门槛。这种能力，往往在特定人群和特定场景下需要，比如:

• 老年用户：因为老年用户往往是有 视觉障碍 和 认知障碍 ，他们可能已经老到看不清手机上的文字，因为年纪大，对新鲜事物的认知也不足，「🔍」放大镜这个图标对他们来说，很难理解为什么能点击查东西。如果有 AI 的帮助，说不定能解决很多他们的认知问题。好比如果能通过语音来帮他们调用现在交互复杂的互联网服务，“帮我打一辆去广州塔的车” 或 “帮我点一份番茄炒蛋，送到xxx地方”。

• 外国友人：同样的，国内很多服务都是基于中文去建设的，外国友人来中国的话，有时候会因为语言问题，无法实现自己想要的能力，比如上文提到的电商，从选品，到添加购物车，到地址填写，到下单，每个步骤在不同的 APP，UI 都是不一样的，有的甚至连流程都不一样，比如 拼多多 都没有购物车，其中又充斥着大量他们可能看不懂的中文，导致试错成本急剧上升。AI 的出现，说不定就能比较低成本地解决这个问题。

• 无法解放双手的你：是的，在你开车的时候，通过 AI 帮你点一份到家的外卖，在你回到家直接能吃上。或者在你做饭的时候，帮你发一条消息给伴侣，告知 ta 今晚有什么晚餐，好让 ta 早点回家。又或者一个人玩王者荣耀，但是又希望有个瑶妹辅助的你：

这三种场景，可以归纳为 用户无法做出该服务预期动作的场景下，我们可以选择让服务融入 AI，让 AI 来辅助用户。

回顾两者，对话连接服务，适当时候导向服务，提高流程的命中率和成功率。服务融入对话能让用户通过语音指令让 AI 完成复杂任务，提高效率和便捷性。

小孩子才做选择，作为成年人，肯定是两者都要。在我希望它是对话时，它是对话。当我希望它能给我服务时，它也能给我服务。比如对话告诉 AI，“我想买一个鼠标，给我商品展示链接”，点击链接跳转到商品展示，选品后，剩下的流程，我希望对话解决，“就这个，帮我下单，送到家”。所以，服务和 AI 的结合，除了取决于使用者本身能力以外，还得取决于使用场景，不能一概而论，更不能为了蹭 AI 的热度，就滥用 AI，或扭曲已有的交互模式。

上述梳理了下 AI 的使用模式，那么 AI 目前已有的能力有哪些？我自己整理了下：

• 海量知识与信息整理能力：AI 拥有海量知识输出能力，并且能处理海量信息，快速从中整理归纳出有效内容。这里并不是说 AI 等同于数据库 // 图书馆一类的知识存储型的角色，而是它理解了字与字之间的联系，并根据上文推导出下文，所以如果它是一个训练了海量优质数据的模型，那么它也能提供海量知识的输出。
• 非结构化数据处理能力：擅长将非结构化数据梳理成结构化数据，比如将中文转换成符合 API 服务要求的结构化数据，如在查询天气时，AI 把「广州」识别成城市，并转换成 { "city": "广州" }
• 快速学习与自适应能力：随着处理数据量增加，AI 能优化算法和模型，在后续处理相似任务时表现更出色。这是因为 AI 受训练数据的影响，随着算力资源、基座模型，训练算法、反馈机制 等各方面的提升，所以 AI 的学习效率以肉眼可见的速度提升，2年间就天翻地覆，所以未来 AI 能做的事情估计远超想象。
• 自动化与不间断运行：AI 可实现自动化，24 * 7 不间断运行，不受时间、精力和体力限制，能随时响应任务，提高业务连续性和响应效率。
• 重复性任务处理优势：处理重复性任务时，AI 不会像人类因重复工作而疲惫或出错，能保持稳定处理质量和效率，适用于反复执行特定查询或数据处理场景。 最后两点，均能够很好地说明，AI 是天生的优质牛马，只是现在它能力还未能充分展示。

AI 毫无疑问是下一个时代的趋势，在这种背景下，我们要做的只是顺势而为，AI 不是万能的，所以无需焦虑，把它想象得如何强大，我们需要做的是如何学会驾驭这种新的技术。

当人类发明汽车之后，你要做的不是去和汽车赛跑，而是去考一个驾照。