你知道MCP是如何工作的吗？

MCP工作原理解析

最新推荐文章于 2025-12-05 11:17:30 发布

智弦智创

最新推荐文章于 2025-12-05 11:17:30 发布

阅读量313

点赞数 8

CC 4.0 BY-SA版权

分类专栏： MCP极简入门文章标签：人工智能

本文链接：https://blog.youkuaiyun.com/WebCraft/article/details/154990818

MCP极简入门专栏收录该内容

2 篇文章

订阅专栏

MCP就像是AI大模型与外界沟通的桥梁，它让AI能够更高效地获取和使用外部数据、工具和功能。为了加深理解，我们可以用通俗的类比来解释MCP。那么，基于MCP的系统到底是如何工作的？

首先，我们得知道基于MCP的系统是由哪些部分组成的。基于MCP系统的架构就像是一个团队，有明确的分工和协作方式。MCP主机就像是团队的接口人，它发起连接并管理整个交互过程；MCP客户端则是负责与外界沟通的“使者”，它维持着与MCP服务器的连接；而MCP服务器是提供各种资源和工具的“后勤部门”，通过标准化的协议为客户端提供服务。

接下来，我们会深入解读MCP，看看它是如何确保各方之间顺畅、安全地通信的。同时，我们会弄清楚传统的API、传统的AI应用、大模型服务、大模型调用第三方工具与基于MCP的系统之间的区别和联系。

当然，MCP在支持搜索和执行任务方面也有着独特的优势，本章最后将以一个天气查询的应用场景为例，介绍MCP所带来的高效和便利。

MCP的通俗类比

想象你家的电视、空调、扫地机器人各有一个遥控器，你每次使用的时候，可能都得翻箱倒柜才能找到对应的那个。通过MCP，就像是给全屋电器配了一个万能遥控器——不管什么品牌、什么型号，一个按键就能操控。

现在把这个场景搬到AI世界，ChatGPT查询天气，DeepSeek调取公司销售数据，文心一言操作智能打印机。以前的做法就像给每个大模型发了一个专用遥控器，开发者为天气预报数据定制接口需要1周时间，为京东后台的销售数据编写适配代码需要2周时间，引入打印机的驱动程序并编写操作代码可能需要3周时间。而基于MCP的方案如同给所有的电器装上智能插座，气象局在“数据插座”上开个接口，所有的智能体插上就能查询天气，连上智能打印机的MCP服务就能够即插即用。

MCP的发展就像手机充电接口的进化史。在诺基亚时代，每个品牌的手机的充电接口都不一样，现在则是Type-C一统江湖。过去每个大模型对接系统都需要定制，如今MCP让数据流动像手机充电一样简单。从此，开发者不用再当“接口焊工”，而可以专注于教大模型更聪明地使用这些现成工具，就像家长不用教孩子造电视机，只需教会他们使用遥控器一样。

再举一个现实生活中的例子。当你的AI助手想完成一顿智能大餐时，你说“来份今日套餐”（例如“查询北京明天天气”），服务员（MCP的主机/客户端系统）立即记录需求：“3号桌要气象套餐，微辣”（将自然语言转换为标准指令），然后跑向不同的窗口。在冷菜间（气象局数据库）取温度数据，在热炒区（空气质量API）要PM2.5数值，在甜品站（天气预报模型）拿降水概率。厨师长（MCP服务器）检查每道食材：

• 确认数据新鲜度（实时性验证）。

• 检测是否有异物（数据格式校验）。

• 核对点单权限（比如普通用户只能获取3天内的预报）。

然后，服务员将拼好的天气套餐端上桌：

北京明日天气：

25℃～32℃ | 东南风3级

降水概率40% | 空气质量良

我们无须冲进厨房盯着火候，基于MCP的系统让AI助手只需“动动嘴”，就能吃上由专业团队准备的定制化数据大餐。这套服务既避免了AI助手自己下厨（直接对接系统）可能引发的火灾（系统崩溃），又能保证菜品的质量（数据安全、可靠）。

基于MCP的系统是如何组成的：架构解读

基于MCP的系统提供了一种有状态、能保持上下文的框架，它能帮助人们在与AI聊天机器人交流时，让对话变得更流畅、更有深度。这个框架有个特别之处，就是它能“记住”对话的上下文。该框架用的是有限状态机来管理对话的状态，让对话的每一步都清清楚楚、明明白白。基于MCP的系统框架与API不一样，API的每次请求都被当作一个新的操作处理，而该框架是把对话当成一个连续的故事来进行的。

基于MCP的系统中有个持久又灵活的上下文层，该上下文层能记住之前说过的话，学到新知识，然后随着对话的深入，自己就能想出下一步该怎么做。这样一来，AI就能更懂我们，对话也就更自然、更像人和人之间的交流。而且，MCP提供了统一的接口描述方式，实现了以智能体为中心的设计，更方便基于大模型的应用集成。

依据modelcontextprotocol.io所述，基于MCP的系统由以下三大核心支柱构建。

(1)记忆便签（有状态）

每次对话生成一张即时贴：

□ 7月5日：用户需要周三买礼物

□ 7月7日：用户询问礼物建议

这些便签按时间贴在虚拟白板上，形成连续对话脉络。

(2)万能适配器（互操作性）

就像智能插座统一所有充电接口：查询天气，插气象局接口；订机票，插航空公司系统接口，每个接口自带说明书（标准协议）。

(3)自主决策（以智能体为中心）

设定好目标后，基于MCP的AI助手就像一个靠谱的管家。周三早晨自动执行：检索过往对话并确认需求，在3个电商平台进行比价，生成《最佳礼物选购方案》并弹出提示“发现京东有现货，现在下单？”。

以订机票为例，传统的AI助手是这样的：

用户：帮我订后天北京到上海的机票。

AI：好的，请提供身份证号和出行时间。

而基于MCP的AI助手则是这样的：

AI：检测到您上月常坐早班机，已筛选：

□ CA1508首都T3—虹桥7：30

□ 经济舱¥680（比上周降15%）

□ 根据历史记录，已预填您的常旅客号

基于MCP的系统让AI从一问一答的复读机，进化为会主动联系上下文、协调多方资源的智能秘书。就像给机器人安装了记忆芯片和工作手册，让它真正理解“现在该做什么，接下来要准备什么”。

基于MCP的系统采用的是客户端/服务器(C/S)这种常见的架构模式，主要由3个关键部分组成：MCP主机、MCP客户端（一般直接集成在MCP主机中）以及MCP服务器，如图1所示。

MCP主机好比一个装着AI聊天机器人的应用系统，像我们常用的那些聊天软件，它的任务就是发起各种请求，MCP客户端可以与主机集成在一起。而MCP服务器的作用是向MCP主机提供访问所需数据和工具的“通道”。MCP主机、MCP客户端和MCP服务器三者之间是通过MCP来快速、高效地交流信息的。

MCP主机

MCP主机是一种基于AI的智能交互系统，主要负责连接和调用MCP服务器的资源。比如，我们常见的智能编程工具、聊天机器人或企业数据分析平台都采用了这种技术。

在用户通过聊天窗口等界面提出问题后，这个智能交互系统会先与后台服务器进行“对话”，共同筛选出适合解决当前问题的功能模块。随后，系统会将用户问题与筛选出的功能模块一起发送给后台的智能决策引擎（大模型），经这个“智能大脑”综合分析后，最终选定最适合解决问题的工具组合。

MCP客户端

MCP客户端相当于智能应用中的“专属接线员”，主要负责在自己所属的软件系统（如编程工具、聊天软件等）和特定服务器之间架起沟通桥梁。这个接线员有3个核心职责：将用户请求转换成标准格式、处理服务器返回的信息，以及确保整个通信过程的安全、可靠。

举个例子更容易理解：当你想让智能助手帮忙查看在GitHub上提交的代码修改时，客户端就像个经验丰富的秘书，它先找到对应的GitHub服务器，把需求整理成标准格式发送过去，收到回复后再整理好交给智能助手。这相当于为人工智能搭建了与外部世界沟通的安全通道。

具体来说，这个“专属接线员”需要完成以下工作：为每个服务器建立专属的通信通道、确认双方都能理解的沟通方式、确保信息准确送达、管理消息订阅和推送提醒，以及像设置防火墙一样维护不同服务器之间的安全隔离。

MCP服务器

MCP服务器按照统一规范为各类智能应用提供所需的“养料补给”。这些养料补给可能是整理好的数据资料（比如文档、表格）、可操作的功能（比如调用接口、运行程序），或者预设的智能应答模板。它能连通数据库、软件接口、本地文件甚至程序代码，相当于给AI配备了一个百宝箱，确保智能助手随时能找到需要的信息。

这种“智能补给包”包括3类AI上下文：

• 数据补给：为AI即时输送整理好的信息，比如最新文件、数据库查询结果、接口返回数据等。

• 功能补给：让AI能操作外部服务的“工具包”，例如自动发送邮件、更新客户管理系统、调用网络接口等。

• 提示词指南：预设的智能应答模板，就像给AI的“参考答案”，帮助它生成更符合需求的回应。

例如：当需要安排会议时，MCP服务器能自动调取日历数据；当需要写报告时，MCP服务器可以即时获取数据库最新数据。在科研场景中，研究者通过MCP服务器就能一站式查询到所需的论文资料和实验数据。这种智能连接能力，让AI助手真正实现了从“能回答”到“能办事”的跨越。

MCP服务器的重要性，可以用“打破AI的信息孤岛”来形象理解。当前即便是最聪明的AI助手，也像戴着枷锁的百科全书——它们只能记住训练时学过的知识，或者用户临时提供的内容。每次想让AI连接新的数据库、在线服务或实时数据源，都需要像给不同电器配专用插座那样单独开发对接程序，既费时费力又难以扩展。

MCP服务器的突破性在于打造了“万能智能插座”。它提供统一的连接标准和安全通道，让AI能够随时获取最新动态信息并完成实际任务。比如，一个AI助手既能查阅知识库最新资料、查看团队日程表，又能代发工作邮件，而这些功能就像插拔标准插头一样简单，不再需要为每个功能单独编写代码。

这种改变让AI真正融入了我们的数字生活：既能实时获取企业数据库中的销售数据，又能同步查看云盘里的项目文档，甚至能帮助操作日常使用的各种办公软件。正是通过这种与真实数据的无缝连接，AI从“纸上谈兵”的问答机器变成了真正懂业务、能办事的智能伙伴。

基于MCP的系统是如何运行的：工作原理解读

基于MCP的系统运行机制的核心是一个动态上下文窗口，就像一个会自己整理记忆的“盒子”。这个盒子会随着每次使用自动扩容，专门存放3类重要信息：用户的习惯设置（比如常用语言、说话风格）、过往对话记录（之前的提问和回答）、使用环境（比如当前设备、所在位置）。但为了避免信息堆积成山，系统会自动筛选盒子里的内容：把核心信息完整保留，将次要内容压缩成“关键词卡片”（例如把10条聊天记录提炼成几个核心要点）。

举个例子，当你用手机让AI助手订机票时，基于MCP的系统既记得你上次要求靠窗座位（用户偏好），又能调取之前讨论过的行程日期（会话记录），还知道你现在用手机操作可能需要简洁回复（设备环境）。而两周前的闲聊天气这类信息，早已被智能压缩成“曾讨论过出行天气”这样一张备忘卡片。

这种动态记忆管理的方式既保持了对话的连贯性，又避免了系统被海量信息拖慢速度，就像给AI配备了一个会主动整理重点的智能秘书，确保每次服务都能快速调取真正需要的信息。

基于MCP的系统的一般工作流程如图2所示。

图2展示了用户与AI助手互动，以及AI助手与MCP及外部工具进行交互的流程。

1) 用户提出问题。

2) AI助手向MCP服务器请求数据。

3) MCP服务器请求用户给予权限。

4) 得到用户权限。

5) MCP服务器连接到外部工具。

6) MCP服务器从外部工具中获取数据。

7) MCP服务器将信息发送回AI助手。

8) AI助手给出答案。

这个流程展示了用户、AI助手、主控处理模块以及外部工具之间的数据流动和交互过程。

简单而言，这种互动遵循以下简单的模式：

• 发现：客户端请求可用的工具。

• 自省：服务器提供工具描述和模式。

• 调用：客户端使用适当的参数调用工具。

• 执行：服务器执行请求的操作并返回结果。

基于MCP的系统就像一个会自主学习的“任务管家”，它能记住每个任务的进度，并灵活调整策略，比如发现用户不在线时，自动把邮件通知切换成短信提醒。更聪明的是，这个管家还会根据用户反馈自动优化服务，比如发现用户总跳过选项A选择B，就会主动调整推荐优先级。

关于MCP，很多人会问：“为什么要专门设计这个协议？AI不是能自己学会使用各种接口吗？”这个问题就像问厨师为什么需要备好切好的食材，而不是现场学切菜一样，理论上当然可以做到，但实际操作效率大不相同。

现实中，虽然大多数网络服务提供使用说明文档（类似菜谱），但让AI每次都要现场阅读并理解这些文档，就像让新手厨师边看菜谱边切菜，不仅耗时费力，还容易出错。MCP服务器的作用就是提前把“刀具”和“食材”都准备好——将复杂的接口功能转化成AI能直接使用的“预制工具包”。

这种设计带来的最直接的好处是用户体验的飞跃：原本需要等待数秒的复杂操作，现在几乎能实时完成；原本可能出错的随机应变，变成稳定、可靠的标准流程。这就像把手动挡汽车升级为自动挡一样，虽然最终都能到达目的地，但驾驶体验和效率却有天壤之别。

服务间的共识——MCP解读

下面从通信架构、通信方式和通信协议3个方面来深入理解MCP。

MCP的协议栈

MCP的协议栈（通信架构）采用四层抽象模型，就像建造房屋时的分层施工一样，如图2-3所示。

物理层就像快递员打包物品，专门负责数据包的封装和拆解。比如，将“打开卧室空调”这个指令转换成设备能识别的数字信号。传输层相当于物流公司，确保数据包准确送达。就像快递员会检查包裹是否完整一样，避免运输途中信息丢失或损坏。会话层类似于客服中心，全程跟踪对话状态。比如发现用户连续3次调整空调温度，会自动保持温度设置界面开启。应用层相当于操作说明书，定义每个功能的执行标准。例如“调节温度”不仅包含数值变更，还需同步更新设备显示屏。

这种分层设计就像搭建积木一样，下层专注基础工作，上层处理智能决策，既继承了传统网络架构的稳定性（如TCP/IP），又针对AI需求做了特别优化。

举个智能家居场景的例子，当你说“把客厅灯光调暗”时，系统从语音识别（物理层）、数据传输（传输层）、对话状态维护（会话层）到最终灯光控制指令生成（应用层），每个环节各司其职，确保服务既准确又高效。

MCP的双向通信方式

MCP的双向对话系统采用一种智能调度机制来处理多线并发的信息交换。这种设计的最大突破在于打破了传统“一问一答”的模式，让AI与外界的信息交流像真实对话一样自然流动。

我们可以把它想象成智能客服中心的工作模式：当多个用户同时咨询时，系统不会手忙脚乱，而是像经验丰富的值班经理，通过智能调度台（Reactor模式）同时处理语音留言、在线咨询、邮件等多种渠道的咨询需求。更重要的是，这个系统支持实时双向沟通——就像在视频会议中的即时互动，AI在对话过程中能持续接收新信息并调整回应策略。

例如，当用户通过AI助手预订国际航班时，系统不仅能即时获取最新票价（单向查询），还能在用户犹豫时主动推送备选方案（双向互动）。当用户临时添加行李托运需求时，AI会自动关联之前的行程信息，确保每个环节的决策都基于完整的对话背景。

这种双向沟通机制带来以下3个核心优势：

• 多任务并行处理：像高速公路的多车道，同时处理不同来源的信息请求。

• 动态信息更新：支持对话过程中实时补充新数据，类似新闻直播中的滚动更新。

• 情景记忆延续：自动关联前后对话内容，避免重复确认基础信息。

2.4.3 MCP的3种分类

基于MCP的通信系统就像智能邮局，采用统一格式的“标准信封”(JSON-RPC 2.0)收发信息。根据距离远近，它提供3种“寄送方式”。

(1)内部通话机(STDIO)

该方式适用于同一台设备内的“隔空对话”场景。就像办公室里的同事之间使用内部电话进行沟通，信息直接通过设备自身的“传声管道”（输入/输出接口）传递，无须外接网线。例如，用命令行工具快速调用数据分析功能。

(2)网络广播站(HTTP+SSE)

该方式适用于需要持续推送的在线服务场景。服务器就像24小时播报的交通电台，通过专用频道（HTTP的连接保持）不断发送实时路况。用户就像车载收音机，保持收听就能获取最新信息。在需要反馈时，可通过专用邮筒(HTTP POST)发送请求。

(3)实时流对话窗（Stream HTTP，2025年3月26日发布的版本中引入）

在Stream HTTP传输中，可以处理多个客户端连接，服务器可以选择服务器发送事件(SSE)来流式传输多个服务器消息。该方式适用于需要高频互动的场景，比如在线会议中的即时问答环节。

其中，STDIO（Standard Input/Output，标准输入/输出）方式通过设备自带的“信息通道”（输入/输出接口）直接传递数据，无须外接网络或其他复杂设置，省去了网络传输环节，速度较快。客户端和服务器如同左右手配合，不需要第三方协调，出错率极低。

而SSE（Server Sent Event，服务器发送事件）是一种实时数据传输技术。它的工作原理是建立一条专属通道：当用户访问网页时，浏览器会与服务器建立持续连接。通过这条“信息通道”，服务器可以随时主动向客户端推送新消息，而客户端只需要保持收听状态。

这种技术特别适合需要实时更新的场景，比如股票行情推送或即时比分显示。在模型通信协议中，SSE承担着信息传递的重要角色。服务器不仅能同时处理成千上万的用户连接，还具备身份验证和弹性扩展等实用功能。

在具体实现时，服务器会提供两个专用接口：一个是接收通道（SSE端点），客户端连接这个接口就能实时获取服务器推送的消息；另一个是发送通道（HTTP POST端点），客户端通过这个接口向服务器提交信息。这两个通道分工明确，共同构建起高效的双向通信系统。

STDIO和SSE这两种通信协议的对比见表1。

MCP的安全性

MCP的安全体系就像给数字世界打造了一座“智能金库”，通过五重防护机制确保每个环节的安全、可靠。

(1)加密保险箱(TLS加密)

所有网络通信都像用防弹运钞车运输，数据在传输时自动加密，防止在传输途中被窃听或篡改。

(2)智能门禁（OAuth 2.0认证）

采用“动态密码+指纹”双认证机制，类似于高级写字楼的访客系统。例如，当AI需要访问企业数据库时，必须出示实时生成的电子通行证，且仅限当次操作。

(3)权限分级(RBAC)

参照公司岗位设置访问权限，例如，实习生只能查阅基础数据，部门主管可修改业务信息，CEO拥有全部权限。

(4)双保险密室（双证书架构）

数据传输采用“双钥匙保管箱”模式：发送方用专用密钥加密，接收方用对应密钥解密。就像跨国贸易中双方通过指定银行交换密钥，确保交易全程受控。

(5)安全游乐场（沙盒机制）

AI操作被限制在“儿童安全围栏”内，通过独立空间运行程序（Linux命名空间隔离），设置资源使用上限（防止资源滥用），危险操作自动拦截（如禁止删除系统文件）。

此外，当发生意外时，系统自带“智能急救手册”，既帮助实时排障，又留存完整操作记录。

• 自动生成错误诊断报告（如“打印机连接超时——代码502”）。• 提供修复建议（如“请检查网络连接或重试”）。

• 记录完整处理流程供审计。

以医疗AI系统为例，医生查询病历时需动态验证身份（智能门禁），检查报告传输时自动加密（加密保险箱），实习医生只能查看基础病历（权限分级）。无论是医生还是实习医生，在读取病历时都使用专属密钥加密请求，AI系统使用对应的密钥解密（双保险密室），影像分析在隔离环境中运行（安全游乐场）。系统故障时马上提示故障原因，指导医生及时修复系统（智能急救手册），紧急故障时自动转备用方案。

这种安全设计让AI系统既保持灵活智能，又像银行金库般固若金汤，真正贯彻“智能不越界，数据不出圈”的安全理念。

基于MCP的系统有什么不同

市场上已经有各种各样的通信方式和集成方法，例如REST API、传统的AI服务、大模型服务，以及大模型调用第三方工具。基于MCP的系统与这些技术有什么不同呢？

与REST API的区别

REST API像拍照片，MCP更像拍电影，这种差异决定了它们适用的场景不同。照片模式(REST API)适合定格瞬间的简单需求，比如查询实时天气（定格此刻的蓝天）、获取股票最新报价（记录某个时间点的数值）、调取身份证信息（获取静态档案）。电影模式(MCP)擅长记录连续的操作过程，例如规划旅行路线（从订票到酒店入住全程跟进）、处理客户投诉（记录沟通历史并动态调整方案）、编写程序代码（根据调试反馈持续优化）。

以订外卖场景来对比更为直观，REST API只能单次查询餐厅是否营业，MCP则能完成“推荐餐厅→选餐→支付→跟踪配送”全流程。MCP背后的智能协作机制就像厨房团队：智能助手（大模型）相当于主厨，负责制订计划；工具执行器相当于帮厨，专门处理具体操作；协作环境相当于厨房工作台，所有的工具触手可及。

这种设计让智能服务突破了以下3重限制：

• 时空连续性：像连续剧一样记住上集剧情。

• 动态调整：根据反馈及时修正方案。

• 环境适配：无论是云端服务还是本地软件，都能调用。

基于MCP的调用与REST API调用在记忆能力、交互类型、复杂性和应用场景等方面有很大不同，具体对比见表2。

与大模型调用第三方工具的区别

大模型调用第三方工具相当于各家餐厅自备菜单，且每家餐厅都有自己的点餐暗号。有的要求用文字写需求，有的要求画示意图下单，还有的要求对特定暗号才能下单，导致顾客每次换餐厅都要重新学习规则，效率低下且容易出错。

基于MCP的调用则是统一的智能点餐系统，相当于给所有餐厅配备标准化点餐机，顾客用统一语言描述需求（如“要一份微辣的牛肉面”），系统自动转换为各餐厅能理解的格式，后厨（工具执行程序）独立运作，可设在本地或云端。

基于MCP的这种设计使AI系统能够像模块化厨房设备那样灵活部署，例如，数据分析工具可以安装在本地计算机上，支付接口部署在云端服务器上，图像识别模块运行在专用设备上。各模块通过标准接口连接，像拼乐高一样自由组合。同时，MCP建立“数字工具普通话”，实现了需求输入标准化（无论文字、语音还是图片）、执行反馈的规范化（成功或失败均有明确编码），以及错误处理统一化（如网络中断自动重试3次）。

更重要的是，基于MCP的系统如同智能手机连接蓝牙设备那样即插即用，接入即自动识别，不需要额外适配。基于MCP的调用与大模型调用第三方工具的对比见表3。

基于MCP的这种“解耦式”架构让AI服务既保持专业深度，又像智能手机生态般开放灵活，真正实现了“一套系统，万物互联”的智能体验。

与传统AI服务的区别

基于MCP的系统与传统AI服务有什么不同呢？这主要体现在以下5个方面：

(1)万能插头与专属转接头

传统AI服务对接新工具就像出国旅行要带一堆转换插头——每个数据库、日历软件都需要单独开发对接程序。基于MCP的系统则像全球通用的Type-C接口，一套标准适配所有设备。例如，在开发智能客服时，无须为微信、邮件、电话分别写代码。

(2)实时导航与纸质地图

传统AI服务如同用纸质地图找路，旅行建议基于过时的攻略。基于MCP的系统则像实时更新的导航系统，例如，查询机票可直接对接售票平台，会议安排会同步最新日程表。

(3)智能管家与传声筒

传统AI服务只能被动应答，例如提问“明天天气如何？”，则只播报预存信息。基于MCP的系统则像全能管家，例如提问“订明早去上海的航班”，则会自动比价并下单，全程支持“说一半补一半”的连续对话。

(4)银行金库与抽屉锁

传统AI服务安全隐患较多，例如API密钥硬编码在程序中，权限管理粗放。基于MCP的系统则内置了安全设计，敏感凭证存放在独立保险箱（服务器）中，每次转账级操作须人脸确认（用户授权），且危险操作自动隔离（沙盒防护）。

(5)乐高积木与定制雕塑

传统AI服务的开发如同雕刻石像，每对接一个新系统就要从头设计，维护成本随功能增加暴涨。MCP生态则像积木搭建，已有邮件、文档、支付等标准模块，新增的智能合约模块只需进行拼装即可，而且社区还持续提供新功能组件。

通过MCP，AI从“书呆子”变成了“实干家”，既保持专业能力，又像智能手机般开放易用。如同给AI世界制定了“数字普通话”，让各类智能设备真正实现无障碍协作。

与大模型服务的区别

我们可以将大模型服务和基于MCP的系统想象成公司的主管与执行团队。主管（大模型服务）擅长理解客户需求、制订计划，就像能快速听懂各地方言的翻译官；执行团队（基于MCP的系统）则掌握打开各个专业工具库的钥匙，负责具体实施。

这种配合模式解决了AI的三大痛点：当遇到需要精准计算的问题（比如财务核算）时，系统会自动切换到专业软件，避免人工计算容易出错的问题；当遇到时效性问题（比如查股票行情）时，系统会实时联网抓取最新数据，就像给老式钟表装上自动对时功能一样；当遇到专业领域问题（比如医疗咨询）时，系统会转接给行业专用程序，相当于给普通员工配了专家顾问团。

特别是在涉及资金交易、信息修改等重要操作时，系统会像银行金库管理一样，通过多重验证后才启动专用程序。这既保留了AI理解自然语言的优势，又规避了它可能存在的随意性和信息滞后问题，最终形成1+1>2的智能协作体系。

示例解读：基于MCP的天气查询

MCP服务器作为AI模型和外部服务之间的接口，定义AI在需要时可以使用的工具。AI处理理解和生成自然语言，而MCP服务器处理特定的域功能。这里以天气查询为例，介绍一个简单的MCP服务。

我们可以把MCP服务器比作AI的“接线员”。当AI需要查询天气时，它不用自己动手操作，而是通过这个接线员调用专业服务，从而把问题转给MCP服务器。这个服务器就会立即调取实时天气数据，再用通俗的语言整理成回答。

想自己搭建这样的服务其实很简单，本节会用TypeScript来演示（熟悉JavaScript的读者也能轻松看懂）。开始前请先安装好Node.js。

为项目创建一个新目录，并初始化package.json文件：

然后，安装必要的依赖项：

现在，在项目目录中创建一个名为main.ts的文件，让我们一步步地分解MCP服务器的实现。

首先，需要导入必要的模块：

McpServer类是我们实现的核心，允许我们定义和公开工具。StdioServerTransport支持通过标准输入/输出进行通信，这是MCP主机/客户端与我们的服务器交互的方式。Zod是一个TypeScript-first模式验证库，我们将使用它来定义工具的参数。

然后，使用名称和版本来初始化MCP服务器：

以上代码将创建一个新的服务器实例，其中含有标识我们的服务的元数据。

接着，向服务器中添加一个工具。我们将创建一个简单的getWeather工具，它返回指定城市的天气信息：

以上代码定义了一个名为getWeather的工具，我们指定这个工具接收一个带有单个参数city的对象，city是一个字符串。同时，它实现了一个在调用工具时执行的处理函数，处理程序返回一个内容对象数组，在本例中仅返回一条文本消息。在真实的场景中，处理程序可能会对天气服务进行API调用，并返回实际的天气数据。

最后，我们需要为服务器设置通信通道。因为希望通过标准输入/输出与MCP主机或客户端通信，所以这里选择使用StdioServerTransport：