至于先搞懂，MCP 到底在中间干了啥

实际来说。最开始我对 MCP 的概念特别模糊，以为又是啥新的微服务框架。老实说，翻了半天才搞明白，它全称是 Model Context Protocol。说白了就是一套「统一传话标准」。

工具，都按同一套协议跟大模型客户端说话。客户端不用管你工具内部怎么实现，只要符合 MCP 协议，就能直接用。

我当时整理了一条完整的调用链路，画出来大概是这样：

换成大白话就是：你跟 AI 说 “帮我看看本地的 server.js 写了啥”。大模型一琢磨，这事得调用读文件工具，就让客户端给 MCP 服务发个指令。服务收到指令去读文件，读完把内容传回来大模型再拿着内容给你解释。整个比如过程里MCP 服务就像个专职跑腿的。只负责按规矩收消息，还有干活，再有回消息。

动手写这方面，不到 30 行的主要代码

原理搞懂了写起来其实很快。主要就两个东西：一个是官方的 SDK 帮我们处理协议通信，另一个是 zod 用来做参数校验。

先装依赖

新建个文件夹，初始化 npm。装两个包就行：

npm install @modelcontextprotocol/sdk zod

一个是官方的 MCP SDK，帮我们搞定所有协议层的脏活累活；另一个 zod 是用来定义工具参数的校验规则，保证传进来的参数格式是对的。

服务主体代码

新建 server.js一步步来写。

1️⃣ 引入依赖并创建服务实例：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";说起来，import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";import { z } from "zod";import fs from "fs/promises";// 初始化服务
const server = new McpServer({
至于name。"simple-read-mcp",version: "1.0.0",});

2️⃣ 注册主要工具 read_file

server.tool(
"read_file"。"读取指定方法的本地文件内容",{
// 用 zod 定义参数
至于path，z.string.describe
},async => {
try {
const content = await fs.readFile;// 必须返回符合 MCP 协议的结构
return {
content:
};} catch {
return {
isError: true,content:
};}
}
)，说起来，

3️⃣ 开启服务：

async function main {
const transport = new StdioServerTransport;await server.connect;}
main，

从坑点一来看。返回格式不能乱写

第一次写的时候，我根本没在意返回格式。我以为直接 return content 就行了却发现大模型调用成功却拿不到内容，一直报解析错误。

MCP 对返回结果有严格要求：必须是一个带 content 数组的对象，每项要声明 type 和对应的数据； 错误返回也要加上 { isError: true,... }。

错误示例：

// ❌ 错误写法：直接返回字符串
return content;

至于客户端配置。怎么让 Trae 认出这个服务

MCP 服务本身是通过标准输入输出与客户端通信，需要在支持 MCP 的客户端里注册。

在 Trae 的配置文件中加入：

{
"mcpServers": {
"simple-read-mcp": {
"command": "node"。"args":
}
}
}

这段配置告诉客户端：“叫 simple-read-mcp 的服务，用 node 执行指定 JS 文件，它会通过 stdio 与我交互”。保存后重启 Trae，就能在 MCP 列表里看到我们的服务。

至于第二个坑，方法问题比想象中麻烦

I 在测试时用了相对方法。原因是 MCP 服务运行时的工作目录不是脚本所在目录，而是客户端启动目录。不过，

• 强制使用绝对方法；老实说，或
.

"提醒如果你的 MCP 服务要处理方法。尽量统一用绝对方法，相对方法基准容易出错"

说到再挖一层。stdio 通信到底是怎么跑的

MCP 默认采用 stdio 通信，而不是 HTTP。其实它只是在进程 stdin 上监听 JSON‑RPC 风格的信息，并把响应写回 stdout。这种方式有几个显著优点：

•  Windows、macOS、Linux 都自带标准输入输出，无需额外网络配置。
•  只能本地调用，不会暴露端口。
•  开发者只专注业务逻辑，无需关心网络协议实现。

还有几个踩过的小坑

•  多余或缺失逗号、括号都会导致服务加载失败，却没有明确报错提示。
•  .describe 并非装饰，而是大模型依据来生成正确请求。如果描述模糊，大模型可能传错参数类型。
•  因为 stdio 同时承担协议消息。如果把普通日志混进 stdout，会破坏协议解析。调试请使用 stderr 或写入日志文件。

最终说两句

MCP 并不是高深的新技术。它只是一套统一调用协议，让大模型和各种本地工具能够「按同一种规矩」交流。

•  注册工具 + stdio 连通，即可拥有一个可被 AI 调用的本地服务；无需搭建 HTTP Server，也不必学习复杂框架。
•  返回结构、工作目录、stdout 日志，这三者最容易导致「跑不通」而找不到原因；官方文档散碎，新手往往卡在这里。
•  生产环境务必加上安全措施，防止大模型随意读取敏感文件；处理与日志也需要完善，

If you also hit se hurdles while tinkering with MCP,drop a comment – my hard‑earned pitfalls might save you some time.