MCP（Model Context Protocol，模型上下文协议）推出将近一年了。起初它只是在AI圈子里小范围传播，真正让它火起来的，还得归功于Cursor这类IDE工具的流行，以及Claude Sonnet在编程能力上的突飞猛进。但真正把MCP推到公众面前并封神的，是Manus那波席卷全网的传播——有人直接给出“Manus = Cursor + MCP”的公式。一时间，MCP被捧上了神坛。今天，我们不吹不黑，来给它祛祛魅。

核心内容：
1. MCP技术出现背景与技术发展
2. MCP与Function call、GPTs的关系解析
3. MCP的应用场景与技术挑战

MCP的问世，其实是在OpenAI的Function call和GPTs之后。很明显，它看到了Function call在开发和使用上的复杂门槛，也看到了GPTs封闭和不开放的局限性。

Function call可以说是MCP的灵感来源和功能基石——你可以直接把它理解为“工具（tools）”。大模型（LLM）能理解工具的描述和参数规定，然后从一堆工具中挑选出一个或几个来解决用户提出的问题。换句话说，没有LLM自动选择和调用工具的能力，就不会有MCP这个概念。这个源头和基础，不得不承认，是OpenAI的巨大原始贡献。

但问题是，Function call（或者说Tools的使用）对很多开发者而言——更不用说普通用户了——虽然能用大模型来辅助编程，但依然很不方便。网络访问、权限控制、流程控制、错误处理、可靠性、版本维护、升级改动……这一大堆事情都需要手动编程处理。而且面对不同的应用场景，往往还需要定制化方案。说白了，门槛太高。

既然Function call这么复杂不好用，OpenAI又提出了GPTs的概念。说穿了，GPTs就类似于微信的小程序，底层实现依然是基于Function call，只不过把一个个封装好的GPTs摆在用户面前，让用户直接选用。但问题在于，GPTs是已经包装好的闭源应用，只能在OpenAI平台上使用，不开放，不是真正的生态玩法——充其量只是“OpenAI生态”。你花功夫给OpenAI做了一个GPT，换到别的平台就得重做一个。对服务商和开发者来说，依然不方便，不利于市场拓展。

这就尴尬了：Function call太底层，太复杂；GPTs又太高层，太封闭。中间缺一个标准化的“中间层”。于是，MCP应运而生——一个恰好处于中间层的协议或产品。

大家习惯用下面这张图来说明MCP的架构。

而下面这张图，个人认为更加清晰。

图中的Ja va Gen AI Application就是一个应用——用更流行的词说，叫Agent（智能体）。它可以调用（触发）不同的Ja va MCP Client来完成一个用户需求。而Client会通过MCP协议调用与之配套的MCP Server来实际完成任务。所有细节处理，都由MCP SDK包装完成，开发者不需要关心底层实现。

再底层的实现，可以参考下面这张图。懂不懂并不重要，大概了解一层一层的封装关系就行。

MCP处理一个用户需求（query或request）的完整流程是这样的：

第一步，MCP Client从MCP Server那里获取所有工具（tools或function calls）的列表和描述，包括参数描述。

第二步，MCP Client将用户的需求，连同工具及描述列表，一起送给大模型（LLM）。

第三步，大模型确定应该使用哪个工具。

第四步，MCP Client通过调用MCP Server来执行大模型选择的工具，拿到工具执行后的结果。

第五步，MCP Client将结果送回给大模型，由大模型生成自然语言描述，最终呈现给用户。

在MCP Server中，通过类似Ja va文档规范的方式来定义和说明工具。这样，MCP SDK就可以通过这种方式自动输出工具及描述列表，大大减少了手动配置的麻烦。

MCP最大的好处在于：用这种方式开发的产品或应用，可以通过MCP Client的形式嵌入到其他AI应用中。它们就像开发中的组件、库或微服务，谁都可以尽情调用。而且这些MCP应用的更新和升级，对上层AI应用来说是无感的，这无疑有利于Agent生态的健康发展。

但MCP也并非完美。它仍然需要相当程度的开发工作量，对普通用户来说，实际门槛依然不低。这或许说明，MCP还只是一个AI native时代的过渡产品。未来，我们完全可以期待更多更激动人心的创新出现。