hermes - 💡(How to fix) Fix SSE MCP server consistently fails with CancelledError on Cloud Run

Description

An SSE MCP server hosted on Google Cloud Run consistently fails to connect with CancelledError. The server is reachable and functional (confirmed via direct curl), but Hermes' SSE MCP client never completes the handshake.

Environment

• Hermes version: v0.14.0 (2026.5.16)
• OS: WSL (Windows Subsystem for Linux)
• MCP transport: SSE (streamable HTTP)
• Server: Google Cloud Run

Steps to Reproduce

1. Configure an SSE MCP server with URL + Bearer token:

mcp_servers:
  pipeline-hub:
    url: https://pipeline-hub-577792423989.asia-southeast2.run.app/api/mcp
    headers:
      Authorization: "Bearer <token>"

1. Run /reload-mcp or /reset
2. Server does NOT appear in reconnected servers list
3. hermes mcp test pipeline-hub times out with no output

Expected Behavior

SSE MCP server connects successfully and tools are registered.

Actual Behavior

Server never connects. Logs show:

WARNING tools.mcp_tool: Failed to connect to MCP server 'pipeline-hub': CancelledError

This happens every time — 10+ failures in 24 hours.

Diagnostics

Server is healthy

Direct SSE connection works fine:

# SSE handshake returns 200 + session endpoint
curl -s -o /dev/null -w "%{http_code}" \
  "https://pipeline-hub-577792423989.asia-southeast2.run.app/api/mcp" \
  -H "Authorization: Bearer <token>"

# Initialize POST returns 200 + "accepted"
# Tools/list POST returns 200 + "accepted" (results on SSE stream)

Other MCP servers work

In the same session, 8 other MCP servers (including other SSE servers like stitch) connect without issues:

Reconnected servers: github, notebooklm, notion-mcp-server, outlook-calendar, project-hub, stitch, teamhub, whatsapp

Token is correct

Verified multiple times — the Bearer token in config.yaml is the full correct token (confirmed via Python content.replace check).

hermes mcp test hangs

$ hermes mcp test pipeline-hub
# No output, times out after 15s

Possible Causes

• Cold start timing: Cloud Run cold starts may be slower than Hermes' SSE connection timeout
• SSE session ID behavior: Server returns the same session ID on multiple connections (?sessionId=dfaa69b0-...), which might indicate a server quirk
• Async response pattern: Server returns {"result":"accepted"} to POST requests and delivers actual results on the SSE stream — Hermes might not be reading the SSE responses after POST

Workaround

Fall back to direct REST/curl calls to the MCP server, bypassing Hermes' MCP client entirely. Works but loses tool integration.