[Bug]: `mavis mcp call` on HTTP/Streamable-HTTP servers fails forever after upstream restart — no auto-reinit, no CLI recovery

[tntstupido]

Version / 版本号

v3.0.47

Platform / 平台

Windows

OS version / 系统版本

Windows 11 Pro 24H2 (build 26200)

Issue area / 问题类型

Other

Upload ID / 日志上传 ID

489342108636860422

What happened? / 问题描述

mavis mcp call permanently fails on HTTP/Streamable-HTTP MCP servers after the upstream restarts. The Mavis client caches the Mcp-Session-Id and never re-runs initialize — there is no CLI verb, no daemon endpoint, and no documented workaround. The only bypass is registering the same endpoint under a different URL form (localhost vs 127.0.0.1).

Steps to reproduce / 复现步骤

1. Add any HTTP MCP server. In my case the upstream is the bundled Unreal Engine 5.8 ModelContextProtocol plugin at http://127.0.0.1:8000/mcp:
   mavis mcp add unreal-mcp '{"type":"http","url":"http://127.0.0.1:8000/mcp"}'
2. Confirm a call works so the session is established:
   echo '{}' | mavis mcp call unreal-mcp list_toolsets --stdin
3. Restart the upstream MCP server. In my case: close and reopen the Unreal Engine 5.8 editor (or any action that invalidates the upstream's session state — Live Coding hot-reload, plugin enable, port change).
4. Repeat the same call:
   echo '{}' | mavis mcp call unreal-mcp list_toolsets --stdin
5. Result (forever): "Error: MCP tool call failed: Streamable HTTP error: Unknown session id '' for 'tools/call'; client should reinitialize". Every subsequent call returns the same dead-session error.
6. mavis mcp sync returns SYNC_ERROR for the affected server. mavis mcp disable unreal-mcp && mavis mcp add unreal-mcp '{...same URL}' does NOT recover (the cache key is the URL, not the server name).
7. Workaround that does work: re-register under a different URL form, e.g. http://localhost:8000/mcp instead of http://127.0.0.1:8000/mcp. The daemon allocates a fresh session slot and calls succeed.

Expected behavior / 预期行为

When the upstream MCP server returns "Unknown session id … client should reinitialize", the Mavis client should drop the cached id and re-issue initialize, then retry the original call once. Per the MCP Streamable-HTTP spec this is the required behavior. Failing that, an explicit mavis mcp session-reset <server> (or equivalent) CLI verb would let the operator recover without URL gymnastics.

Actual behavior / 实际行为

The daemon caches Mcp-Session-Id indefinitely and reuses it on every call. Every call after an upstream restart returns the same dead-session error with no auto recovery. mavis mcp sync does not recover the session. The mcp-cli skill body is silent on this failure mode. Recovery today requires editing the registered URL (different host form or different port) — fragile, undocumented, and unsustainable for any integration whose upstream routinely restarts.

Affected integrations include the Unreal Engine 5.8 MCP plugin (just shipped 2026-06-17), Blender MCP servers (auto-restart on file save), and any stdio→http bridge like mcp-remote whose session TTL expires.

Version: mavis v3.0.47 (Windows 11 Pro 24H2 / build 26200). Upload ID: 489342108636860422.

Logs or crash report / 日志或崩溃信息

$ echo '{}' | mavis mcp call unreal-mcp list_toolsets --stdin
Error: MCP tool call failed: Streamable HTTP error: Error POSTing to endpoint: {
  "jsonrpc": "2.0",
  "id": 4,
  "error": {
    "code": -32600,
    "message": "Unknown session id 'a99e026f4569bc66d69110b80deb5046' for 'tools/call'; client should reinitialize"
  }
}
code: 50205 (mcp error)

# Reproduced verbatim each call after upstream MCP server restart.
# 'mavis mcp disable <srv> && mavis mcp add <srv> <same url>' does NOT recover.
# Recovered only by registering same endpoint under a different URL form
# (localhost vs 127.0.0.1); daemon appears to key session cache by URL.

Screenshots / 截图

No response

Before submitting / 提交前确认

• I have searched existing issues.
• I am using the latest version available to me.
• I have removed sensitive information from logs/screenshots.

[iamagenius00]

Thanks for the detailed write-up and clear repro steps. We’ve tracked this down to stale MCP session handling after an upstream HTTP server restarts. We’re working on a MiniMax Code update that should recover from this automatically, and we’ll follow up here once the fix is available.