MCP（Model Context Protocol）的落地链路涉及Host、Client、Server三个角色，任何一环配置不当都会导致工具无法被LLM调用。本文基于公开实战资料，梳理从环境准备到Host连接的排错路径，重点覆盖description字段、Node版本依赖和Inspector调试。

一、链路角色与常见故障点

MCP采用CS架构，Host是面向用户的入口（如ChatMCP），Client负责与Server通信，Server提供工具能力。资料显示，MCP Server提供command和SSE两种类型功能。全链路排错的核心是确认：Server能否独立启动、Client能否发现工具、Host能否把工具描述传给LLM并触发调用。

常见故障集中在三处：本地Node环境版本不足、Server的description字段缺失或模糊、Host未配置支持function calling的LLM。

二、环境依赖：Node版本是第一道门槛

资料明确指出，调试MCP需本地有高版本Node环境。这是最容易被忽略的排错起点。如果Server基于TypeScript SDK开发，低版本Node可能导致启动失败或协议握手异常。

检查清单：
- 执行node -v确认版本，若低于项目要求则升级；
- 确认npm/npx可用，避免Server启动命令找不到；
- 若使用Java SDK（如0.7.0版本），需确认JDK与依赖版本匹配。

工程建议：在Server启动脚本中加入版本检查，失败时输出明确错误，而不是静默退出。

三、Server实现：description字段决定LLM能否正确调用

资料特别强调MCP Server实现中description字段的重要性。该字段是LLM理解工具用途的唯一自然语言入口。如果description缺失、过于简略或与实际功能不符，LLM可能不调用、误调用或传错参数。

排错时优先检查：
- 每个tool是否有独立且语义清晰的description；
- description是否说明了输入参数的含义和格式；
- 是否存在多个tool描述雷同，导致LLM无法区分。

工程分析：description应写成“做什么+何时用+参数说明”，避免只写工具名。这是提升调用准确率的最低成本手段。

四、Client实现与执行

资料提到MCP Client实现需撰写代码并执行。Client的核心职责是连接Server、列出可用工具、将工具描述传递给Host。若Client执行报错，先确认Server是否已正常启动，再检查传输方式（command或SSE）是否与Server一致。

检查清单：
- Client连接参数与Server启动方式匹配；
- 工具列表能否成功拉取；
- 调用单个工具时参数是否符合description定义。

五、Host配置：以ChatMCP为例

资料以ChatMCP为例说明Host配置，要求配置支持function calling的LLM。这是全链路最后一环，也是最容易误判的一环：如果LLM本身不支持function calling，即使Server和Client都正常，工具也不会被触发。

排错顺序建议：
1. 确认Host中配置的LLM支持function calling；
2. 确认Host已正确加载Client提供的工具列表；
3. 在对话中提出明确需要工具的问题，观察是否触发调用；
4. 若未触发，回查description是否被Host完整传递。

六、MCP Inspector调试

资料提到MCP Inspector调试工具，可用于在接入Host之前独立验证Server。建议将Inspector作为排错中间层：先用Inspector连接Server，确认工具列表和调用结果正常，再接入Client和Host。这样可以快速定位问题出在Server侧还是Host侧。

七、全链路检查清单

  • Node版本满足要求；
  • Server可独立启动，description字段完整清晰；
  • Client能连接Server并拉取工具列表；
  • Host配置的LLM支持function calling；
  • 使用Inspector隔离验证Server；
  • 工具调用参数与description一致。

按此顺序逐层排查，可避免在Host侧反复调试却忽略Server描述或环境依赖的问题。