首页/排错/MCP 排错
MCP 排错

只要把基础工具层和 server 层分开看,MCP 排错就会清楚很多

MCP 问题很容易被过度诊断,因为它出现在栈的更高层。现实里,很多所谓 MCP 故障,其实还是安装、配置、provider 或 shell 层的问题,只是加了 server 以后才暴露出来。

本页是站内详情页DeepSeek TUI 的 MCP 排错排错

这页应该先回答的问题

  • 不启用 MCP 时,基础工具本身是否工作正常?
  • server 是否以配置预期的方式被声明和启动?
  • 你现在排的是 MCP server 问题,还是一个披着 MCP 外衣的更底层问题?

这页应该帮你判断什么

这页要帮助用户按层排 MCP:基础安装、配置、server 声明、server 可达性,以及预期工具面。

快速定位

基础工具层

先确认不带 MCP 时应用也能正常工作,保证基础层是稳的。

声明层

检查 server 的配置路径、启动命令和环境变量是否真的和当前配置一致。

可达层

确认 server 能启动且持续存活,而不是刚起就挂。

预期层

别把没有暴露的能力误当成启动失败,要确认 server 原本承诺的 tool surface 是什么。

逐步处理流程

  1. 先跑非 MCP 基线
    如果不带 MCP 时工具已经不稳定,先修基础层。
  2. 再看 server 声明
    核对配置文件里的 server 定义、命令和环境。
  3. 验证 server 可用性
    确认 server 能正确启动并持续可用,而不是瞬间退出。
  4. 比较预期与实际 tool surface
    缺少某个能力,不一定是故障,也可能只是 server 本来就没有提供。

常见误区

  • 基础安装都没稳,就先把所有高级问题归咎于 MCP。
  • 默认 server 会提供它从未承诺的工具或 schema。
  • 只从客户端侧看问题,没有确认 server 启动层是否正常。

什么时候可以离开这页

当你已经知道问题属于基础栈、MCP 声明、server 运行时,还是自己对 tool surface 的预期错误时,就可以离开这页了。

直接可用的示例

先拿可执行例子,再回头做更细的调整。

先拿同一任务做一次无 MCP 对照

隔离 MCP 最快的方法,就是让任务不变,只把 MCP 这一层拿掉。

# 先在无 MCP 情况下跑一次窄任务
# 再启用单个 MCP server 重跑

先查 server 声明,再猜客户端问题

先确认 server 命令、路径和它承诺暴露的能力,再判断是不是客户端层异常。

# 检查 server 定义
# 核对启动命令和预期 tool surface

常见失败分支

先判断你卡在哪一层,再去对应分支,不要把所有问题都混成一个。

基础 app 本身已经不稳

那就不要先叫它 MCP bug。先把安装、配置或 provider 基线修稳。

server 启动了,但预期工具没有出现

这可能不是启动失败,而是 server 能力面和你的预期不一致。