​聊一下MCP，希望能让各位清醒一点吧。

先说观点：MCP不错，但它仅仅是个协议而已，很多科普文章中，提到的更多都是愿景，而不是落地的场景。

本文不再重新陈述MCP的基本概念，而是旨在能让大家了解的是MCP 有什么用？、怎么用？、要不要用？

我准备了一份MCP实现的核心代码，只保留必要的内容，五分钟就能看明白MCP怎么回事。

先上代码，让我们看看实现MCP最核心的部分我们都干了些什么东西。顺便让大家看看MCP到底和Function call是个什么关系。

MCP代码核心逻辑

我们在本地运行的MCP，所以使用的是Stdio模式的客户端和服务端。也就是：StdioServerTransport和StdioClientTransport

先看打满日志的demo运行起来起来后，我们获得的信息：

我们的服务端写了两个简单的工具，加法和减法。

服务端启动成功之后，客户端成功的从服务端获取到了这两个工具。

我们发起了一个问题：计算1+1

接下来做的事情就是MCP的客户端核心三步逻辑：

1. 客户端调用AI的function call能力，由AI决定是否使用工具，使用哪个工具。

2. 客户端把确定要使用的工具和参数发送回服务端，由服务端实现API调用并返回结果。

3. 客户端根据结果，再次调用AI，由AI进行回答。

我们一边看代码一边说里面的问题：

第一步调用AI，决定使用工具

客户端代码：

  const response = await this.openai.chat.completions.create({
    model: model,
    messages,
    tools: this.tools, // ! 重点看这里，this.tools是服务端返回的工具列表
  });

看到了么？这里用的还是Function call! 谣言一：MCP和Function call没关系，MCP就可以让大家调用工具，终结了。MCP就是用的function call的能力来实现的工具调用。当然我们也可以不用Function call，我们就直接用提示词判断，也是可以的。

这里要说的是：MCP就是个协议。并没有给大模型带来任何新的能力，也没有某些人说的MCP提升了Function call的能力，以后不用Function call了，用MCP就够了这种话，千万不要被误导。

MCP并没有让大模型的工具调用能力提升

在真实的生产环境中，目前Function call主要的问题有：

• 工具调用准确性不够。 真正的生成环境可能不是三个五个工具，而是三十个五十个。工具之间的界限不够清晰的话，就会存在模型判断不准确的情况。

• 参数提取准确性不够。 特别是当一个工具必填加选填的参数达到十个以上的时候，面对复杂问题，参数的提取准确率会下降。

• 多意图的识别。
  用户的一个问题涉及到多个工具时，目前没有能够稳定提取的模型。

第二步把工具和参数发回服务端，由服务端调用API

客户端代码：

const result = await this.mcp.callTool({
  name: toolName,
  arguments: toolArgs,
});

服务端的代码：

server.tool(
  "加法",
  "计算数字相加",
  {
    "a": z.number().describe("加法的第一个数字"),
    "b": z.number().describe("加法的第二个数字"),
  },
  async ({ a, b, c }) => {
    console.error(`服务端: 收到加法API，计算${a}和${b}两个数的和。模型API发送`) 
    // 这里模拟API的发送和使用
    let data = a + b
    return {
      content: [
        {
          type: "text",
          text: a + '+' + b + '的结果是：' + data,
        },
      ],
    };
  },
);

发现问题了么？ API是要有MCP服务器提供者调用的。要花钱的朋友！

每一台MCP服务器背后都是要成本的，收费产品进行MCP服务器的支持还说的过去，不收费的产品全靠爱发电。更不要说，谁敢在生成环境接一个不收费的私人的小服务器？

百度地图核心API全面兼容MCP了，百度地图是收费的，进行多场景的支持是很正常的行为。

来看看百炼吧，阿里的百炼目前推出了MCP的功能，支持在百炼上部署MCP server。

也是要花钱的朋友~，三方API调用费用另算。

阿里的魔塔社区提供了大量的MCP，可以看到有一些大厂的服务在，当然有收费的有免费的，各位可以尝试

第三步客户端根据结果，再次调用AI，由AI进行回答。

客户端代码：

messages.push({
  role: "user",
  content: result.content,
});
const aiResponse = await this.openai.chat.completions.create({
  model: model,
  messages: messages,
});

从服务端返回的结果，添加到messages中，配合提示词由大模型进行回复即可。

这一步属于正常的流程，没什么好说的。

那么问题是：我们使用MCP来实现，和我们自己实现这套流程有什么区别么？我们为什么要用MCP呢？

当初群里朋友第一次提到MCP的时候，我去看了一眼文档，给了这样的结论：

大厂为了抢生态做的事情，给落地的流程中定义了一些概念，多了脑力负担，流程和自己实现没区别。

对于工具的使用，自己实现和用MCP实现有什么区别么？

自己实现的流程和逻辑是这样的：

1. 我们的提示词工程师写好每个工具的提示词
2. 我们的后端工程师写好模型的调用，使用的是前面写好的提示词
3. 提供接口给前端，等待前端调用
4. 前端调用传入query，后端通过AI获取了工具
5. 通过工具配置调用API，拿到数据交给AI，流式返回用户。

MCP的逻辑是这样的：

1. 我们的提示词工程师写好每个工具的提示词
2. 我们后端工程师分别写好MCP服务端、MCP客户端
3. MCP客户端提供个接口给前端，等待前端调用
4. 前端调用传入query，MCP客户端调用AI，获取了工具。
5. 客户端把确定要使用的工具和参数发送会服务端，由服务端实现API调用并返回结果。
6. 客户端根据结果，再次调用AI，由AI进行回答，流式返回用户。

看吧，本质上是没有区别的。

什么？你说MCP服务端，如果日后需要与其他企业进行合作，可以方便的让对方的MCP客户端调用？ 我们的客户端也可以很方便的接入别人的MCP服务端。

不好意思，不用MCP也可以，因为Function call的参数格式已经确定了，这里原本存在差异性就极小。而且MCP也并没有解决这个差异性。还是需要客户端进行修改的。

MCP真正的意义

现在还是诸神混战时期，整个AI产品的上下游所有的点，都具有极高的不确定性。

MCP给出了一个技术标准化的协议，是大家共建AI的愿景中的一环，潜力是有的。

但是Anthropic真的只是在乎这个协议么？前面的内容我们也看到了，MCP和我们自己实现的流程几乎是一样的。但是为什么还要提出MCP呢？

为了生态控制权和行业话语权。

MCP它表面上是一个开放的协议，旨在解决AI模型与外部工具集成的碎片化问题，但其实他就是Anthropic对未来AI生态主导权的竞争。

未来MCP如果真的作为一个标准的协议成为大家的共识，围绕这个协议，甚至每家模型的工具调用格式都将被统一，此时Anthropic在委员会里的位置呢？不言而喻啊。

结语

最后把我的策略分享给大家吧：

打算在圈子里玩的部分，就和大家用一样的，不在圈子里玩的，其实自己团队实现也是OK的。

我这边更多的是自己团队实现的，而且在这个实现过程中大家对模型应用、AI产品的理解不断地在提升。

希望各位读者也多进行尝试，这样未来面对新出的各路牛鬼蛇神时大家才能有更多的判断力。

共勉吧！

转自https://juejin.cn/post/7492271537010671635