MCP connection aborts after one minute (timeout is not honored)

[emsi]

What happened?

I have MCP server configured like this:

mcpServers:
  violations:
    type: sse
    url: http://10.1.32.166:3001/sse
    timeout: 900000

My server sends ping (progress update) every 5 seconds and works properly with ClaudeDesktop.
However, despite the timeout set to 10 minutes the tool is aborted exactly after a minute:

LibreChat         | 2025-03-30 20:36:31 info: [MCP][User: 67e85d6db7edeb46584fde99][violations] Establishing new connection
LibreChat         | 2025-03-30 20:36:33 info: [MCP][User: 67e85d6db7edeb46584fde99][violations] Connection successfully established

LibreChat         | 2025-03-30 20:37:31 error: [MCP][User: 67e85d6db7edeb46584fde99][violations][fix_violation] Tool call failed This operation was aborted
LibreChat         | 2025-03-30 20:37:31 error: [api/server/controllers/agents/client.js #sendCompletion] Operation aborted Aborted

The same is true to SSE servers:

LibreChat  | 2025-03-30 22:13:22 info: [MCP][User: 67e85d6db7edeb46584fde99][violations] Creating SSE transport: http://10.1.32.166:3001/sse
LibreChat  | 2025-03-30 22:13:23 info: [MCP][User: 67e85d6db7edeb46584fde99][violations] Connection successfully established

LibreChat  | 2025-03-30 22:14:22 error: [MCP][User: 67e85d6db7edeb46584fde99][violations][fix_violation] Tool call failed This operation was aborted
LibreChat  | 2025-03-30 22:14:22 error: [api/server/controllers/agents/client.js #sendCompletion] Operation aborted Aborted

Version Information

$ docker images | grep librechat
ghcr.io/danny-avila/librechat-dev                         latest                                     2cb7bd98cf9f   26 hours ago    913MB
ghcr.io/danny-avila/librechat-rag-api-dev-lite            latest                                     dd05389daecc   3 days ago      1.31GB

Steps to Reproduce

Create a MCP tool that takes more than 1 minut to finilize.

What browsers are you seeing the problem on?

No response

Relevant log output

Screenshots

No response

Code of Conduct

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

[danny-avila]

The "timeout" is for initial connection when LC starts. If you are experiencing an "abort error" after 60 seconds, it's likely your hosting setup that is cutting the request.

Most hosting setups will by default cut requests after 60 seconds if not fulfilled, and you can confirm this if you are experiencing an "error connecting to server" from the UI side.

If you are in charge of the instance's setup, you can look into how this can be mitigated on the deployment end. The timeout is configurable with NGINX. Some hosting providers won't allow longer timeouts unless you are subscribed to Enterprise plans. There is nothing from the LibreChat configuration you can do to resolve this.

[emsi]

@danny-avila:

1. I'm running both LibreChat and MCP servers on my local infrastructure.
2. There is no hosting setup. I'm using official SDK. There is no nginx nor anything like that.
3. The same setup works flawlessly with Claud Desktop app. The connection does not get aborted.
4. On the MCP server side I see that the LibreChat MCP client is forcibly closing the connection after 1 minute.
5. I'm using report_progress() on the MCP server which is what is needed to maintain the connection alive if the request takes longer.
6. The problem is identical on both SSE and stdio transports.

The bottom line is that LibeMCP side is forcibly aborting the connection after exactly 1 minute.

[danny-avila]

LibreChat MCP client is forcibly closing the connection

LibreChat does not do this by default. If the client disconnects from your instance, it would do this, however. This is necessary in a multi-user context, which Claude Desktop is not.

I'm using an MCP server that takes longer than most (firecrawl with deep research).

I timed the duration of MCP tool invocation to completion here, and it exceeded 60 seconds (from the time you see the purple "running the action" appear to the time you see the checkmark).

And tried to force it to go longer here:

---

If you can point me to specific prompts, LLMs, and MCP servers you are using, I could help troubleshoot the issue, as MCP servers may come with their own handling of timeouts.

However, the fact that it cuts at 60 seconds is usually a very big tell that something is happening between the client <> LC API connection, which would abort all LLM interactions, MCP servers or not. More info about your local infrastructure could also help determine what is going on.

[danny-avila]

For completeness, also tested on using local npm as well as docker (default docker-compose.yml setup):

[emsi]

By "LibreChat" aborting the connection I mean it's the client side. It might be inside MCP client SDK or up the call stack in tools or chat api, etc.
On the server side I see:

asyncio.exceptions.CancelledError                                                                                  
ERROR:    Exception in ASGI application  

which clearly indicates that the client has canceled the connection.

I'll prepare an mcp server that can be used to reproduce it.

[emsi]

I've prepared MCP server that executes command longer but sends progress updates every 5 seconds to keep the connection alive.

To run it you need to install uv. uv is python equivalent to npm. It provides uvx which lets you run python packages off the bat (npx equivalent).

1. Install uv: curl -LsSf https://astral.sh/uv/install.sh | sh
2. Start slow-mcp: uvx --quiet --refresh git+https://github.com/emsi/slow-mcp --transport sse (you can specify --port if you want, the default is 3001).
3. Configure it in librechat.yaml:

mcpServers:
  slow_mcp:
    type: sse
    url: http://<IP ADDR>:3001/sse

This mcp server provides just one command run_command.

If you run the server with --transport stdio then you can run it on the same host as librechat, eliminating the http and network transport. Just make sure to pass all the args to uvx command in the librechat.yaml :)

[emsi]

Hi!

OK, I've nailed it. It's Typescript/JS MCP client bug! (I'm calling it bug because it's starkly different behavior than python's, however it probably can and should be set to a higher value).

I created two clients. Python and Typescript:

https://github.com/emsi/slow-mcp/blob/master/src/client.py
https://github.com/emsi/slow-mcp/blob/master/src/client.mjs

When I run the tests with python client it works as expected:

$ python3 ./src/client.py 
[03/31/25 22:05:22] INFO     Processing request of type ListResourcesRequest                                                                                                                 server.py:534
                    INFO     Processing request of type ListToolsRequest                                                                                                                     server.py:534
Tools: meta=None nextCursor=None tools=[Tool(name='run_command', description='Run command and report progress.', inputSchema={'properties': {'timeout': {'default': 300, 'title': 'Timeout', 'type': 'integer'}}, 'title': 'run_commandArguments', 'type': 'object'})]
                    INFO     Processing request of type CallToolRequest                                                                                                                      server.py:534
Result: meta=None content=[TextContent(type='text', text='1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n24\n25\n26\n27\n28\n29\n30\n31\n32\n33\n34\n35\n36\n37\n38\n39\n40\n41\n42\n43\n44\n45\n46\n47\n48\n49\n50\n51\n52\n53\n54\n55\n56\n57\n58\n59\n60\n61\n62\n63\n64\n65\n66\n67\n68\n69\n70\n71\n72\n73\n74\n75\n76\n77\n78\n79\n80\n81\n82\n83\n84\n85\n86\n87\n88\n89\n90\n91\n92\n93\n94\n95\n96\n97\n98\n99\n100\n101\n102\n103\n104\n105\n106\n107\n108\n109\n110\n111\n112\n113\n114\n115\n116\n117\n118\n119\n120\n121\n122\n123\n124\n125\n', annotations=None)] isError=False

The server just calls the following script that prints number of seconds lapsed:

#!/bin/sh

for sec in $(seq 1 125); do
    sleep 1
    echo "$sec"
done

However the Typescript/JS client times out after EXACTLY 60000 milliseconds:

 node src/client.mjs 
[03/31/25 22:17:03] INFO     Processing request of type ListToolsRequest                                                                                                                     server.py:534
                    INFO     Processing request of type CallToolRequest                                                                                                                      server.py:534
file:///home/emsi/node_modules/@modelcontextprotocol/sdk/dist/esm/shared/protocol.js:282
            const timeoutHandler = () => cancel(new McpError(ErrorCode.RequestTimeout, "Request timed out", { timeout }));
                                                ^

McpError: MCP error -32001: Request timed out
    at Timeout.timeoutHandler (file:///home/emsi/node_modules/@modelcontextprotocol/sdk/dist/esm/shared/protocol.js:282:49)
    at listOnTimeout (node:internal/timers:611:17)
    at process.processTimers (node:internal/timers:546:7) {
  code: -32001,
  data: { timeout: 60000 }
}

Node.js v23.10.0

FYI: I've opened an issue on the typescript-sdk project: modelcontextprotocol/typescript-sdk#245

[danny-avila]

I think it's working as expected, apologies I didn't direct you to adjusting the timeout sooner:

mcpServers:
  slow_mcp:
    type: sse
    url: http://0.0.0.0:3001/sse
    timeout: 300000  # Configure this timeout for long operations

[danny-avila]

with the new setting, it will timeout after the expected time (after 5 minutes)

[emsi]

@danny-avila No it's not. Please read my previous messages and see the test clients.
I have reproducible examples.

Your tests are using server that periodically sends some data and it's a global timeout. The problematic one is on the
request() method.
The python sdk client works as expected while the js one times out.

[danny-avila]

Ok, you're experiencing the network request timeout, which I explained here: #6629 (comment)

this is clear in your logs:

LibreChat | 2025-04-09 14:22:51 error: [MCP][User: 67e85d6db7edeb46584fde99][slow_mcp][run_command] Tool call failed This operation was aborted

The MCP call is tied to the initial request object, which would "abort" if the frontend UI client loses connection to the API backend. It's quite common for NGINX/Cloudflare/ngrok/etc. to limit this to 60 seconds, exactly, severing the connection and causing this "abort" chain.

When this is not a factor, it's no longer experienced as I demonstrate here: #6629 (comment)

I can run the same MCP server/tool for over 60 seconds, and I can make a video of it running for that long if you'd like.

[emsi]

I'm not using cloudflare nor proxies. I'm running the docker locally and accessing it via browser that runs on the same machine - my desktop.

Have you checked my clients that I created to isolate the issue? There's no network connection at play. The client runs the server directly and interfaces with it via stdio. The js client times out while the python one does not.

[danny-avila]

I can confirm it works as the person in the SDK issue mentioned: modelcontextprotocol/typescript-sdk#245 (comment)

You're not passing the necessary RequestOptions (3rd arg) to callTool, which would in turn be passed to the request() method

https://github.com/emsi/slow-mcp/blob/1492ae4a8c13926554a3ed8b2ec6c3d45ad54342/src/client.mjs#L36-L38

SDK reference

https://github.com/modelcontextprotocol/typescript-sdk/blob/0fa46aa2e95e4a53be35b515e11898ebe6e86e58/src/client/index.ts#L405-L410

[emsi]

Without ANY argument it times out after 60 seconds.
Python SDK does NOT timeout.

[danny-avila]

well, they are different frameworks, in JS it requires to be explicitly passed. the python just has a different default behavior 🤷 if you don't want it to timeout, the 3rd arg must be passed in JS