MCPModel Context Protocol的落地链路涉及Host、Client、Server三个角色任何一环配置不当都会导致工具无法被LLM调用。本文基于公开实战资料梳理从环境准备到Host连接的排错路径重点覆盖description字段、Node版本依赖和Inspector调试。一、链路角色与常见故障点MCP采用CS架构Host是面向用户的入口如ChatMCPClient负责与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是否有独立且语义清晰的descriptiondescription是否说明了输入参数的含义和格式是否存在多个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都正常工具也不会被触发。排错顺序建议确认Host中配置的LLM支持function calling确认Host已正确加载Client提供的工具列表在对话中提出明确需要工具的问题观察是否触发调用若未触发回查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描述或环境依赖的问题。