Skip to content
This page has been auto-translated and may contain errors.View in English

在本地运行 Model Context Protocol

用这个页面来运行提取出来的 TypeScript MCP 服务器,试试它的天气工具和资源。服务器通过标准输入输出与客户端通信,所以它在等待客户端,而不是打开项目页面或应用端口。

你需要先准备什么

安装 Node 24。MCP Inspector 设置了最低 Node 版本要求(写这段文档时是 22.19);Node 24 超过这个最低版本,而较旧的 LTS 版本可能无法启动测试界面。

这个项目不需要 API key 或 .env 文件。MCP 客户端把服务器作为子进程启动,所以 Node 版本和运行环境来自你机器上的启动方式。

Juno你需要先准备什么 安装 Node 24,就这样,没有其他要求:不需要 API key,不需要 .env 文件。有个意外的地方是,这个服务器永远不会打开网页;它静静地等待客户端,第一次运行的时候我完全被骗了。
Juno你需要先准备什么 Node 24 满足 TypeScript 服务器和 Inspector 的最低版本要求,一次安装就够了。项目通过 stdio 而不是 HTTP 端口通信,所以不要等待永远不会出现的 URL。
Juno你需要先准备什么 客户端把这个服务器作为子进程启动,所以 Node 版本和环境来自启动它的东西,不是来自服务器文件夹。这就是为什么客户端的 Node 安装很重要,即使服务器本身不需要 key 也不需要端口。"服务器不需要任何东西"这个说法只在启动它的客户端运行受支持的 Node 版本时才成立。

安装和修复服务器

在包含 package.json 的提取出来的服务器文件夹中打开终端:

bash
$ cd path-to-your-downloaded-project
$ npm ci
$ npm install --save-dev tsx

最后一条命令记录 tsx,这是运行 TypeScript 文件的工具,提取出来的 "start": "tsx server.ts" 脚本需要它。

你可以直接启动 stdio 服务器:

bash
$ npm start

它等待一个 MCP 客户端而不是打印浏览器 URL。在启动 Inspector 前用 Ctrl+C 停止它。

Juno安装和修复服务器 运行 npm ci,添加运行 TypeScript 文件所需的缺失 tsx 工具,然后尝试 npm start。当终端安静下来时,没什么问题:服务器在等待客户端与它通话。我重启了三次才有人告诉我这一点!
Juno安装和修复服务器 包的启动脚本已经预期了 tsx,所以把它记录为开发依赖是最小的可重复修复。等待的 stdio 进程是成功的启动,不是挂起;抵住重启它的冲动。
Juno安装和修复服务器npm ci 只安装了锁定文件记录的东西,tsx 不在其中。用 --save-dev 安装会把 tsx 写入 package.json 和锁定文件。记录在清单中的这个依赖就是让客户端稍后能从任何目录用 npm exec 启动服务器的原因。记录在清单中的修复会被保留;只存在于你的 shell 历史中的修复不会。

用 MCP Inspector 测试

从同一个项目文件夹运行官方 MCP Inspector

bash
$ npx @modelcontextprotocol/inspector npx tsx server.ts

第一个 npx 下载并启动 Inspector,它可能会要求一次性安装的权限;在接受前确认包是 @modelcontextprotocol/inspector,对于可重复的团队使用,固定一个已审查的版本而不是无限期依赖最新发布。然后 Inspector 用 npx tsx server.ts 作为它的 stdio 子进程启动你的服务器。它的网页界面在自己的本地端口上运行,与到服务器的 stdio 连接分开。如果没有自动打开,打开终端打印的本地 URL。

在 Inspector 中,连接到服务器,列出它的工具和资源,用课程中使用的输入之一调用天气工具。工具使用章节解释了像这样的工具定义给模型的东西。测试时让终端保持打开,然后用 Ctrl+C 停止 Inspector 和子服务器。

Juno用 MCP Inspector 测试 运行 Inspector 命令,打开它的本地 URL,连接,然后列出并调用课程工具和资源。接受下载前检查包名,就像打开网址前检查一样。
Juno用 MCP Inspector 测试 Inspector 是这里的客户端,它把 server.ts 作为它的 stdio 子进程启动。在调用前验证发现:如果工具列表是空的,调用任何东西都没意义。保持终端打开并用 Ctrl+C 停止两个进程。
Juno用 MCP Inspector 测试 内层命令与下一节给桌面客户端的进程契约相同,所以在这里让它工作意味着稍后的客户端配置是复制值而不是调试。Inspector 的网页界面端口与 stdio 传输分开:忙碌的端口会阻止网页界面,而服务器本身继续运行。

连接另一个 MCP 客户端

桌面客户端需要一个可执行命令和启动同一个 stdio 服务器的参数。首先,复制提取出来的项目文件夹和它的 server.ts 文件的绝对路径。用这个进程契约配置客户端,替换两个示例路径:

text
command: npm
arguments:
  - --prefix
  - /absolute/path/to/project
  - exec
  - --
  - tsx
  - /absolute/path/to/project/server.ts

--prefix 值让 npm 使用在那个项目中安装的 tsx 依赖,即使桌面客户端从另一个工作目录启动。配置为独立运行 tsx 的客户端(前面没有 npm --prefix)依赖于全局安装和客户端的 PATH,它通常与你的终端的不同。把每个参数作为一个单独的项,这样包含空格的路径仍然是一个值。不要添加 URL 或端口:这个服务器通过 stdio 通信。

这样连接服务器是桌面客户端给它们的模型提供工具的方式;agents 章节涵盖了使用这些工具的循环。

客户端配置格式不同,所以把那个命令和那些参数映射到客户端当前 MCP 设置说明中的字段。修改配置后重启客户端。你不需要另一个项目下载:把它连接到你已经测试过的提取出来的服务器。

Juno连接另一个 MCP 客户端 把命令设为 npm,添加文档化的参数并填入两个绝对路径,然后重启客户端。你在重用 Inspector 测试过的同一个提取出来的服务器,所以如果它在那里工作了,服务器端已经被证明了。
Juno连接另一个 MCP 客户端 客户端配置语法不同,但进程契约保持相同:npm --prefix 选择项目,exec -- tsx 通过 stdio 启动它的 TypeScript 服务器。把这些片段映射到客户端使用的任何字段名。
Juno连接另一个 MCP 客户端 配置为独立运行 tsx 的客户端只在已经有全局安装的机器上工作,而桌面客户端很少继承你的终端的 PATH。npm --prefixexec 命令把启动固定到项目自己记录的依赖上。依赖于启动环境的配置是在第二台机器上失败的。

故障排除

tsx: command not found 在项目文件夹中运行 npm install --save-dev tsx。对于桌面客户端,也要确认它的命令是 npm 并且它的参数以 --prefix 开头,后面跟绝对项目路径。

Inspector 拒绝 Node 版本: 安装 Node 24,用 node --version 验证,并重新打开终端。

npm start 似乎挂起: 这是等待客户端的 stdio 服务器的预期行为。用 Inspector 与它交互。

Inspector 没显示工具: 检查终端中的 TypeScript 或连接错误,确认最后的命令以 npx tsx server.ts 结尾。

Juno故障排除 如果 tsx 丢失就安装它,如果 Inspector 拒绝启动就升级到 Node 24,记住安静的服务器是等待的服务器,不是坏掉的。这个页面上的几乎每个问题都是这三个中的一个。
Juno故障排除 分离三个故障层:tsx 安装、Inspector 的最低 Node 版本和 stdio 连接本身。在假设工具注册失败前检查终端输出;真正的错误通常已经打印在那里了。
Juno故障排除 按顺序追踪链:外层 Inspector 进程、子启动命令、TypeScript 执行、MCP 初始化。这条链中的任何步骤都可能让工具列表为空,如果你在重启前读终端,它会告诉你哪个坏了。先重启是常见的本能,而且它很少能告诉你什么。