MCP 到底解决了谁的什么问题？
前言、关于本文
MCP 全称是 Model Context Protocol，是 Anthropic 在 2024 年 11 月底提出来的开源协议，旨在提供标准的大模型通信的协议，方便大模型调用第三方服务、访问第三方数据。
官方对 MCP 的类比是，MCP 就是大模型的“USB Type-C 接口”，不管是 OpenAI、Claude、Deepseek 什么大模型厂商，也不管是 GPT4o、deepseek-r1 还是 Qwen-2.5 什么模型，都能用 MCP 与外部服务和数据交互；就像不管是电脑、手机、耳机还是摄像头，都能使用 USB-C 接口来充电或者做数据传输。
很多讲 MCP 的文章介绍到这儿就开始拿着“查天气”的例子演示如何实现一个 MCP Server，但我认为还远远不够，AI 领域有很多“创新”都不怎么靠谱，MCP 到底解决了谁的什么问题？这些问题是真需求还是伪命题？之前是怎么解决的呢？MCP 能做成吗？我们又能从中获得什么启发？
带着这样的疑问，我持续关注 MCP 好几个月，断断续续的思考整理成文，如有理解不正确的地方，欢迎批评指教。
一、MCP 要解决什么问题？
在 Anthropic 的Introducing the Model Context Protocol文章中介绍到，
随着人工智能助手逐渐被主流所接受，业界已投入大量资金来提升模型能力，在推理和质量方面取得了快速进步。然而，即使是最复杂的模型也受到与数据隔离的限制——被困在信息孤岛和遗留系统后面。由于每个数据源的要求不同，无法用统一的方式处理，这就让构建一个能够高效连接所有数据源的系统变得非常困难，限制了系统的扩展性和整体效率。
AI 大模型的推理能力和回答质量越来越好了，但即使大模型的能力再强，如果不知道你的个性化数据，也没办法针对你的问题给出有效回答。比如，你问 deepseek 如何减肥，它很可能回答了一堆正确的废话，因为它没有你的数据，没有办法针对你因材施教。你的数据可能在 Keep、Apple Watch 这样的第三方系统里，那么，大模型如何获取第三方企业的数据？
让大模型的输出质量更高，一直都是大模型“进化”的核心驱动力。刚才个人减肥的例子也适用于企业用 AI 提效，大模型如何变成数字员工，提升企业的生产效率？同样需要大模型打通企业内部的服务，获取企业内部数据。
二、在 MCP 之前大模型如何集成第三方工具？
MCP 不是第一个要解决这个问题的方案，在此之前已经有 LangChain、Function Calling、ReAct 等众多实践，人们在这个领域已经摸索过一阵儿了
1、LangChain Tools
早在 2022 年底 ChatGPT 刚出来的时候，Langchain 就提出来要做大模型编排，它尝试将多种工具、API 和数据源连接到大语言模型中。这绝对是一个很好的点子，敏锐地认识到了大模型的优势与局限性。
Langchain 的开源社区一直非常活跃，但业内对 Langchain 吐槽的点主要是它的过度抽象，颇有一点简单问题复杂化的意思。比如，一个简单的调用大模型进行翻译的需求，使用 Langchain 框架比直接使用 OpenAI 更复杂，更抽象，各种封装让报错后的调试变得异常困难。
Langchain 本身的文档也写的超级复杂，其中的概念一屏都截不下，我试图学习过好几次，但最终还是放弃了。如果一个技术在让事情变得更复杂，那一定是在退步。
2、Function Calling
Function Calling（函数调用）是 OpenAI 最早提出的方案，旨在让“OpenAI 的模型”更方便灵活地与用户代码或外部服务进行交互，开发者可以在 OpenAI 的 API 里边使用 tools 和一系列约定的语法来使用 Function Calling，支持例如调用天气 API、执行数据库查询等。
这里说要说明的是，Function Calling 并不是大模型直接去调用第三方 API，而只是根据上下文推理出来最合适的工具，并正确组装参数，让开发者自行发起调用。具体流程如下图所示
整体的流程，可以分为以下几步
开发者需要预先定义并实现函数或工具，比如“查询天气”，开发者需要对这个函数进行描述（比如，查询天气函数提供根据城市查询天气的服务）和参数（比如，城市的英文全拼、具体的日期）。对这种定义主要是为了让大模型理解这个函数的用途和用法。
大模型根据用户的输入，以及预定义的函数描述信息，决策要使用哪个函数，比如用户问“今天杭州的天气”，大模型识别到这个可以调用“查询天气”函数，并拼装符合格式的参数，如
{"location": "hangzhou", "date": "2025-03-23"}开发者或封装了大模型的客户端发起对“查询天气”函数的调用
开发者将该服务返回的原始数据（如温度值）再次传递给大模型
大模型根据 API 结果生成最终回答，如“杭州今天气温 25℃，晴”
整个流程还是很通用和成熟的，Google Gemini 的Function Calling、Anthropic Claude 的Tool Use实现的流程也一样。但是，这三家在实现上又略有区别，比如 Gemini 的 function 定义中，用了function_declarations这个特殊关键词，Claude 在定义的时候，使用了input_schema作为参数描述，而在 GPT 和 Gemini 里叫parameters。诸如这种差异，无谓的增加了开发者使用 function calling 的成本。
另外，支持 Function Calling 的模型是使用特定数据集微调过的，不是大语言模型天然就有的能力，比如在 2023 年 6 月之前的 ChatGPT 模型都不支持 Function Calling，deepseek r1 在发布的时候也宣称不支持，这些因素也限制了 Function Calling 的使用范围。
3、ReAct，Reasoning and Acting
ReAct（Reasoning and Acting）是另一种工作范式，它借鉴了人类解决问题的方式，在解决问题时，先分解问题，逐步推理（Reasoning）需要做什么，再根据推理结果采取行动（Acting），再根据行动的结果继续推理，直到问题解决。
《ReAct: Synergizing Reasoning and Acting in Language Models》论文发现在问题回答、事实核查和交互式决策任务上的实验上，ReAct 让大模型拥有了更强大的问题解决能力。
说着比较抽象，在实际使用过程中，其实都是用 Prompt 让大模型来做事，只是 prompt 的结构不同。比如千问给出来了一个ReAct提示词模板，可以“激发千问使用工具的能力”
可以看出来，用 ReAct 模式虽然效果好，但提示词可能会是一篇茫茫长的作文指令，这对开发者来说门槛简直太高了，其难度不亚于跟不懂技术的人沟通。我们对于这种场景的做法通常是，算了算了
三、MCP 如何定义问题？
上一节我们介绍了在 MCP 之前，大模型集成第三方工具的方案，各有优缺点。但整体来说问题都是太复杂了。这里的复杂性在一定程度上还体现为混乱，这是因为这些产品并没有把开发者做进一步的区分。不论是 LangChain、Function Calling 还是 ReAct，都在假定开发者同时开发 Function 和在 AI Agent 内集成 Function，最终交付一个 ChatBot 给非技术人员用。
Anthropic 对 Agent 的认知不是 ChatBot，而是被 AI 赋能的工具们（AI-powered tools），比如 Claude 客户端、Cursor、Cline、Warp 等。从问题定义上就比其他的模型厂商的格局更高。进一步的，开发者被划分为提供数据的 Provider 和使用数据的 Consumer。MCP 明确了两类开发者的核心场景，Provider 使用 MCP Server 暴露他们的数据，Consumer 使用 MCP Client 连接到这些 MCP Server。
MCP 是一项开源的标准，旨在帮助开发者在数据源与 AI 驱动的工具之间建立安全的双向连接。其架构设计简洁明了：开发者既可通过 MCP Server 安全地开放数据接口，也可开发与这些服务器连接的 AI 应用程序（即 MCP Client）。这一协议通过标准化通信框架，既保障了数据交互的安全性，又实现了 AI 工具与数据源的动态集成。
如此以来，“让大模型更灵活方便地集成第三方工具”的问题被转化成了三个子问题
提供数据的 Provider 如何更方便地发布自己的工具/服务？
消费数据的 Consumer 如何更方便地找到这些服务，并且更方便地使用它们？
Provider、Consumer 和大模型之间，如何建立起彼此认可的协议？
四、MCP 如何解决问题？
MCP 在 2024 年 11 月底，到现在不过四个多月时间，大有成为业界事实标准的趋势。除了 Anthropic 的背书、开源协议之外，它还做对了哪些事？
1、MCP 的多语言支持
MCP 为 Python、TypeScript、Java、Kotlin 提供了 SDK，让这些程序员更容易实现 MCP Server 和 MCP Client。MCP 这种选择的背后一定是为了能覆盖最大开发者群体，比如
TypeScript：覆盖 Web/移动端开发，2024-10-23 发布 TypeScript SDK
Python：是数据科学和 AI 领域的事实标准，2024-11-20 发布 Python SDK
Kotlin：Android 官方推荐的开发语言，Jetbrains 在 2024-12-21 发布 Kotlin SDK
Java：构建企业级 Web 应用的首选语言之一，VMware 的 Spring AI 在 2025-02-14 发布 Java SDK
C#：是开发 Windows 桌面应用程序的首选语言之一，微软在 2025-03-24 发布
这么来看，MCP 还是太全面了。反观 Langchain 至今仅支持 Python 和 JavaScript，微软的 Semantic Kernel 仅支持 C#、Python 和 Java
2、MCP 的“朋友圈”
除了成为官方 SDK 的 Jetbrains, VMware, 微软之外，MCP 在其网站上列出了支持 MCP 协议的部分 Server 和 Client，比如 MCP Server 包括了 Docker、Github、PostgreSQL 等，MCP Client 包括了 Claude 的桌面客户端、网红编码 IDE Cursor、号称最好用的免费编码插件 Cline 等。
预置的这些 Server 和 Client，也可以最大程度地触达开发者，一方面让开发者可以基于预置的 Server 和 Client 玩起来，一方面类似于“羊群效应”，让新进入的开发者倾向于认为这个生态非常有前途。
这真是一个很聪明的做法，我还没看到有哪个大模型厂商这么花心思经营开发者生态的。把朋友搞得多多的，更有利于 MCP 形成广泛共识。
3、MCP 是怎么通信的？
很多文章不会涉及这部分，官方文档也写得云里雾里的，但集成了 AI 的工具怎么就实现了用自然语言调用 MCP Server 呢？我一直也很好奇，直到我看到了《抓取AI提示词，拆解MCP底层原理》这个视频，作者用 Cloudflare 的 AI 网关拦截了 Cline 和大模型的“聊天记录”解开了这个谜题。按照视频的方式我也复现了下，拿到调用日志以后我看笑了，这不就是 Function Calling 和 ReAct 的结合体吗？
拿用户问“当前时间”举例，来看我截获的 Cline 与大模型 Deepseek 的聊天记录：
首先，Cline 把 MCP 工具的信息放在系统提示词（System Prompt）里，同时把用户的实际提问放在一起，一并发给大模型。比如我安装了 time MCP，那么 get_current_time、convert_time 工具的作用、怎么用等描述信息就会出现在系统提示词里
然后，大模型根据用户的问题推断出是否需要使用工具，以及使用哪个。确定之后，提取并拼装具体的参数。安装 Time MCP 之后，我问“当前时间是什么”，大模型的思考和决策指令是，使用
get_current_time工具再然后，Cline 根据大模型的指示，发起对工具的调用，并将之前的聊天记录 Context 和这次的执行结果一并发给大模型
最后，大模型基于用户的原始问题和执行结果判断是否解决了问题，并返回最终结果给 Cline
由此可见，智能工具们（如 Cursor、Cline）不管是用 MCP，还是用 Function Calling，都需要问云端的大模型，并且它们聊天的模式是一模一样的。
同时，我也发现 MCP 的精华并不是 MCP Server 定义的工具，而是由智能工具发送给大模型的、预置的、巨长的系统提示词。Cline 的系统提示词写了 1000 多行，结构化地指导大模型如何调用工具做分步执行、显式的思考-行动-观察循环，全面应用了 ReAct 框架。比如这段提示词告诉大模型如何使用 MCP 工具
后记、得开发者者得天下
Cursor、Cline、Claude App 这些 AI 工具将复杂的系统提示词封装了起来，让开发者更简单，提供服务的开发者可以只关注如何将服务发布为 MCP Server，普通的开发者可以只关注我要安装哪个 MCP Client。
从这个角度看，是可以基于 MCP 构建 AI 时代的 AppStore 或安卓市场的，MCP Server 多了之后，问题就变成了用户怎么找到高质量的 MCP Server，以及 MCP Server 的开发者如何通过 MCP Server Store 获取商业利润。好消息是 MCP 社区已经在讨论这个问题了：MCP Server Registry，也让我们期待一下
MCP 持续火爆，2025/03/27 连 OpenAI 作为 Anthropic 的对手都开始支持 MCP，MCP 已经成为事实标准，Agent 领域越来越好玩了
---
欢迎关注我的公众号：RockBot
前言、关于本文
MCP 全称是 Model Context Protocol，是 Anthropic 在 2024 年 11 月底提出来的开源协议，旨在提供标准的大模型通信的协议，方便大模型调用第三方服务、访问第三方数据。
官方对 MCP 的类比是，MCP 就是大模型的“USB Type-C 接口”，不管是 OpenAI、Claude、Deepseek 什么大模型厂商，也不管是 GPT4o、deepseek-r1 还是 Qwen-2.5 什么模型，都能用 MCP 与外部服务和数据交互；就像不管是电脑、手机、耳机还是摄像头，都能使用 USB-C 接口来充电或者做数据传输。
很多讲 MCP 的文章介绍到这儿就开始拿着“查天气”的例子演示如何实现一个 MCP Server，但我认为还远远不够，AI 领域有很多“创新”都不怎么靠谱，MCP 到底解决了谁的什么问题？这些问题是真需求还是伪命题？之前是怎么解决的呢？MCP 能做成吗？我们又能从中获得什么启发？
带着这样的疑问，我持续关注 MCP 好几个月，断断续续的思考整理成文，如有理解不正确的地方，欢迎批评指教。
一、MCP 要解决什么问题？
在 Anthropic 的Introducing the Model Context Protocol文章中介绍到，
随着人工智能助手逐渐被主流所接受，业界已投入大量资金来提升模型能力，在推理和质量方面取得了快速进步。然而，即使是最复杂的模型也受到与数据隔离的限制——被困在信息孤岛和遗留系统后面。由于每个数据源的要求不同，无法用统一的方式处理，这就让构建一个能够高效连接所有数据源的系统变得非常困难，限制了系统的扩展性和整体效率。
AI 大模型的推理能力和回答质量越来越好了，但即使大模型的能力再强，如果不知道你的个性化数据，也没办法针对你的问题给出有效回答。比如，你问 deepseek 如何减肥，它很可能回答了一堆正确的废话，因为它没有你的数据，没有办法针对你因材施教。你的数据可能在 Keep、Apple Watch 这样的第三方系统里，那么，大模型如何获取第三方企业的数据？
让大模型的输出质量更高，一直都是大模型“进化”的核心驱动力。刚才个人减肥的例子也适用于企业用 AI 提效，大模型如何变成数字员工，提升企业的生产效率？同样需要大模型打通企业内部的服务，获取企业内部数据。
二、在 MCP 之前大模型如何集成第三方工具？
MCP 不是第一个要解决这个问题的方案，在此之前已经有 LangChain、Function Calling、ReAct 等众多实践，人们在这个领域已经摸索过一阵儿了
1、LangChain Tools
早在 2022 年底 ChatGPT 刚出来的时候，Langchain 就提出来要做大模型编排，它尝试将多种工具、API 和数据源连接到大语言模型中。这绝对是一个很好的点子，敏锐地认识到了大模型的优势与局限性。
Langchain 的开源社区一直非常活跃，但业内对 Langchain 吐槽的点主要是它的过度抽象，颇有一点简单问题复杂化的意思。比如，一个简单的调用大模型进行翻译的需求，使用 Langchain 框架比直接使用 OpenAI 更复杂，更抽象，各种封装让报错后的调试变得异常困难。
Langchain 本身的文档也写的超级复杂，其中的概念一屏都截不下，我试图学习过好几次，但最终还是放弃了。如果一个技术在让事情变得更复杂，那一定是在退步。
2、Function Calling
Function Calling（函数调用）是 OpenAI 最早提出的方案，旨在让“OpenAI 的模型”更方便灵活地与用户代码或外部服务进行交互，开发者可以在 OpenAI 的 API 里边使用 tools 和一系列约定的语法来使用 Function Calling，支持例如调用天气 API、执行数据库查询等。
这里说要说明的是，Function Calling 并不是大模型直接去调用第三方 API，而只是根据上下文推理出来最合适的工具，并正确组装参数，让开发者自行发起调用。具体流程如下图所示
整体的流程，可以分为以下几步
开发者需要预先定义并实现函数或工具，比如“查询天气”，开发者需要对这个函数进行描述（比如，查询天气函数提供根据城市查询天气的服务）和参数（比如，城市的英文全拼、具体的日期）。对这种定义主要是为了让大模型理解这个函数的用途和用法。
大模型根据用户的输入，以及预定义的函数描述信息，决策要使用哪个函数，比如用户问“今天杭州的天气”，大模型识别到这个可以调用“查询天气”函数，并拼装符合格式的参数，如
{"location": "hangzhou", "date": "2025-03-23"}开发者或封装了大模型的客户端发起对“查询天气”函数的调用
开发者将该服务返回的原始数据（如温度值）再次传递给大模型
大模型根据 API 结果生成最终回答，如“杭州今天气温 25℃，晴”
整个流程还是很通用和成熟的，Google Gemini 的Function Calling、Anthropic Claude 的Tool Use实现的流程也一样。但是，这三家在实现上又略有区别，比如 Gemini 的 function 定义中，用了function_declarations这个特殊关键词，Claude 在定义的时候，使用了input_schema作为参数描述，而在 GPT 和 Gemini 里叫parameters。诸如这种差异，无谓的增加了开发者使用 function calling 的成本。
另外，支持 Function Calling 的模型是使用特定数据集微调过的，不是大语言模型天然就有的能力，比如在 2023 年 6 月之前的 ChatGPT 模型都不支持 Function Calling，deepseek r1 在发布的时候也宣称不支持，这些因素也限制了 Function Calling 的使用范围。
3、ReAct，Reasoning and Acting
ReAct（Reasoning and Acting）是另一种工作范式，它借鉴了人类解决问题的方式，在解决问题时，先分解问题，逐步推理（Reasoning）需要做什么，再根据推理结果采取行动（Acting），再根据行动的结果继续推理，直到问题解决。
《ReAct: Synergizing Reasoning and Acting in Language Models》论文发现在问题回答、事实核查和交互式决策任务上的实验上，ReAct 让大模型拥有了更强大的问题解决能力。
说着比较抽象，在实际使用过程中，其实都是用 Prompt 让大模型来做事，只是 prompt 的结构不同。比如千问给出来了一个ReAct提示词模板，可以“激发千问使用工具的能力”
可以看出来，用 ReAct 模式虽然效果好，但提示词可能会是一篇茫茫长的作文指令，这对开发者来说门槛简直太高了，其难度不亚于跟不懂技术的人沟通。我们对于这种场景的做法通常是，算了算了
三、MCP 如何定义问题？
上一节我们介绍了在 MCP 之前，大模型集成第三方工具的方案，各有优缺点。但整体来说问题都是太复杂了。这里的复杂性在一定程度上还体现为混乱，这是因为这些产品并没有把开发者做进一步的区分。不论是 LangChain、Function Calling 还是 ReAct，都在假定开发者同时开发 Function 和在 AI Agent 内集成 Function，最终交付一个 ChatBot 给非技术人员用。
Anthropic 对 Agent 的认知不是 ChatBot，而是被 AI 赋能的工具们（AI-powered tools），比如 Claude 客户端、Cursor、Cline、Warp 等。从问题定义上就比其他的模型厂商的格局更高。进一步的，开发者被划分为提供数据的 Provider 和使用数据的 Consumer。MCP 明确了两类开发者的核心场景，Provider 使用 MCP Server 暴露他们的数据，Consumer 使用 MCP Client 连接到这些 MCP Server。
MCP 是一项开源的标准，旨在帮助开发者在数据源与 AI 驱动的工具之间建立安全的双向连接。其架构设计简洁明了：开发者既可通过 MCP Server 安全地开放数据接口，也可开发与这些服务器连接的 AI 应用程序（即 MCP Client）。这一协议通过标准化通信框架，既保障了数据交互的安全性，又实现了 AI 工具与数据源的动态集成。
如此以来，“让大模型更灵活方便地集成第三方工具”的问题被转化成了三个子问题
提供数据的 Provider 如何更方便地发布自己的工具/服务？
消费数据的 Consumer 如何更方便地找到这些服务，并且更方便地使用它们？
Provider、Consumer 和大模型之间，如何建立起彼此认可的协议？
四、MCP 如何解决问题？
MCP 在 2024 年 11 月底，到现在不过四个多月时间，大有成为业界事实标准的趋势。除了 Anthropic 的背书、开源协议之外，它还做对了哪些事？
1、MCP 的多语言支持
MCP 为 Python、TypeScript、Java、Kotlin 提供了 SDK，让这些程序员更容易实现 MCP Server 和 MCP Client。MCP 这种选择的背后一定是为了能覆盖最大开发者群体，比如
TypeScript：覆盖 Web/移动端开发，2024-10-23 发布 TypeScript SDK
Python：是数据科学和 AI 领域的事实标准，2024-11-20 发布 Python SDK
Kotlin：Android 官方推荐的开发语言，Jetbrains 在 2024-12-21 发布 Kotlin SDK
Java：构建企业级 Web 应用的首选语言之一，VMware 的 Spring AI 在 2025-02-14 发布 Java SDK
C#：是开发 Windows 桌面应用程序的首选语言之一，微软在 2025-03-24 发布
这么来看，MCP 还是太全面了。反观 Langchain 至今仅支持 Python 和 JavaScript，微软的 Semantic Kernel 仅支持 C#、Python 和 Java
2、MCP 的“朋友圈”
除了成为官方 SDK 的 Jetbrains, VMware, 微软之外，MCP 在其网站上列出了支持 MCP 协议的部分 Server 和 Client，比如 MCP Server 包括了 Docker、Github、PostgreSQL 等，MCP Client 包括了 Claude 的桌面客户端、网红编码 IDE Cursor、号称最好用的免费编码插件 Cline 等。
预置的这些 Server 和 Client，也可以最大程度地触达开发者，一方面让开发者可以基于预置的 Server 和 Client 玩起来，一方面类似于“羊群效应”，让新进入的开发者倾向于认为这个生态非常有前途。
这真是一个很聪明的做法，我还没看到有哪个大模型厂商这么花心思经营开发者生态的。把朋友搞得多多的，更有利于 MCP 形成广泛共识。
3、MCP 是怎么通信的？
很多文章不会涉及这部分，官方文档也写得云里雾里的，但集成了 AI 的工具怎么就实现了用自然语言调用 MCP Server 呢？我一直也很好奇，直到我看到了《抓取AI提示词，拆解MCP底层原理》这个视频，作者用 Cloudflare 的 AI 网关拦截了 Cline 和大模型的“聊天记录”解开了这个谜题。按照视频的方式我也复现了下，拿到调用日志以后我看笑了，这不就是 Function Calling 和 ReAct 的结合体吗？
拿用户问“当前时间”举例，来看我截获的 Cline 与大模型 Deepseek 的聊天记录：
首先，Cline 把 MCP 工具的信息放在系统提示词（System Prompt）里，同时把用户的实际提问放在一起，一并发给大模型。比如我安装了 time MCP，那么 get_current_time、convert_time 工具的作用、怎么用等描述信息就会出现在系统提示词里
然后，大模型根据用户的问题推断出是否需要使用工具，以及使用哪个。确定之后，提取并拼装具体的参数。安装 Time MCP 之后，我问“当前时间是什么”，大模型的思考和决策指令是，使用
get_current_time工具
再然后，Cline 根据大模型的指示，发起对工具的调用，并将之前的聊天记录 Context 和这次的执行结果一并发给大模型
最后，大模型基于用户的原始问题和执行结果判断是否解决了问题，并返回最终结果给 Cline
由此可见，智能工具们（如 Cursor、Cline）不管是用 MCP，还是用 Function Calling，都需要问云端的大模型，并且它们聊天的模式是一模一样的。
同时，我也发现 MCP 的精华并不是 MCP Server 定义的工具，而是由智能工具发送给大模型的、预置的、巨长的系统提示词。Cline 的系统提示词写了 1000 多行，结构化地指导大模型如何调用工具做分步执行、显式的思考-行动-观察循环，全面应用了 ReAct 框架。比如这段提示词告诉大模型如何使用 MCP 工具
后记、得开发者者得天下
Cursor、Cline、Claude App 这些 AI 工具将复杂的系统提示词封装了起来，让开发者更简单，提供服务的开发者可以只关注如何将服务发布为 MCP Server，普通的开发者可以只关注我要安装哪个 MCP Client。
从这个角度看，是可以基于 MCP 构建 AI 时代的 AppStore 或安卓市场的，MCP Server 多了之后，问题就变成了用户怎么找到高质量的 MCP Server，以及 MCP Server 的开发者如何通过 MCP Server Store 获取商业利润。好消息是 MCP 社区已经在讨论这个问题了：MCP Server Registry，也让我们期待一下
MCP 持续火爆，2025/03/27 连 OpenAI 作为 Anthropic 的对手都开始支持 MCP，MCP 已经成为事实标准，Agent 领域越来越好玩了
---
欢迎关注我的微信公众号，探索在 AI 时代的进化之路
版权声明: 本文为 InfoQ 作者【RockBot】的原创文章。
原文链接:【http://xie.infoq.cn/article/20da01d2dc2b9730ee9d81fea】。文章转载请联系作者。
还未添加个人签名 2017-11-02 加入
还未添加个人简介
评论