v0.8.2: Chat MCP dropdown cannot select external/LAN SSE server (checkbox toggles off, no request sent)

[paulomac1000]

What happened?

What happened

In LibreChat v0.8.2 (Docker), an external/LAN MCP server (SSE transport) shows up in the chat MCP dropdown but cannot be selected: the checkbox checks and immediately unchecks.

Key observation: selecting the internal Docker MCP server works, but selecting the external LAN server results in no HTTP requests in the browser network tab (it gets reverted purely in the frontend state).

Backend logs show that LibreChat successfully initializes both MCP servers and lists tools.

What I expected

I expected the external MCP server checkbox selection to persist (be added to mcpValues) and allow tool calls from the chat UI, similar to the internal Docker MCP server.

Version Information

WARNING: This output is designed for human readability. For machine-readable output, please use --format.
ghcr.io/danny-avila/librechat-dev:latest d6cb4dfdf1ab 2.8GB 599MB U
ghcr.io/danny-avila/librechat:latest 0683d43fb723 2.72GB 595MB

LibreChat reported version (from container logs)

LibreChat backend reports: LibreChat@v0.8.2 backend (seen in docker logs librechat)

Steps to Reproduce

1. Run LibreChat v0.8.2 via Docker Compose.
2. Configure two MCP SSE servers in librechat.yaml:
   • Internal Docker MCP server, e.g. http://mcp-server:8000/sse
   • External LAN MCP server, e.g. http://192.168.0.101:9092/sse
     (also ensure the host/IP is included in mcpSettings.allowedDomains and MCP_ALLOWED_HOSTS).
3. Start the stack and verify backend logs show both servers initialized and tools listed.
4. Open LibreChat UI → start a new chat → open the MCP dropdown in the chat input area.
5. Try selecting the external LAN MCP server:
   • checkbox checks then immediately unchecks
   • browser Network tab shows no request
6. Select the internal Docker MCP server:
   • selection persists
   • a request is sent and selection works

What browsers are you seeing the problem on?

Firefox

Relevant log output

### LibreChat backend logs (during startup)

[MCPServersRegistry] Creating new instance
[MCP][local_lan_mcp] Creating SSE transport: http://192.168.0.101:9092/sse
[MCP][fastmcp_builtin] Creating SSE transport: http://mcp-server:8000/sse
...
[MCP][local_lan_mcp] Tools: ... (125 tools listed)
...
[MCP][fastmcp_builtin] Tools: hello, calculate, current_time, word_count
...
[MCP] Initialized with 2 configured servers and 129 tools.


### UI observations
- Clicking external LAN MCP server checkbox in chat dropdown: checks then immediately unchecks.
- Browser Network tab: no request sent when clicking external server checkbox.
- No JS errors shown in browser console during selection.

Screenshots

Suspected frontend gating (v0.8.2)

In client/src/hooks/MCP/useMCPServerManager.ts (toggleServerSelection), selection only persists when connectionState === "connected":

const serverStatus = connectionStatus?.[serverName];
if (serverStatus?.connectionState === 'connected') {
  setMCPValues([...currentValues, serverName]);
} else {
  initializeServer(serverName);
}

External/LAN server often ends up disconnected/stale (via getServerConnectionStatus() + isStale()), so the UI never calls setMCPValues() for it and the checkbox “bounces”.

Workaround verified on my setup

• Switching LibreChat image to ghcr.io/danny-avila/librechat-dev:latest made the external server selectable in the chat UI.
• Additionally, routing the external MCP server through a Docker-network TCP tunnel using socat improved reliability:

mcp-tunnel:
  image: alpine/socat:latest
  container_name: mcp-tunnel
  command: "TCP-LISTEN:9092,fork,reuseaddr TCP:192.168.0.101:9092"
  networks:
    - llm-network
  restart: unless-stopped

and using MCP URL: http://mcp-tunnel:9092/sse.

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Thanks for the detailed report!

The toggleServerSelection and getServerConnectionStatus code paths are identical between v0.8.2 and dev:latest, as there were no changes to this logic. The dev:latest image appearing to fix it was likely coincidental (fresh container restart, different startup timing).

The root cause is a timing-sensitive staleness check on the backend that can report an actively-connected server as disconnected, causing the frontend toggle to bounce. Your socat tunnel workaround is a solid fix since it keeps the MCP server within the Docker network and avoids the external connectivity instability that may trigger this.

[paulomac1000]

What do you think about changing the logic to avoid situations like that? Maybe parameter for timeouts?