MCP request timed out -> LibreChat turns unavailable

[alexhermida]

I have a few agents an some MCP tools deployed everything working ok.

I was evaluating to deploy a new tool, testing it locally (with Docker) it turns that when I get a time out from the tool the agent is using, in this case due to the size of the response to process I think.

I can see the timeout error response in the chat,

Error processing tool: "my-mcp-tool" tool call failed: MCP error -32001: Request timed out

but immediately after last error message, everything in the UI become unavailable, and the page neither refresh properly or load with any browser, I can't see any error in the inspector neither. The only way to recover the service is to restart the LibreChat container.

In the LibreChat logs I can see:

LibreChat         | 2025-06-18 15:30:28 error: [api/server/controllers/agents/client.js #chatCompletion] Tool Error "my-mcp-tool" tool call failed: MCP error -32001: Request timed out
chat-mongodb      | {"t":{"$date":"2025-06-18T15:31:15.219+00:00"},"s":"I",  "c":"WTCHKPT",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":{"ts_sec":1750260675,"ts_usec":219389,"thread":"1:0xffff79dae6c0","session_name":"WT_SESSION.checkpoint","category":"WT_VERB_CHECKPOINT_PROGRESS","category_id":7,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"saving checkpoint snapshot min: 28, snapshot max: 28 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 106665"}}}
chat-mongodb      | {"t":{"$date":"2025-06-18T15:32:15.249+00:00"},"s":"I",  "c":"WTCHKPT",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":{"ts_sec":1750260735,"ts_usec":248573,"thread":"1:0xffff79dae6c0","session_name":"WT_SESSION.checkpoint","category":"WT_VERB_CHECKPOINT_PROGRESS","category_id":7,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"saving checkpoint snapshot min: 29, snapshot max: 29 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 106665"}}}

I can see new WT_VERB_CHECKPOINT_PROGRESS are coming, restarting mongodb doesn't have any effect, it only works after restarting LibreChat.

I'm wondering best approach to debug this issue as I didn't find anything in the discussions or issues. I'm concerned to deploy it to production if its making the service unavailable.

Thank you for any help!

[danny-avila]

Helpful to see this output:

docker images | grep librechat

Make sure you're on latest version, updating Instructions (docker):
https://www.librechat.ai/docs/local/docker#update-librechat

We resolved some potentially related issues since the last major version of LibreChat (on latest commits).

I'm concerned to deploy it to production if its making the service unavailable.

In production, I would not recommend using a local version of mongodb, which could be what's hanging up everything here. You can rule it out if you use MongoDB Atlas (they have a free plan):
https://www.mongodb.com/cloud/atlas

Also, for MCP specifically, only MCP servers with "Streamable HTTP" transports are recommended for production.

[alexhermida]

Thanks for the quick reply @danny-avila ! Great project and I notice huge effort to support it.

These are the images I have locally:

ghcr.io/danny-avila/librechat-dev                                                                latest                                           3b60221576ab   6 days ago      1.05GB
ghcr.io/virtuos/librechat_exporter                                                               main                                             7e5945ef649a   8 days ago      311MB
ghcr.io/danny-avila/librechat-dev                                                                <none>                                           b74cbb915050   3 weeks ago     1.03GB
ghcr.io/danny-avila/librechat-dev                                                                <none>                                           38aa60620d47   2 months ago    920MB
ghcr.io/danny-avila/librechat-rag-api-dev-lite                                                   latest                                           74bc5dfe8440   2 months ago    1.28GB

I recently updated the version both local with a recent image, and in prod.

In production, I would not recommend using a local version of mongodb, which could be what's hanging up everything here. You can rule it out if you use MongoDB Atlas (they have a free plan):
https://www.mongodb.com/cloud/atlas

Thanks, that makes sense. For us 'production' refers to internal users and is still under evaluation, so not a big deal if we have some occasional issues, but this particular, at least locally, looks persistent and I need to fix it before deployment. I'll definitely consider a more stable DB deployment.

MCP specifically, only MCP servers with "Streamable HTTP" transports are recommended for production.

Yes, we still using SSE as we didn't migrate our internal tools, also I think that during my initial test it wasn't available in LibreChat yet or I had auth issues.

After a bit more debugging I noticed that the service restores without doing anything, after ~19min.

I can see the following error in Librechat at that point:

<--- Last few GCs --->

[25:0xffffb5720000]  5149494 ms: Scavenge 2038.6 (2076.3) -> 2038.6 (2077.3) MB, 3.47 / 0.00 ms  (average mu = 0.223, current mu = 0.202) allocation failure; 
[25:0xffffb5720000]  5149500 ms: Scavenge 2039.6 (2077.3) -> 2039.7 (2082.0) MB, 4.49 / 0.00 ms  (average mu = 0.223, current mu = 0.202) allocation failure; 


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

and I can see some error the following messages in the meilisearch container

2025-06-18T17:36:15.316490Z  INFO HTTP request{method=GET host="meilisearch:7700" route=/health query_parameters= user_agent=node status_code=200}: meilisearch: close time.busy=18.1ms time.idle=1.53ms
2025-06-18T17:37:10.096839Z  INFO HTTP request{method=GET host="meilisearch:7700" route=/indexes/convos/documents/31f68b76-716c-43f0-8392-7e93e9bedc0e query_parameters= user_agent=node status_code=200}: meilisearch: close time.busy=9.43ms time.idle=897µs
2025-06-18T17:37:10.109412Z  INFO HTTP request{method=POST host="meilisearch:7700" route=/indexes/messages/documents query_parameters= user_agent=node status_code=202}: meilisearch: close time.busy=21.8ms time.idle=15.9ms
2025-06-18T17:37:10.319755Z  INFO index_scheduler::batch: document indexing done indexing_result=DocumentAdditionResult { indexed_documents: 1, number_of_documents: 240 } processed_in=204.577128ms
2025-06-18T17:37:10.331311Z  INFO index_scheduler: A batch of tasks was successfully completed with 1 successful tasks and 0 failed tasks.
2025-06-18T17:56:09.301642Z  INFO HTTP request{method=GET host="meilisearch:7700" route=/health query_parameters= user_agent=node status_code=200}: meilisearch: close time.busy=15.6ms time.idle=934µs
2025-06-18T17:56:09.318191Z  INFO HTTP request{method=POST host="meilisearch:7700" route=/indexes query_parameters= user_agent=node status_code=202}: meilisearch: close time.busy=13.0ms time.idle=20.1ms
2025-06-18T17:56:09.323596Z  INFO HTTP request{method=POST host="meilisearch:7700" route=/indexes query_parameters= user_agent=node status_code=202}: meilisearch: close time.busy=12.9ms time.idle=25.6ms
2025-06-18T17:56:09.328783Z ERROR index_scheduler: Batch failed Index `convos` already exists.
2025-06-18T17:56:09.331479Z  INFO HTTP request{method=POST host="meilisearch:7700" route=/indexes query_parameters= user_agent=node status_code=202}: meilisearch: close time.busy=13.3ms time.idle=33.1ms
2025-06-18T17:56:09.332733Z  INFO HTTP request{method=POST host="meilisearch:7700" route=/indexes query_parameters= user_agent=node status_code=202}: meilisearch: close time.busy=13.2ms time.idle=33.6ms
2025-06-18T17:56:09.339297Z ERROR index_scheduler: Batch failed Index `convos` already exists.
2025-06-18T17:56:09.349684Z ERROR index_scheduler: Batch failed Index `messages` already exists.
2025-06-18T17:56:09.351340Z ERROR index_scheduler: Batch failed Index `messages` already exists.
2025-06-18T17:56:09.395136Z  INFO HTTP request{method=GET host="meilisearch:7700" route=/indexes/messages/stats query_parameters= user_agent=node status_code=200}: meilisearch: close time.busy=600µs time.idle=389µs
2025-06-18T17:56:09.397885Z  INFO HTTP request{method=GET host="meilisearch:7700" route=/indexes/convos/stats query_parameters= user_agent=node status_code=200}: meilisearch: close time.busy=41.8µs time.idle=685µs

The first message is the start of a new session, the UI become unresponsive at 2025-06-18T17:37:10.331311Z and came back at 2025-06-18T17:56:09.301642Z. I noticed that when it loads no conversation has been saved, just the initial question.

Definetely looks like a memory problem, not sure why it takes so long to process or trigger the final error/restart. I'll continue debugging, thank you.

[alexhermida]

Hi @danny-avila I finally had some time to debug this properly, I think it might be related to the TypeScript SDK. I've opened an issue modelcontextprotocol/typescript-sdk#771

Thanks for your support!