MCP getTools fallback 到 SSE 导致 405，但 runTool 可正常调用 Streamable HTTP MCP

[Mrxia7757]

例行检查

• 我已确认目前没有类似 issue
• 我已完整查看过项目 README，以及项目文档
• 我使用了自己的 key，并确认 key 可正常使用
• 我理解并愿意跟进此 issue，协助测试和提供反馈
• 我理解并认可上述内容，并理解项目维护者精力有限

你的版本

• 公有云版本
• 私有部署版本，版本号：V4.14.9

问题描述

我们在 FastGPT 私有化环境中接入 Streamable HTTP MCP endpoint 时，发现 runTool 可以正常执行工具并返回 200，但 getTools 解析/刷新工具列表时失败。

后端日志显示：getTools 阶段先尝试 StreamableHTTP，失败后 fallback 到 SSE；由于该 MCP endpoint 不支持 SSE GET，最终报 405。

[POST] /api/core/app/mcpTools/getTools
StreamableHTTP connect failed, falling back to SSE
SSE error: Non-200 status code (405)
[POST] /api/core/app/mcpTools/getTools - 500

但同一个 MCP endpoint 执行工具时可以成功：

[POST] /api/core/app/mcpTools/runTool
MCP client calling tool
[POST] /api/core/app/mcpTools/runTool - 200

我们单独测试 MCP endpoint，结果是：

POST initialize：成功
POST tools/list：成功
GET：405
SSE GET：405

因此该 MCP 服务本身可用，问题集中在 FastGPT 的 getTools 链路：getTools 失败后 fallback 到 SSE，而该 endpoint 不是 SSE endpoint。

最小复现 MCP 服务

from fastapi import FastAPI, Request, Response
from fastapi.responses import JSONResponse
import uvicorn, json

app = FastAPI()
TOKEN = "demo-token"

def ok_auth(req: Request):
    return req.headers.get("authorization") == f"Bearer {TOKEN}"

def err(i, code, msg, status=200):
    return JSONResponse(status_code=status, content={"jsonrpc":"2.0","id":i,"error":{"code":code,"message":msg}})

@app.get("/services/mcp")
async def get_mcp(req: Request):
    return JSONResponse(status_code=405, content={"message":"Method not allowed"})

@app.get("/services/mcp/sse")
async def get_sse(req: Request):
    return JSONResponse(status_code=405, content={"message":"Method not allowed"})

@app.post("/services/mcp")
async def post_mcp(req: Request):
    body = await req.json()
    i = body.get("id")
    m = body.get("method")
    if not ok_auth(req):
        return err(i, -32600, "Authentication failed: No bearer token provided", 401)
    if m == "initialize":
        return {"jsonrpc":"2.0","id":i,"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{}},"serverInfo":{"name":"mock-mcp","version":"1.0.0"}}}
    if m == "notifications/initialized":
        return Response(status_code=200)
    if m == "tools/list":
        return {"jsonrpc":"2.0","id":i,"result":{"tools":[{"name":"demo_get_info","description":"demo tool","inputSchema":{"type":"object","properties":{}}}]}}
    if m == "tools/call":
        result = {"status":"ok","message":"tool call success"}
        return {"jsonrpc":"2.0","id":i,"result":{"content":[{"type":"text","text":json.dumps(result)}],"structuredContent":result}}
    return err(i, -32601, f"Method {m} not found")

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=18089)

启动：

pip install fastapi uvicorn
python mock_mcp_server.py

FastGPT 中配置：

MCP 地址：http://<server-ip>:18089/services/mcp
鉴权 Header：Authorization: Bearer demo-token

复现步骤

1. 在 FastGPT 中添加上述 MCP 地址。
2. 配置 Header：Authorization: Bearer demo-token。
3. 点击解析/刷新工具列表。
4. 观察 FastGPT 后端日志。
5. 如果 getTools 失败后 fallback 到 SSE，会出现 SSE error: Non-200 status code (405)。
6. 执行已存在工具时，runTool 可以正常返回 200。

预期结果

对于 Streamable HTTP MCP endpoint：

• getTools 使用 Streamable HTTP / POST JSON-RPC 获取工具列表；
• runTool 使用 Streamable HTTP / POST JSON-RPC 执行工具；
• getTools 和 runTool 调用逻辑保持一致；
• 如果 StreamableHTTP 失败，建议不要默认 fallback 到 SSE，或提供关闭 SSE fallback 的配置。

实际结果

runTool 可以成功，但 getTools 阶段失败后 fallback 到 SSE，最终触发 405。

[c121914yu]

不支持 streamable 也不支持 SSE？没有第三个协议了呢。

[Mrxia7757]

这里可能有个误解：不是“不支持 Streamable HTTP 也不支持 SSE”，而是：

1. 不支持旧版 SSE transport；
2. 不提供 Streamable HTTP 里的 GET/SSE 监听流；
3. 但支持 Streamable HTTP 的 POST JSON-RPC 主链路。

我又单独做了一次最小化测试，结果如下：

MCP endpoint:
https://<host>/services/mcp

鉴权:
Authorization: Bearer <token>

测试结果：

OPTIONS /services/mcp
=> 200 OK

GET /services/mcp
=> 405 Method Not Allowed

GET /services/mcp with Accept: text/event-stream
=> 405 Method Not Allowed

POST /services/mcp method=initialize
=> 200 OK

POST /services/mcp method=notifications/initialized
=> 200 OK

POST /services/mcp method=tools/list
=> 200 OK，成功返回工具列表，共 10 个 tools

其中 initialize 返回：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {}
    },
    "serverInfo": {
      "name": "Splunk_MCP_Server",
      "version": "1.1.0"
    }
  }
}

tools/list 也能正常返回工具，例如：

splunk_get_info
splunk_get_indexes
splunk_get_index_info
splunk_get_user_list
splunk_get_user_info
splunk_run_query
splunk_get_metadata
splunk_get_kv_store_collections
splunk_get_knowledge_objects
splunk_run_saved_search

所以这个服务端并不是“不支持 Streamable HTTP”。它支持的是 Streamable HTTP 的 POST JSON-RPC 调用方式，只是不支持 GET 建立 SSE stream。

按照 MCP Streamable HTTP 的设计，核心 JSON-RPC 消息是通过 POST 发送的；GET 只是用于服务端主动消息 / SSE stream 的可选通道。如果服务端不提供该 SSE stream，GET 返回 405 是合理的，并不能据此判断 Streamable HTTP 不可用。

现在的问题点是 FastGPT 的 getTools 链路：

StreamableHTTP connect failed, falling back to SSE
SSE error: Non-200 status code (405)

这里真正需要定位的是第一句：

StreamableHTTP connect failed

因为同一个 endpoint 用 POST JSON-RPC 执行：

initialize
notifications/initialized
tools/list
tools/call

都可以成功，其中 FastGPT 的 runTool 也能正常返回 200。

因此我认为问题更可能在 FastGPT 的 getTools 实现里：

1. getTools 和 runTool 使用的 Streamable HTTP 调用逻辑不一致；
2. getTools 的 StreamableHTTP 初始化 / tools/list 阶段出现异常后，没有暴露原始异常；
3. fallback 到 SSE 后，把合理的 GET 405 当作最终错误；
4. 对于已经按 Streamable HTTP 配置的 endpoint，建议不要自动 fallback 到旧 SSE transport，或者提供关闭 SSE fallback 的配置；
5. 建议先打印 StreamableHTTP connect failed 的完整异常堆栈，这样才能确认 getTools 为什么没有像 runTool 一样走通 POST JSON-RPC。

补充一个可复现测试脚本思路：

import requests
import json

MCP_URL = "https://<host>/services/mcp"
TOKEN = "<token>"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Content-Type": "application/json",
    "Accept": "application/json, text/event-stream",
    "MCP-Protocol-Version": "2025-06-18",
}

def post(payload):
    r = requests.post(MCP_URL, headers=headers, data=json.dumps(payload), timeout=30)
    print(r.status_code, r.text[:1000])
    return r

# 1. initialize
post({
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
        "protocolVersion": "2025-06-18",
        "capabilities": {
            "roots": {"listChanged": True},
            "sampling": {}
        },
        "clientInfo": {
            "name": "mcp-probe",
            "version": "1.0.0"
        }
    }
})

# 2. initialized notification
post({
    "jsonrpc": "2.0",
    "method": "notifications/initialized",
    "params": {}
})

# 3. tools/list
post({
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/list",
    "params": {}
})

# 4. SSE GET probe
sse_headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "text/event-stream",
}
r = requests.get(MCP_URL, headers=sse_headers, timeout=15)
print("SSE GET:", r.status_code, r.text[:1000])

这个脚本可以复现：

POST initialize: 200
POST notifications/initialized: 200
POST tools/list: 200
GET/SSE GET: 405

因此这里的 405 只能说明该 endpoint 不提供 SSE GET stream，不能说明它不支持 Streamable HTTP。

[luanxu-dev]

我觉得这里可以把两个判断拆开：

1. Streamable HTTP 的 POST JSON-RPC 主链路是否可用；
2. 是否额外支持 GET/SSE 监听流。

这个复现里 initialize、notifications/initialized、tools/list 都能通过 POST 返回 200，所以 getTools 不应该因为 GET/SSE 405 就把整个 StreamableHTTP 判定失败。

比较安全的处理顺序可能是：先用 POST initialize 建 session，再用 POST tools/list 拉工具；只有 POST initialize/tools/list 返回协议错误或网络错误时才进入 fallback。GET with Accept: text/event-stream 返回 405 时，只标记“没有 server-to-client stream”，不影响一次性 tools/list。

这样也能解释为什么 runTool 成功但 getTools 失败：runTool 走的是 POST 主链路，而 getTools 的 fallback 把一个可用的 POST-only Streamable HTTP endpoint 当成了 SSE endpoint。

[c121914yu]

我觉得这里可以把两个判断拆开：

1. Streamable HTTP 的 POST JSON-RPC 主链路是否可用；
2. 是否额外支持 GET/SSE 监听流。

这个复现里 initialize、notifications/initialized、tools/list 都能通过 POST 返回 200，所以 getTools 不应该因为 GET/SSE 405 就把整个 StreamableHTTP 判定失败。

比较安全的处理顺序可能是：先用 POST initialize 建 session，再用 POST tools/list 拉工具；只有 POST initialize/tools/list 返回协议错误或网络错误时才进入 fallback。GET with Accept: text/event-stream 返回 405 时，只标记“没有 server-to-client stream”，不影响一次性 tools/list。

这样也能解释为什么 runTool 成功但 getTools 失败：runTool 走的是 POST 主链路，而 getTools 的 fallback 把一个可用的 POST-only Streamable HTTP endpoint 当成了 SSE endpoint。

sreamable 初始化都失败了，fallback 到 sse 失败不失败不影响呢。

[c121914yu]

这里可能有个误解：不是“不支持 Streamable HTTP 也不支持 SSE”，而是：

1. 不支持旧版 SSE transport；
2. 不提供 Streamable HTTP 里的 GET/SSE 监听流；
3. 但支持 Streamable HTTP 的 POST JSON-RPC 主链路。

我又单独做了一次最小化测试，结果如下：

MCP endpoint:
https://<host>/services/mcp

鉴权:
Authorization: Bearer <token>

测试结果：

OPTIONS /services/mcp
=> 200 OK

GET /services/mcp
=> 405 Method Not Allowed

GET /services/mcp with Accept: text/event-stream
=> 405 Method Not Allowed

POST /services/mcp method=initialize
=> 200 OK

POST /services/mcp method=notifications/initialized
=> 200 OK

POST /services/mcp method=tools/list
=> 200 OK，成功返回工具列表，共 10 个 tools

其中 initialize 返回：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {}
    },
    "serverInfo": {
      "name": "Splunk_MCP_Server",
      "version": "1.1.0"
    }
  }
}

tools/list 也能正常返回工具，例如：

splunk_get_info
splunk_get_indexes
splunk_get_index_info
splunk_get_user_list
splunk_get_user_info
splunk_run_query
splunk_get_metadata
splunk_get_kv_store_collections
splunk_get_knowledge_objects
splunk_run_saved_search

所以这个服务端并不是“不支持 Streamable HTTP”。它支持的是 Streamable HTTP 的 POST JSON-RPC 调用方式，只是不支持 GET 建立 SSE stream。

按照 MCP Streamable HTTP 的设计，核心 JSON-RPC 消息是通过 POST 发送的；GET 只是用于服务端主动消息 / SSE stream 的可选通道。如果服务端不提供该 SSE stream，GET 返回 405 是合理的，并不能据此判断 Streamable HTTP 不可用。

现在的问题点是 FastGPT 的 getTools 链路：

StreamableHTTP connect failed, falling back to SSE
SSE error: Non-200 status code (405)

这里真正需要定位的是第一句：

StreamableHTTP connect failed

因为同一个 endpoint 用 POST JSON-RPC 执行：

initialize
notifications/initialized
tools/list
tools/call

都可以成功，其中 FastGPT 的 runTool 也能正常返回 200。

因此我认为问题更可能在 FastGPT 的 getTools 实现里：

1. getTools 和 runTool 使用的 Streamable HTTP 调用逻辑不一致；
2. getTools 的 StreamableHTTP 初始化 / tools/list 阶段出现异常后，没有暴露原始异常；
3. fallback 到 SSE 后，把合理的 GET 405 当作最终错误；
4. 对于已经按 Streamable HTTP 配置的 endpoint，建议不要自动 fallback 到旧 SSE transport，或者提供关闭 SSE fallback 的配置；
5. 建议先打印 StreamableHTTP connect failed 的完整异常堆栈，这样才能确认 getTools 为什么没有像 runTool 一样走通 POST JSON-RPC。

补充一个可复现测试脚本思路：

import requests
import json

MCP_URL = "https://<host>/services/mcp"
TOKEN = "<token>"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Content-Type": "application/json",
    "Accept": "application/json, text/event-stream",
    "MCP-Protocol-Version": "2025-06-18",
}

def post(payload):
    r = requests.post(MCP_URL, headers=headers, data=json.dumps(payload), timeout=30)
    print(r.status_code, r.text[:1000])
    return r

# 1. initialize
post({
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
        "protocolVersion": "2025-06-18",
        "capabilities": {
            "roots": {"listChanged": True},
            "sampling": {}
        },
        "clientInfo": {
            "name": "mcp-probe",
            "version": "1.0.0"
        }
    }
})

# 2. initialized notification
post({
    "jsonrpc": "2.0",
    "method": "notifications/initialized",
    "params": {}
})

# 3. tools/list
post({
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/list",
    "params": {}
})

# 4. SSE GET probe
sse_headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "text/event-stream",
}
r = requests.get(MCP_URL, headers=sse_headers, timeout=15)
print("SSE GET:", r.status_code, r.text[:1000])

这个脚本可以复现：

POST initialize: 200
POST notifications/initialized: 200
POST tools/list: 200
GET/SSE GET: 405

因此这里的 405 只能说明该 endpoint 不提供 SSE GET stream，不能说明它不支持 Streamable HTTP。

这个 mock 只说明该 endpoint 不支持旧 SSE transport，但不说明 Streamable HTTP 失败；如果 FastGPT fallback 到 SSE，说明 Streamable 初始化阶段另有错误，需要提供原始 StreamableHTTP error 日志。
AI 分析了没啥问题，大概率是你streamable初始化阶段都失败了。

[Mrxia7757]

这里可能有个误解：不是“不支持 Streamable HTTP 也不支持 SSE”，而是：

1. 不支持旧版 SSE transport；
2. 不提供 Streamable HTTP 里的 GET/SSE 监听流；
3. 但支持 Streamable HTTP 的 POST JSON-RPC 主链路。

我又单独做了一次最小化测试，结果如下：

MCP endpoint:
https://<host>/services/mcp

鉴权:
Authorization: Bearer <token>

测试结果：

OPTIONS /services/mcp
=> 200 OK

GET /services/mcp
=> 405 Method Not Allowed

GET /services/mcp with Accept: text/event-stream
=> 405 Method Not Allowed

POST /services/mcp method=initialize
=> 200 OK

POST /services/mcp method=notifications/initialized
=> 200 OK

POST /services/mcp method=tools/list
=> 200 OK，成功返回工具列表，共 10 个 tools

其中 initialize 返回：
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-06-18",
"capabilities": {
"tools": {}
},
"serverInfo": {
"name": "Splunk_MCP_Server",
"version": "1.1.0"
}
}
}

tools/list 也能正常返回工具，例如：

splunk_get_info
splunk_get_indexes
splunk_get_index_info
splunk_get_user_list
splunk_get_user_info
splunk_run_query
splunk_get_metadata
splunk_get_kv_store_collections
splunk_get_knowledge_objects
splunk_run_saved_search

所以这个服务端并不是“不支持 Streamable HTTP”。它支持的是 Streamable HTTP 的 POST JSON-RPC 调用方式，只是不支持 GET 建立 SSE stream。
按照 MCP Streamable HTTP 的设计，核心 JSON-RPC 消息是通过 POST 发送的；GET 只是用于服务端主动消息 / SSE stream 的可选通道。如果服务端不提供该 SSE stream，GET 返回 405 是合理的，并不能据此判断 Streamable HTTP 不可用。
现在的问题点是 FastGPT 的 getTools 链路：

StreamableHTTP connect failed, falling back to SSE
SSE error: Non-200 status code (405)

这里真正需要定位的是第一句：

StreamableHTTP connect failed

因为同一个 endpoint 用 POST JSON-RPC 执行：

initialize
notifications/initialized
tools/list
tools/call

都可以成功，其中 FastGPT 的 runTool 也能正常返回 200。
因此我认为问题更可能在 FastGPT 的 getTools 实现里：

1. getTools 和 runTool 使用的 Streamable HTTP 调用逻辑不一致；
2. getTools 的 StreamableHTTP 初始化 / tools/list 阶段出现异常后，没有暴露原始异常；
3. fallback 到 SSE 后，把合理的 GET 405 当作最终错误；
4. 对于已经按 Streamable HTTP 配置的 endpoint，建议不要自动 fallback 到旧 SSE transport，或者提供关闭 SSE fallback 的配置；
5. 建议先打印 StreamableHTTP connect failed 的完整异常堆栈，这样才能确认 getTools 为什么没有像 runTool 一样走通 POST JSON-RPC。

补充一个可复现测试脚本思路：
import requests
import json

MCP_URL = "https:///services/mcp"
TOKEN = ""

headers = {
"Authorization": f"Bearer {TOKEN}",
"Content-Type": "application/json",
"Accept": "application/json, text/event-stream",
"MCP-Protocol-Version": "2025-06-18",
}

def post(payload):
r = requests.post(MCP_URL, headers=headers, data=json.dumps(payload), timeout=30)
print(r.status_code, r.text[:1000])
return r

1. initialize

post({
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {
"roots": {"listChanged": True},
"sampling": {}
},
"clientInfo": {
"name": "mcp-probe",
"version": "1.0.0"
}
}
})

2. initialized notification

post({
"jsonrpc": "2.0",
"method": "notifications/initialized",
"params": {}
})

3. tools/list

post({
"jsonrpc": "2.0",
"id": 2,
"method": "tools/list",
"params": {}
})

4. SSE GET probe

sse_headers = {
"Authorization": f"Bearer {TOKEN}",
"Accept": "text/event-stream",
}
r = requests.get(MCP_URL, headers=sse_headers, timeout=15)
print("SSE GET:", r.status_code, r.text[:1000])

这个脚本可以复现：

POST initialize: 200
POST notifications/initialized: 200
POST tools/list: 200
GET/SSE GET: 405

因此这里的 405 只能说明该 endpoint 不提供 SSE GET stream，不能说明它不支持 Streamable HTTP。

这个 mock 只说明该 endpoint 不支持旧 SSE transport，但不说明 Streamable HTTP 失败；如果 FastGPT fallback 到 SSE，说明 Streamable 初始化阶段另有错误，需要提供原始 StreamableHTTP error 日志。 AI 分析了没啥问题，大概率是你streamable初始化阶段都失败了。

可能我前面表达得有点问题，先修正一下：

我不是想直接断定根因一定是 FastGPT 的 StreamableHTTP 主链路实现错了，也可能是我的 MCP 服务端某个返回细节没有完全满足当前 SDK 的预期。

但我看了下 v4.14.9 的源码，感觉 FastGPT 这里至少有一个地方可以优化：StreamableHTTP connect failed 后 fallback 到 SSE 时，原始的 StreamableHTTP 错误被后面的 SSE 405 覆盖了，导致现在很难判断到底是哪一步失败。

我理解现在大概是这个逻辑：

try {
  const transport = new StreamableHTTPClientTransport(...)
  await this.client.connect(transport)
  return this.client
} catch (error) {
  logger.debug('StreamableHTTP connect failed, falling back to SSE', { error })
  await this.client.connect(new SSEClientTransport(...))
  return this.client
}

这里如果 StreamableHTTP 阶段真实失败原因是 header、session、initialized notification、tools/list 或 SDK 校验问题，后面 SSE 再返回 405，最终用户看到的就只剩 SSE 405 了。

所以我觉得 FastGPT 侧至少可以先这样改，供参考：

let streamableError: unknown

try {
  const transport = new StreamableHTTPClientTransport(new URL(url), {
    requestInit: {
      headers
    }
  })

  await client.connect(transport)
  return client
} catch (error) {
  streamableError = error

  logger.error('StreamableHTTP connect failed', {
    url,
    error
  })
}

try {
  const sseClient = new Client({
    name: 'FastGPT-MCP-client',
    version: '1.0.0'
  })

  const sseTransport = new SSEClientTransport(new URL(url), {
    requestInit: {
      headers
    }
  })

  await sseClient.connect(sseTransport)
  return sseClient
} catch (sseError) {
  logger.error('MCP connect failed on both StreamableHTTP and SSE', {
    url,
    streamableError,
    sseError
  })

  throw new Error(
    `MCP connect failed. StreamableHTTP error: ${String(streamableError)}; SSE error: ${String(sseError)}`
  )
}

更保守一点的话，也可以不改变 fallback 行为，只是把 StreamableHTTP 的原始异常保留下来：

catch (sseError) {
  logger.error('SSE fallback failed', {
    url,
    streamableError,
    sseError
  })

  throw new Error(
    `StreamableHTTP connect failed: ${String(streamableError)}; SSE fallback failed: ${String(sseError)}`
  )
}

这样至少可以先确认 StreamableHTTP connect failed 到底是卡在 initialize、initialized notification、tools/list、header 还是 session 校验上。

如果最终确认是我的 MCP 服务端响应不符合当前 SDK 要求，我可以配合修改服务端；但目前 FastGPT 这里把 StreamableHTTP 原始错误隐藏掉，确实会导致排查方向被 SSE 405 带偏，所以我觉得 FastGPT 侧这个错误处理逻辑也需要修一下。

[Mrxia7757]

现在 MCPClient.doConnect() 的逻辑大概是：

先尝试 StreamableHTTPClientTransport
  -> 任意异常
  -> fallback 到 SSEClientTransport
  -> SSE GET 返回 405
  -> 最终 getTools 失败

但对于 Streamable HTTP MCP endpoint 来说，判断主链路是否可用，应该主要看 POST JSON-RPC，也就是：

POST initialize
POST notifications/initialized
POST tools/list

GET with Accept: text/event-stream 返回 405，只能说明服务端不提供额外的 server-to-client SSE stream，不应该直接影响一次性的 tools/list。

所以我觉得 FastGPT 这里不只是要打印原始错误，而是可以把兼容逻辑改成：

1. 先尝试 Streamable HTTP；
2. 如果 Streamable HTTP connect 成功，直接使用它，不再 fallback；
3. 只有在 POST initialize 明确返回 404/405，说明这个 URL 不是 Streamable HTTP endpoint 时，才 fallback 到旧 SSE；
4. 如果只是 GET/SSE stream 返回 405，不应该把整个 Streamable HTTP 判定为失败；
5. fallback 到 SSE 时最好使用新的 Client，避免复用前一次 connect 失败后的 client 状态。

我不确定项目里是否还有其他兼容考虑，下面是我理解的修法，供参考：

private createClient() {
  return new Client({
    name: 'FastGPT-MCP-client',
    version: '1.0.0'
  });
}

private normalizeError(error: unknown) {
  if (error instanceof Error) {
    return {
      name: error.name,
      message: error.message,
      stack: error.stack
    };
  }

  return {
    message: String(error),
    raw: error
  };
}

private getErrorStatus(error: any): number | undefined {
  return (
    error?.status ||
    error?.statusCode ||
    error?.response?.status ||
    error?.cause?.status ||
    error?.cause?.statusCode
  );
}

private isLegacySSEFallbackCase(error: unknown) {
  const status = this.getErrorStatus(error);
  const message = error instanceof Error ? error.message : String(error);

  // 只有明确是 Streamable HTTP POST endpoint 不存在/不支持时，才认为需要旧 SSE fallback。
  // 401/403/400/协议校验错误不应该 fallback，否则会掩盖真实问题。
  if (status === 404 || status === 405) return true;

  // 兼容 SDK 只把 HTTP 状态写在 message 里的情况。
  if (/POST/i.test(message) && /(404|405)/.test(message)) return true;

  return false;
}

private createStreamableTransport() {
  return new StreamableHTTPClientTransport(new URL(this.url), {
    requestInit: {
      headers: this.headers
    }
  });
}

private createSSETransport() {
  return new SSEClientTransport(new URL(this.url), {
    requestInit: {
      headers: this.headers
    },
    eventSourceInit: {
      fetch: (url, init) => {
        const mergedHeaders: Record<string, string> = {
          ...this.headers
        };

        if (init?.headers) {
          if (init.headers instanceof Headers) {
            init.headers.forEach((value, key) => {
              mergedHeaders[key] = value;
            });
          } else if (typeof init.headers === 'object') {
            Object.assign(mergedHeaders, init.headers);
          }
        }

        return fetch(url, {
          ...init,
          headers: mergedHeaders
        });
      }
    }
  });
}

private async doConnect(): Promise<Client> {
  const streamableClient = this.createClient();

  try {
    await streamableClient.connect(this.createStreamableTransport());

    this.client = streamableClient;
    return this.client;
  } catch (streamableError) {
    logger.error('StreamableHTTP connect failed', {
      url: this.url,
      error: this.normalizeError(streamableError)
    });

    // 这里是关键：不是所有 StreamableHTTP 错误都 fallback。
    // 只有明确是“不是 Streamable HTTP endpoint”的情况，才尝试旧 SSE。
    if (!this.isLegacySSEFallbackCase(streamableError)) {
      throw streamableError;
    }

    logger.debug('Trying legacy SSE fallback', {
      url: this.url,
      streamableError: this.normalizeError(streamableError)
    });
  }

  const sseClient = this.createClient();

  try {
    await sseClient.connect(this.createSSETransport());

    this.client = sseClient;
    return this.client;
  } catch (sseError) {
    logger.error('Legacy SSE fallback failed', {
      url: this.url,
      error: this.normalizeError(sseError)
    });

    throw sseError;
  }
}

如果要更贴近这个 issue 的场景，我理解核心改动其实是这一句：

if (!this.isLegacySSEFallbackCase(streamableError)) {
  throw streamableError;
}

也就是：不要把所有 StreamableHTTP 异常都 fallback 到 SSE。
只有确认当前 URL 不支持 Streamable HTTP POST 初始化时，才走旧 SSE 兼容逻辑。

这样处理后，POST-only 的 Streamable HTTP MCP endpoint 就不会因为 GET/SSE 405 被错误地带到旧 SSE 链路里；getTools 应该继续走 POST initialize / POST tools/list。

[c121914yu]

我记得官方推荐要 fallback 吧，可以优化报错提示。

[Mrxia7757]

我记得官方推荐要 fallback 吧，可以优化报错提示。

我理解官方确实推荐做 fallback，这点我认同。可能需要区分一下 fallback 的触发条件。

我理解官方推荐的 fallback 是：

先尝试 Streamable HTTP POST initialize；
如果 POST initialize 明确失败，比如返回 404/405，说明服务端可能是旧版 HTTP+SSE；
这时再 fallback 到旧 SSE transport。

但如果已经是 Streamable HTTP endpoint，GET with Accept: text/event-stream 返回 405，应该只表示服务端没有提供可选的 server-to-client stream，不应该因此把整个 Streamable HTTP 判定失败。

所以我觉得这里不是“不应该 fallback”，而是 fallback 判断链路可以更细一点：

1. 先判断 POST initialize 是否成功；
2. 如果 POST initialize 成功，就继续 POST tools/list；
3. 如果 GET/SSE stream 返回 405，只标记为“不支持 server-to-client stream”；
4. 只有 POST initialize 明确返回 404/405，才 fallback 到旧 SSE transport；
5. 如果 fallback 到旧 SSE 后也失败，错误信息里可以同时带上 StreamableHTTP 和 SSE 的错误。

这样既保留官方推荐的旧协议兼容 fallback，也不会把一个 POST-only 的 Streamable HTTP endpoint 错误带到旧 SSE 链路里。

[luanxu-dev]

我也赞同保留 fallback，关键可能是把触发条件和错误记录拆开：先保留 StreamableHTTP connect/POST initialize/tools-list 的原始错误；如果 POST initialize 或 tools/list 明确失败，再用一个新的 client 去尝试旧 SSE；如果只是 GET/SSE stream 返回 405，则只标记这个 endpoint 没有 server-to-client stream，不要覆盖 POST tools/list 已经可用的判断。这样既符合向旧 transport fallback 的兼容目标，也能避免最后只看到 “SSE 405” 而丢掉 StreamableHTTP 主链路到底失败在哪里。