5分钟让你的服务接入AI——用 API Auto MCP Server 实现大模型与后端系统的无缝对话

5 分钟让你的服务接入 AI------用 API Auto MCP Server 实现大模型与后端系统的无缝对话

话不多说，先看看效果：

这里我向AI提出问题，AI就根据问题自动调取对应的接口获取信息，然后将这些获取到的信息进行汇总呈现给我。

而要实现这一切，只需要将你的后端服务配置上API Auto MCP Server即可，接下来我将手把手教你如何将这一工具用于自己的后端系统。

快速开始

我准备了一个示例项目------API Auto MCP Server Demo，使用该项目可以快速体验和熟悉这一MCP Server的使用。

环境准备

Bun >= 1.2 （推荐）或 Node.js >= 22
Cursor >= 0.46.8 或 VScode >= 1.99.3（需要启用Github Copilot插件）

安装依赖

在项目根目录下，执行以下命令安装依赖：

bash 复制代码

bun install # 推荐
# 或
npm install

启动服务

使用VScode或Cursor等IDE打开该项目后，按F5运行（推荐）。

或在根目录下执行以下命令启动服务：

bash 复制代码

bun dev # 推荐
# 或
npm run dev

访问服务

服务启动成功后，访问http://localhost:3000/api-docs，可以看到接口文档页面

启动MCP服务器

Cursor

如果是使用Cursor打开该项目，根据下图示意，打开Cursor Settings-MCP，找到名为api-auto的MCP服务器，将其设置为开启状态，如果开启成功了，则会出现各种可用的Tools。

VScode

如果是使用VScode打开该项目，打开Github Copilot的聊天窗口，点击刷新按钮，出现提示Trust MCP Server from api-auto-mcp-server-demo/.cursor/mcp.json?，点击Trust。然后就可以看到刷新按钮变为扳手按钮，并出现数字。

开始愉快的对话吧！

接下来，你就可以像演示的那样，向AI提出问题，AI就根据问题自动调取对应的接口获取信息，然后将这些获取到的信息进行汇总呈现给你。

如何接入你的服务

首先，你的后端服务需要提供一个get接口，并返回该服务的OpenAPI规范的json文件。

然后将以上的demo项目中的.cursor/mcp.json文件中的http://localhost:3000/openapi替换为你服务的OpenAPI规范的json文件的地址。

如果需要配置cookie等信息，可以在.cursor/mcp.json文件中的auth=your-cookie-here修改为你需要的配置：

json 复制代码

{
  "mcpServers": {
    "api-auto": {
      "command": "npx",
      "args": [
        "-y",
        "api-auto-mcp-server",
        "--openapi-url",
        "http://your-openapi-json-url",
        "--cookie",
        "auth=your-cookie-here"
      ]
    }
  }
}

然后等待MCP服务器重启完成后，你就会发现根据你的服务的接口，MCP Server自动注册了相应的工具。

接下来，你就可以提问你的后端服务相关的问题了。

基本原理

从上面的示例效果中其实就能看到，这里的AI是通过MCP提供的的工具（tool）来调用接口，并获取相应的信息。

以下是这整个流程的简单示意图

其中，步骤1-2都是在宿主环境（比如VScode或Cursor）启动后自动完成的，而从步骤3开始，用户提问后，开始正式调用MCP提供的工具。

这里也可以看到，和常规的AI聊天不同，多了步骤6到11。

AI不会一开始就给出回答，而是先判断是否需要调用MCP，要调用的情况下，会先调用完MCP，再生成最终回答。

在一次对话中，步骤6到12只会执行一次，但是现在大部分搭配了MCP功能的AI工具都是以Agent的形式存在的，所以会根据AI的判断，重复执行多次这一步骤。

可以看到，这整个流程中有两个关键步骤：

使用MCP作为AI和后端服务之间联通的桥梁；
根据具体的后端服务来自动创建对应的MCP服务器；

接下来我会对这两个核心步骤进行具体讲解

MCP实现AI与外界沟通

虽然现在MCP已经被说讨论烂了，但这里还是简单地讲解MCP。

MCP全称Model Context Protocol，即模型上下文协议，它是一种帮助AI和其他系统进行交互的规范，它即不是具体的技术或者代码实践，但它由于完善生态配套，已经是现在整个AI行业中，实现AI和外部交互的底层标准。

而API Auto MCP Server就是基于MCP制作的MCP服务器。在前文中的配置MCP的部分，其实就是配置该服务器的启动命令。

说到这里，其实就有一个非常有趣的问题------AI是如何知道有哪些MCP工具可以调用，以及怎么去调用的？

为了分析这个问题，我使用Fiddler对Github Copilot进行了抓包，并将相关内容保存在了代码仓库中。

本次需要调用MCP的对话中，大致流程如下：

一次查询汇总用户信息的对话总共包括三次请求和响应：

第一次请求包括用户提问和MCP相关信息；
第一次响应包括要调用的**第1个MCP工具（获取用户基本信息）**内容；
第二次请求包括用户提问和MCP相关信息，以及第1个MCP工具的调用结果；
第二次响应包括要调用的**第2、3个MCP工具（获取用户订单信息和退款记录信息）**的相关内容；
第三次请求包括用户提问和MCP相关信息，以及第1、2、3个MCP工具的调用结果；
第三次响应数据，AI汇总整理的内容；

打开请求时发送的内容可以发现，所有MCP的工具都被放置在tools数组中，所有之前的工具调用结果都会放在message中：

jsonc 复制代码

// 第二次请求时发送的内容
{
  "messages": [
    // ... 发送的信息
    // 经过修饰后的用户提问
    {
      "role": "user",
      "content": "<context>\nThe current date is April 28, 2025.\nMy current OS is: Windows\nI am working in a workspace with the following folders:\n- d:\\New folder \nI am working in a workspace that has the following structure:\n```\n\n```\nThis view of the workspace structure may be truncated. You can use tools to collect more context if needed.\n</context>\n\n<reminder>\nWhen using the insert_edit_into_file tool, avoid repeating existing code, instead use a line comment with `...existing code...` to represent regions of unchanged code.\n</reminder>\n<prompt>\n查询id为1的用户的相关信息，包括订单记录、退款记录等，并总结该用户特点\n</prompt>"
    },
    // 之前调用的MCP工具的信息
    {
      "role": "assistant",
      "content": "",
      "tool_calls": [
        {
          "function": {
            "name": "331_GET-users-byId",
            "arguments": "{\"id\":1}"
          },
          "id": "call_J0Qpk5HjZMVkvtaf8XO65tGI",
          "type": "function"
        }
      ]
    },
    // 之前调用的MCP的结果
    {
      "role": "tool",
      "content": "{\n  \"id\": 1,\n  \"name\": \"John Doe\",\n  \"email\": \"[email protected]\",\n  \"age\": 30,\n  \"role\": \"admin\"\n}",
      "tool_call_id": "call_J0Qpk5HjZMVkvtaf8XO65tGI"
    },
    // 对于上述信息的描述
    {
      "role": "user",
      "content": "Above is the result of calling one or more tools. The user cannot see the results, so you should explain them to the user if referencing them in your answer. Continue from where you left off if needed without repeating yourself."
    }
  ],
  "tools":[
    // ...其他的工具
    // 一个用来创建用户的MCP工具的描述信息
    {
      "function": {
        "name": "331_POST-users",
        "description": "Create a new user",
        "parameters": {
          "type": "object",
          "properties": {
            "requestBody-id": {
              "type": "number"
            },
            "requestBody-name": {
              "type": "string"
            },
            "requestBody-email": {
              "type": "string"
            },
            "requestBody-age": {
              "type": "number"
            },
            "requestBody-role": {
              "type": "string"
            }
          },
          "additionalProperties": false,
          "$schema": "http://json-schema.org/draft-07/schema#"
        }
      },
      "type": "function"
    },
  ]
}

了解到这一原理，我们就可以使用普通的对话AI来模拟这一流程：

首先打开DeepSeek（其他的对话AI效果不是很好），注意不要打开R1和联网搜索选项；
复制第一次请求的内容，发送给DeepSeek；
DeepSeek会返回一个包含MCP工具的列表的json数据，大概率会调用331_GET-orders-user--userId-这个方法，并传递userId为1这个参数；
复制第二次请求的内容，发送给DeepSeek；
这时DeepSeek会返回一个包含接下来要调用的MCP工具的json数据，由于DeepSeek没有做针对这种情况的特化处理，可能还是只会请求一个工具；
但是，这里我们假设DeepSeek一次性调用了两个MCP工具，直接复制包含这两个MCP工具调用结果的第三次请求的内容，发送给DeepSeek；
这时，DeepSeek就不会再请求MCP工具了，而是直接返回一个基于上述信息的汇总数据。

到里相信大家也能理解了，MCP并没有提供什么很高深的方案，本质上还是让各个聊天程序把MCP的工具转换为提示词发给AI，然后让AI规范返回要使用的工具的相关信息，然后再解析这些信息，调用相关的MCP工具，并且将这些工具的返回值再作为提示词提供给AI。

根据后端服务创建MCP服务器

MCP和AI的交互原理搞清楚了，接下来就是MCP是如何根据后端服务自动生成可用工具，并且调用的。

实现这一方法的最直接的方法毫无疑问是直接编写各个接口的参数解析和调用逻辑，因为AI传递的参数都是规范化的，那么自然可以使用程序轻松地进行解析，然后就常规地调用接口，获得返回值后再转发出去即可。

但问题在于一个后端服务其接口常常有几百上千个，而且会随着后续开发逐步增加，那么全部都手写一遍相关的逻辑明显是不现实的。

就如同使用了MCP这一协议可以帮助我们快速帮助AI和外部工具对接一样，将MCP和后端接口对接起来也需要使用一个通用的规范------OpenAPI。

OpenAPI也是一个开发的标准，但它规定的是一个接口描述自身信息的一系列规范，各种后端框架、接口管理工具都可以非常方便地生成符合OpenAPI的接口描述信息。

上文中提供的demo的接口文档就是使用OpenAPI标准的接口信息进行自动生成的：

和生成接口文档类似，也可以编写程序自动生成MCP的各种工具：

typescript 复制代码

/**
 * 使用符合OpenAPI标准的接口信息自动注册MCP工具 的大致实现
 */
export const registerTools = async (
  server: McpServer,
  openApiDoc: OpenAPIV3.Document,
) => {
  // 遍历接口信息
  for (const [path, pathItem] of Object.entries(openApiDoc.paths)) {
    for (const [method, operation] of Object.entries(pathItem)) {

      // 解析获得请求地址
      const cleanPath = path.replace(/^\//, '');

      // 根据请求方法、请求地址生成工具ID
      const toolId = `${method.toUpperCase()}-${cleanPath}`.replace(
        /[^a-zA-Z0-9-]/g,
        '-',
      );

      // 解析生成工具的描述信息
      const description =
        operation.summary ||
        operation.description ||
        `${method.toUpperCase()} ${path}`;

      // 解析获得param信息
      const validParameters =
        operation?.parameters?.filter(
          (param) => 'name' in param && 'in' in param,
        ) || [];

      // 解析获得param的schema
      const validParametersSchema = (()=>{
        // ...
      })()

      // 解析获得requestBody中的参数
      const requestBody = (() => {
        if (!operation.requestBody) {
          return undefined;
        }
        // ...

        return schema;
      })();

      // 解析获得requestBody中参数的schema
      const requestBodyInputSchema = (() => {
        if (!requestBody) {
          return undefined;
        }
        // ...
      })();

      // 汇总为总的schema
      const inputSchema: Record<string, z.ZodType> = {
        ...validParametersSchema,
        ...requestBodyInputSchema,
      };


      // 使用生成的schema注册该接口对应的工具
      server.tool(toolId, description, inputSchema, async (params) => {
        // ...
      });
    }
  }
};

写在最后------关于MCP和AI的未来

经过这两年各种AI模型和工具的快速发展，可以说AI全面接入数字世界只差临门一脚了，而MCP就是迈向这最后一步的钥匙。

从MCP提出到现在的几个月时间，无论是各种社区项目的诞生，还是各大厂商的积极跟进，都证明了只要各种"共识"能够确立，整个AI生态的活力也会被逐步释放。

图中的各种围绕AI的生产流程也会很快实现。

5分钟让你的服务接入AI——用 API Auto MCP Server 实现大模型与后端系统的无缝对话