AI 编程实战:给你的工具创建一个 MCP 接口

最近我越来越觉得，AI 编程正在进入一个新阶段。

第一阶段，是让 AI 帮我们写代码。

比如写一个函数，修一个 bug，重构一个模块，生成一个页面。

但真正用久了以后，你会发现，问题开始变了。

你不只是希望 AI 会写代码。

你会开始希望它能使用你的工具、读取你的资料、调用你的系统、完成你的流程。

也就是说，AI 编程的下一步，不只是“让 AI 写代码”。

而是：

让 AI 能真正接入你的工作系统。

这时候，MCP 就变得重要了。

MCP，全称是 Model Context Protocol。

你可以先不用记这个英文名。

更直白地说：

MCP 是一种让 AI Agent 连接外部工具、数据和工作流的标准接口。

如果说 Markdown 正在变成 AI 编程时代的工作语言，那么 MCP 很可能就是 AI Agent 时代的工具接口。

Markdown 让你把任务、规则、上下文写清楚。

MCP 则让 AI 不只是读懂上下文，还能真正调用工具、读取数据、执行动作。

这篇文章不打算把 MCP 讲成一个很玄的协议。

我们直接从一个最小实战开始：

创建一个最简单的 MCP Server，让 AI 能调用我们自己定义的工具。

一、MCP 到底解决什么问题？

今天的大模型很聪明，但它有一个天然限制：

它默认不知道你本地有什么文件，不知道你公司的数据库里有什么，也不能直接调用你写的内部工具。

你当然可以把信息复制粘贴给它。

但这只适合临时对话，不适合真实工作。

真实工作里，AI 需要的是稳定接口。

比如：

• 读取一个项目的最新状态
• 查询数据库里的某条记录
• 调用公司内部 API
• 检查某个订单状态
• 生成一份报表
• 把某个任务写入系统

这些事情不能每次都靠人复制粘贴。

所以我们需要一种方式，把外部系统“暴露”给 AI。

MCP 做的就是这件事。

你可以把它理解成：

给你的工具加一个 AI 能理解、能发现、能调用的接口。

这句话很关键。

因为创建 MCP 的本质，不是“再写一个新 App”。

而是把已有的工具、数据、流程，包装成 AI Agent 可以使用的能力。

二、一个 MCP Server 能提供什么？

一个 MCP Server 可以向 AI 提供几类能力。

最常见的是三类：

1. Tools：工具

Tool 是最容易理解的一类。

它就是 AI 可以调用的函数。

比如：

• search_customer
• create_ticket
• get_weather
• query_database
• summarize_document

AI 看到这些工具后，可以根据用户任务选择是否调用。

2. Resources：资源

Resource 更像“可读取的数据”。

比如某个文件、某个数据库 schema、某个项目状态、某个 API 返回结果。

它不一定是动作，更偏上下文。

3. Prompts：提示模板

Prompt 是一组可复用的工作模板。

比如“帮我分析这份销售线索”“帮我写一份 PRD”“帮我 review 这段代码”。

不过如果你是第一次理解 MCP，可以先不用管这么多。

第一步，只要会做 Tool，就已经理解了 MCP 最核心的一层。

因为 Tool 最直观：

AI 调用一个函数，函数返回一个结果。

三、我们先做一个最小例子

我们创建一个 MCP Server，里面只有一个工具：

get_demo_weather

它接收一个城市名，然后返回一段模拟天气。

这听起来很简单，但它包含了 MCP Server 的完整骨架：

1. 创建 server
2. 注册工具
3. 定义输入参数
4. 编写工具执行逻辑
5. 用 stdio 启动
6. 配置到 Claude Desktop 或其他 MCP client 里

只要这个例子跑通，后面你把天气换成数据库、CRM、文件系统、内部 API，本质上就是同一件事。

下面用 Node.js 举例。

先创建项目：

mkdir demo-mcp-server
cd demo-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod

然后在 package.json 里加上：

{
  "type": "module"
}

接着创建 index.js。

核心代码如下：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "demo-mcp-server",
  version: "1.0.0",
});

server.registerTool(
  "get_demo_weather",
  {
    title: "Get demo weather",
    description: "Get demo weather for a location",
    inputSchema: {
      location: z.string().describe("City name, for example Toronto"),
    },
  },
  async ({ location }) => {
    return {
      content: [
        {
          type: "text",
          text: `The weather in ${location} is 22°C and sunny.`,
        },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

这就是一个最小 MCP Server。

它做的事情很简单：

• 告诉客户端：我这里有一个工具，叫 get_demo_weather
• 这个工具需要一个参数：location
• 当 AI 调用它时，server 返回一段文本结果

你可以先不用纠结协议细节。

真正重要的是这个结构：

工具名称 + 参数说明 + 执行逻辑 + 返回结果。

这就是很多 MCP 工具的基本形态。

四、一个很容易踩的坑

如果你用的是 stdio 方式，也就是通过标准输入输出和 MCP client 通信，有一个坑要特别注意：

不要随便用 console.log() 输出调试信息。

原因是 stdio MCP Server 会用 stdout 传输协议消息。

如果你把普通日志也写到 stdout，就可能污染 MCP 的通信内容，导致 client 解析失败。

如果要打印调试信息，可以用：

console.error("debug message");

因为 console.error() 写到 stderr，不会干扰 stdout 里的协议消息。

这个细节很小，但真实开发里非常容易让人卡住。

五、把它接到 Claude Desktop

创建好 MCP Server 以后，还需要告诉 MCP client 怎么启动它。

以 Claude Desktop 为例，可以在配置文件里加入类似配置：

{
  "mcpServers": {
    "demo-weather": {
      "command": "node",
      "args": [
        "/ABSOLUTE/PATH/TO/demo-mcp-server/index.js"
      ]
    }
  }
}

这里要注意，路径最好使用绝对路径。

保存配置后，重启 Claude Desktop。

如果一切正常，Claude 就能发现这个工具。

你可以问它：

> What is the weather in Toronto?

它就有机会调用你刚才定义的 get_demo_weather 工具。

当然，这只是 demo。

真实项目里，你可以把这段模拟天气替换成：

• 调用一个真实 API
• 查询一个数据库
• 读取一个本地文件
• 检查一个 GitHub issue
• 拉取 CRM 里的客户信息
• 调用内部自动化脚本

这时候，MCP 的价值才真正出现。

六、创建 MCP 的真正意义

如果只是看上面的代码，MCP 好像没什么神秘的。

不就是注册一个工具，然后返回结果吗？

但它真正重要的地方，不在代码复杂度，而在接口位置。

过去软件主要是给人用的。

所以我们设计按钮、页面、表单、菜单。

人打开网页，点击按钮，填写表单，提交结果。

但 AI Agent 不适合用这种方式工作。

它需要的是更结构化的能力描述：

• 有哪些工具可以用
• 每个工具做什么
• 参数是什么
• 返回什么
• 哪些动作需要用户确认
• 哪些数据可以读取

这就是 MCP 的价值。

它让软件开始拥有一层“Agent 可调用接口”。

换句话说：

未来很多软件，不只需要 UI，也需要 AI Interface。

UI 是给人用的。

API 是给程序用的。

MCP 这类协议，则是给 Agent 用的。

这也是为什么我觉得 MCP 值得认真关注。

它不是又一个技术名词。

它代表的是软件使用方式的变化。

七、什么东西适合做成 MCP？

并不是所有东西都适合一上来就做 MCP。

我会优先考虑这几类。

1. 高频查询

比如每天都要查的项目状态、客户信息、订单状态、日志摘要。

这类东西很适合先做成只读工具。

2. 低风险动作

比如生成报告、创建草稿、添加本地任务、格式化数据。

这类动作即使出错，代价也比较低。

3. 人需要反复复制粘贴的流程

如果你发现自己每天都在把同一种信息复制给 AI，那它可能就适合变成 MCP resource 或 tool。

4. 内部系统的窄接口

不要一上来就把整个公司系统开放给 AI。

更好的方式是先开放一个很窄的能力。

比如：

• 只查某类数据
• 只生成某类草稿
• 只读取某个目录
• 只允许创建待审核任务

MCP 的关键不是“给 AI 最大权限”。

恰恰相反。

好的 MCP 设计，是给 AI 刚好够用的工具。

八、我的判断

我现在对 MCP 的判断是：

它会成为 AI Agent 落地过程里非常关键的一层基础设施。

但普通人理解它，不应该从协议细节开始。

而应该从一个更简单的问题开始：

> 我有什么工具、数据或流程，是希望 AI 能稳定使用的？

如果有，那你就可以考虑给它创建一个 MCP 接口。

这件事的意义不只是“接入 Claude”或者“接入某个 AI 工具”。

更大的意义是：

你开始把自己的工作系统，整理成 AI Agent 可以理解和调用的形状。

这和我们之前说 Markdown 很像。

Markdown 是把人的意图、规则、上下文写清楚。

MCP 是把工具、数据、动作暴露给 AI。

一个偏“说清楚”。

一个偏“做得到”。

这两者合起来，才是 AI 编程真正进入实战的开始。

九、最后一句话

如果你想理解 MCP，不要先把它想成复杂协议。

先把它想成一句话：

给你的工具装上一个 AI 能用的接口。

今天你创建的可能只是一个天气 demo。

明天它可以是你的文件系统、知识库、CRM、自动化脚本、内部数据库。

再往后，它可能就是你的数字员工真正开始工作的入口。

因为 AI Agent 要想从“会聊天”走向“会干活”，中间必须经过这一层：

它要能安全、稳定、可控地使用工具。

而 MCP，正是在补这块拼图。

—

参考资料：

• Model Context Protocol 官方文档：What is MCP
• Model Context Protocol 官方文档：Build an MCP server
• Model Context Protocol 官方文档：Architecture overview