node mcp链接实战：用 TaoToken 统一 Key 写一个自己的 MCP 服务

1. 从零写一个 MCP 服务为什么卡在“链接”这一步MCPModel Context Protocol这两年被聊得很多但真正动手写一个自己的 MCP 服务时大部分人卡住的不是协议本身而是“链接”两个字。Node.js 环境下你要同时处理三件事SDK 的握手流程、工具Tool的注册与参数校验、以及客户端Cursor、Cherry Studio 等能不能正确拉起你的进程并识别出工具列表。任何一环没对齐表现就是“客户端里看不到工具”或者“调用了但没反应”。这篇就聚焦这条链路用 Node.js 从零搭一个自定义 MCP 服务注册两个工具一个求和、一个创建文件然后把它接到支持 MCP 的客户端里跑通。同时我会把模型调用这一层统一走 TaoToken 的 Key 和 API 通道这样你后面无论换哪个模型、哪个客户端都不用到处改配置。适合已经会一点 Node、想搞清楚 MCP 到底怎么“连上”的人也适合只想照着抄一份能跑骨架的人。核心检索词先摆出来node mcp 链接、自定义 MCP 服务、MCP 协议握手、工具注册、本地调试。下面按“先跑通再优化”的顺序来。2. TaoToken 前置统一 Key 与 API 通道怎么准备MCP 服务本身是本地进程它不直接决定你用哪个大模型。真正决定模型的是客户端那一侧。但如果你想让多个客户端、多个脚本共用一套模型入口就需要一个统一的 Key 和 API 通道。我这边用的是 TaoToken官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 这个不加 UTM。操作顺序很简单先注册登录进控制台在 API Keys 页面创建一个 Key。这个 Key 后面会填到客户端的模型配置里而不是填到 MCP 服务代码里——这点新手最容易搞混。MCP 服务只负责“提供工具”模型负责“决定调不调工具”两者通过客户端串起来。如果你只是本地调试 MCP 工具其实不接模型也能测用 curl 或者客户端自带的工具面板就能触发。但一旦你想让模型自动调用这些工具就必须在客户端里配好模型通道。TaoToken 在这里的作用是一个 Key 走通对话、编码、Agent 这几类场景省得每个客户端单独配一遍。注意Key 属于敏感信息不要写进会提交到 Git 的代码里。本地测试可以用环境变量或者放在客户端自己的配置文件中。3. 可复制配置package.json 与 app.js 骨架先建目录初始化项目。Node 版本建议 18 以上我用的是 20.x。因为 MCP SDK 是 ESM 的所以 package.json 里要声明type: module。{ name: my-mcp-server, version: 0.1.0, type: module, scripts: { start: node app.js }, dependencies: { modelcontextprotocol/sdk: ^1.15.1, zod: ^3.25.76 } }装依赖npm install然后是 app.js。这里的关键点是用McpServer创建服务实例用registerTool注册工具参数校验交给 zod最后用StdioServerTransport把服务挂到标准输入输出上——因为客户端是通过 stdio 拉起你的进程并通信的。import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; import fs from fs; const server new McpServer({ name: my mcp server, title: my mcp server, version: 0.1.0, }); server.registerTool( sum, { title: 两数求和, description: 得到两个数的和, inputSchema: { a: z.number().describe(第一个数), b: z.number().describe(第二个数), }, }, ({ a, b }) { return { content: [ { type: text, text: 两数求和结果${a b} }, ], }; } ); server.registerTool( createFile, { title: 创建文件, description: 在指定目录下创建一个文件, inputSchema: { filename: z.string().describe(文件名), content: z.string().describe(文件内容), }, }, ({ filename, content }) { try { fs.writeFileSync(filename, content); return { content: [{ type: text, text: 文件创建成功 }], }; } catch (err) { return { content: [{ type: text, text: err.message || 文件创建失败 }], }; } } ); const transport new StdioServerTransport(); await server.connect(transport);这里有两个容易踩的点。第一registerTool的第一个参数是工具名客户端里显示的就是它别用中文或空格。第二工具回调里不要往 stdout 打日志因为 stdout 是协议通道你打一行普通日志就可能破坏握手。要调试就写console.error它走 stderr不影响协议。4. 验证请求用 Cursor 和 curl 确认 MCP 链接生效代码写完后先本地跑一下确认不报错node app.js如果进程挂住不动、没有输出这是正常的——它在等 stdio 输入。按 CtrlC 退出即可。接下来用 Cursor 测试。打开 Cursor 的 MCP 配置写入{ mcpServers: { mcp-Test: { command: D:\\Users\\zhangsan\\AppData\\Local\\nvm\\v20.11.1\\node, args: [C:\\Users\\zhangsan\\Desktop\\as\\src\\app.js] } } }command填 node 可执行文件的绝对路径args填你的 app.js 绝对路径。Windows 下路径要用双反斜杠转义。保存后重启 Cursor在 MCP 面板里应该能看到mcp-Test下面挂着两个工具sum和createFile。触发sum时传{a: 3, b: 5}返回文本应该是“两数求和结果8”。触发createFile时传文件名和内容比如{filename: test.txt, content: hello mcp}执行后去对应目录看文件是否生成。我实测下来只要路径没写错文件会直接落在 node 进程的工作目录下——如果你没指定绝对路径它可能创建在你意想不到的地方这点要注意。除了 CursorCherry Studio 也能加 MCP 工具而且它里面可以同时挂多个模型和多个 MCP 服务适合做交叉验证。如果你想让模型自动决定调用哪个工具就在 Cherry Studio 里把模型通道配成 TaoToken 的 API 基址和 Key然后问它“帮我算 12 加 30”看它会不会自动走sum工具。想用命令行验证协议层是否正常可以用 curl 走 HTTP 方式前提是你把 transport 换成 HTTP 类型。stdio 模式下 curl 不方便直接测更实际的做法是看客户端日志。Cursor 的 MCP 日志里会打印握手和工具列表如果工具没出现日志里通常会有报错原因。5. 本篇常见错排查工具列表为空九成是路径问题。command必须是 node 的绝对路径不是node这个字符串args必须是 app.js 的绝对路径。Windows 下用where node查路径注意反斜杠转义。进程启动就退出检查 app.js 里有没有顶层 await 报错或者依赖没装全。先单独node app.js跑一遍看 stderr 输出。调用工具没反应检查工具回调里是不是往 stdout 打了日志。任何console.log都会污染协议通道改用console.error。文件创建到了奇怪的位置fs.writeFileSync用的是相对路径时基准是 node 进程的工作目录不是 app.js 所在目录。要可控就传绝对路径。客户端识别不到服务确认客户端版本支持 MCP并且配置保存后重启了客户端。有些客户端需要手动刷新 MCP 列表。模型不调用工具这不是 MCP 的问题是模型侧的工具调用能力。确认客户端里模型通道配置正确并且该模型支持 function calling / tool use。6. 把 Key 和通道固定下来后面少折腾MCP 服务跑通之后你会发现真正花时间的不是写工具而是每换一个客户端就重配一遍模型。我的做法是把模型入口统一到 TaoToken一个 Key一个 API 基址对话类场景走模型对话长期编码和 Agent 场景走 Coding Plan接入细节看接入文档。这样 MCP 服务本身保持干净只负责工具模型通道的事交给统一入口。如果你还在调工具注册和握手先去 API Keys 页面把 Key 建好再对着接入文档把客户端配通如果只是想先验证模型能不能正确调用你写的工具直接开模型对话试一句“帮我算 7 加 9”如果你打算把 MCP 工具长期挂在编码流程里那 Coding Plan 更合适。三条路都指向同一个 Key配一次就行。