Stdio MCP (Oracle SQLcl) dies after parallel reconnect and resource subscribe with Failed to enqueue message

[adiedx-alkami (Adi)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s MCP host repeatedly reconnects and multiplexes background RPC on a stdio MCP server (Oracle SQLcl). That kills the server mid-session with RuntimeException: Failed to enqueue message in StdioServerTransportProvider, then every tool call returns -32000 Connection closed until MCP is restarted.

The same SQLcl binary and the same launcher (sql -mcp via a local wrapper) stay stable under Claude Code on the same machine. The failure correlates with Cursor identifying as cursor-vscode, often double-starting the MCP process within 1–2 seconds, and logging Subscribed to 11 resources before the crash.

This matches known MCP Java stdio concurrency issues (unicast Reactor sink / concurrent sendMessage), and it lines up with existing Cursor reports about parallel reconnect/CreateClient storms and Cursor still sending resources/subscribe even when that is inappropriate for quiet stdio servers.

Steps to Reproduce

1 Configure a stdio MCP server that wraps Oracle SQLcl (sql -mcp). Example: ~/.cursor/mcp.json points oracle-db at a launcher that runs SQLcl MCP.

2 Open Cursor IDE and confirm the server connects (Output → MCP / user-oracle-db).

3 In Agent chat, run a busy Oracle session: connect to a saved connection, several sql_run SELECTs, then DML or a short PL/SQL block, then more SELECTs.

4 Watch the MCP log while Cursor is also doing host-side MCP traffic (resource subscribe, reconnect).

5 Observe paired process starts a second apart, then:
RuntimeException: Failed to enqueue message
at StdioServerTransportProvider$StdioMcpSessionTransport.sendMessage
→ transport_closed
→ Error calling tool ‘sql_run’: MCP error -32000: Connection closed
→ Error calling tool ‘connect’: Not connected

Expected Behavior

One stable stdio MCP child per enabled server for the session.
No parallel reconnect / overlapping CreateClient on the same server.
No overlapping outbound stdio emits that kill the Java unicast sink.
Honor “tools only” usage for fragile stdio servers: do not subscribe to resources (or provide a setting to disable resource subscribe / background multiplexing).
Do not tear down the stdio process while a tools/call response is still in flight.
After a tool error, recover cleanly without requiring a manual MCP restart for every death.

Operating System

MacOS

Version Information

Version: 3.13.21 (Universal)
VS Code Extension API: 1.128.0
Commit: 55434bd8062ece6fee083b82beed2aee42d253f0
Date: 2026-07-27T03:26:14.573Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Agent sessions that reproduced this used Cursor’s agent with MCP tool calls (including Grok / Composer-style agent runs). Model choice does not appear required; the failure is in the MCP host/transport around SQLcl stdio.

Additional Information

Related Cursor forum threads:

Auto-reconnection to MCP servers is STILL broken in 3.0 (runs multiple times in parallel, then fails). on/off works OK

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug See Auto-reconnection to MCP servers is broken (runs multiple times in parallel, then fails). on/off works OK Steps to Reproduce See Auto-reconnection to MCP servers is broken (runs multiple times in parallel, then fails). on/off works OK Expected Behavior Bugs 1st reported over 6 months ago should be fixed by now. Operating System Windows 10/11 Version Information Version: 3.0.13 (system setup) VSCode Version: 1.105.…

MCP resources support

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug Currently, Cursor does not support resources (Example Clients - Model Context Protocol). However, when trying to use a stateless MCP Server that exposes resources, it will still try to subscribe, which, for a stateless server, results in a Missing handler for request type: resources/subscribe error even though subscription is not enabled. '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-…

Upstream MCP Java SDK (same exception class):

Local log fingerprints:

Cursor often starts MCP twice within ~2s, then Subscribed to 11 resources, then enqueue failure.
Companion leak: ORA-17027: Stream has already been closed.
Protocol warning Client requested unsupported protocol version: 2025-11-25 appears for both Cursor and Claude Code; treat as noise, not the kill.
There is no mcp.json / settings toggle to disable resource subscribe or force serial reconnect for stdio servers (chat.mcp.gallery.enabled only).

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[mohitjain (Mohit)]

Hey there,
The fatal Failed to enqueue message comes from SQLcl’s own MCP Java library, not Cursor. But you’re right that Cursor’s stdio double-start / parallel-reconnect and the capability-driven resource subscribes (“Subscribed to 11 resources”) are what trip it. That reconnect pattern on stdio servers is something we’ve seen reported and it’s on our radar, and as you found, there’s no mcp.json or settings toggle to opt out of resource subscribe today.

What helps now:

• Run SQLcl tools-only if it can avoid advertising the resources.subscribe capability. Cursor only subscribes because the server advertises it, so that stops the background RPC from multiplexing with your tool calls.
• After a death, toggle oracle-db off then on to reconnect immediately — a dead stdio server otherwise only retries on a slow timer. Editing mcp.json mid-session also forces a teardown/recreate, so best to avoid that while working.

I’ve logged your two asks (a tools-only opt-out and cleaner auto-recovery). If you get a chance: does running SQLcl tools-only noticeably cut the mid-session deaths? That’d tell us how much is the resource subscribe versus the reconnect race itself