MCP工具能用，resources/list却报Method not found

MCP连接建立后，tools/list 和 tools/call 都能工作，调用 resources/list 却返回 -32601 Method not found。先看服务端是否声明了资源能力。一个只提供工具的服务器，不必同时实现资源和提示词接口。

本文针对带 initialize 握手的协议版本，以2025-11-25的能力声明规则说明。2026-07-28改用逐请求的协议元数据和能力协商，迁移时需要核对双方支持的版本，不能把旧握手流程当成所有现行连接的前提。

初始化成功不代表所有方法都存在

只提供工具的服务器，初始化结果可能包含这样的能力对象：

{
  "tools": {
    "listChanged": true
  }
}

这没有声明 resources 或 prompts。客户端若把 list_resources、read_resource、list_prompts 和 get_prompt 全部包装成模型工具，模型就会尝试调用远端没有提供的方法。

检查真正收到的初始化结果，再对照失败请求的方法名。不要因为可选方法失败，就把已经验证可用的工具服务器标成“断开连接”。也不要给工具服务器补几个空资源接口，只为迎合客户端错误暴露的工具列表。

本地对象有方法，不能证明远端支持

Python SDK的 ClientSession 可以同时定义多个请求方法。hasattr(session, "list_resources") 检查的是本地类或对象，不是远端实现。

在使用这类初始化结果模型的客户端中，应保留 initialize() 的返回值，按能力是否为 None 决定要不要注册对应包装器。下面仅说明应用层门控逻辑，假定 session 已由原有代码正确进入上下文：

initialize_result = await session.initialize()
capabilities = initialize_result.capabilities

supports_resources = capabilities.resources is not None
supports_prompts = capabilities.prompts is not None

它不是完整连接程序，不新建服务器进程，也不保证任何第三方封装都采用相同数据模型。应用保存初始化结果后，还要让工具注册、刷新和重连路径都使用这份结果。

声明 resources: {} 与完全没有 resources 含义不同。空对象表示资源能力存在，只是没有声明 subscribe、listChanged 等可选功能。因此门控不能用空字典的真假值来判断是否支持资源，也不能把 listChanged: false 当成整个资源接口不可用。

检查提供给模型的最终工具列表

在工具型服务器上，确认真正的业务工具保留，资源和提示词包装器不再出现。支持资源的服务器仍应能列举与读取资源；支持提示词的服务器同理。配置里显式禁用的包装器，还应保持禁用。

部分实现已经合入过能力门控改动，但合并记录不足以给所有发行包指定“首个修复版”。部署时应检查实际安装的发布包或提交内容，再决定升级；不要仅凭服务器版本号推断客户端包装逻辑已经正确。

如果收到的是 Unexpected identifier 之类JSON解析错误，可以按stdio输出混入普通日志排查，它发生在消息解析层。若携带旧会话ID的HTTP请求返回404，可对照会话失效后的重新初始化。本篇讨论的是已解析成功的可选方法调用，排查入口需要保持清楚。