Stdio Mcp servers does not close and piles up

[stannumm]

Description:
Every flowise session and every request which uses mcp creates a new server process. These processes do not close and piles up for every request that uses mcp even just refreshing flowise. This also happens with api requests. I've tried with node sdk and python sdk.

async function main() {
    const transport = new StdioServerTransport();
    await server.connect(transport);
    console.error("AppInfo MCP Server running on stdio");
    console.error("MCP env", process.env);
}

main().catch((error) => {
    console.error("Fatal error in main():", error);
    process.exit(1);
});

process.on('SIGINT', async () => {
    process.exit(0);
});

process.on('SIGTERM', async () => {
    process.exit(0);
});

process.stdin.on("close", () => {
    console.error("MCP Server closed");
   server.close();
});

Root Cause:
Flowise does not notifies server that client has gone. I tried to create this flow using sequential agents and added a custom JS function node to send a close message to MCP, but I wasn't able to get it to work.

Expected Behavior:
Each time a request ends, Flowise should close the mcp or sends a signal to close itself.

[toi500]

@HenryHengZJ

Not sure if 100% related to this specific issue of MCP processes not closing correctly, but I wanted to share my observations after getting the Puppeteer MCP tool functional on my test deployment.

Setup:

• Clean Flowise instance, just 1 test flow.
• Using the standard Flowise Alpine Dockerfile (with apk add chromium).
• Puppeteer MCP configured via env variables in the Custom MCP node settings to use /usr/bin/chromium-browser with necessary flags (--no-sandbox, --headless=new, --disable-gpu, cache flags, etc.) and ALLOW_DANGEROUS=true. (This config does allow the tool to function).

{
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-puppeteer"
  ],
  "env": {
    "PUPPETEER_SKIP_DOWNLOAD": "true",
    "PUPPETEER_EXECUTABLE_PATH": "/usr/bin/chromium-browser",
    "PUPPETEER_LAUNCH_OPTIONS": "{\"args\": [\"--no-sandbox\", \"--disable-setuid-sandbox\", \"--disable-gpu\", \"--disable-dev-shm-usage\", \"--headless=new\", \"--disk-cache-size=1\", \"--media-cache-size=1\", \"--aggressive-cache-discard\"]}",

    "ALLOW_DANGEROUS": "true"
  }
}

Observation 1:
After applying this working Puppeteer MCP configuration to a Custom MCP node in a chatflow (even without actively running the flow that uses it), the Flowise container's memory usage jumps significantly and stays consistently high (around 7 GB). This, in turn, causes the host server's memory utilization to hit 100%. This high usage persists even when Flowise should be idle.

Observation 2:
Even after deleting the Custom MCP node from the chatflow configuration in the Flowise UI and saving the flow, the high memory usage (~7000 MB) persisted. A full restart of the Flowise container was required to bring the memory consumption back down to the normal idle baseline (~350 MB).

Note:
The sustained high memory usage (Observation 1) seems excessive for a single idle headless browser. The fact that usage doesn't decrease after removing the MCP node from the configuration (Observation 2) strongly suggests that the MCP server processes (and their corresponding browser instances) launched previously are indeed not being terminated and are leaking, accumulating until the container is restarted. This aligns with the core issue being discussed here regarding MCP process handling.

[HenryHengZJ]

Can any of you guys try this branch? #4375

I've verified that every connection is started and closed correctly

[stannumm]

I've tried this branch with same server config and I did not catch any accumulated process. MCP server tools working fine.

It seems this commit handled the problem unless I missed something.

Thank you.

[toi500]

Definitely, this is improved. After 3 uses, the memory usage goes from 330 to 460 in the first session and stays at that level of usage in any subsequent new MCP use. But I also notice that even if you close or even remove the flow completely, it does not return to the base idle state. You need a manual restart of the container or redeploy to get the base idle state.

The memory increase happens when you initially set the MCP in the flow.

Edit: From a resource management perspective, ideally, when the Custom MCP node is unuse or deleted, Flowise should automatically terminate any background MCP server process associated with that node. A cleanup to prevent unuse processes from consuming memory (130MB+ in my tests) indefinitely, which impacts long-term scalability, especially if flows are frequently modified.

[HenryHengZJ]

From the PR, MCP connection is closed immediately after request, so I'm not sure what else to improve or to do in order to kill that completely. My guess is there is some garbage collector or cache, but I'm not sure. Anyhow it's a big improvement from what it was, we'll see if we are able to get rid of the unused memory later.

Question, do you see a bump in the memory utilisation when you create multiple flows with custom mcp? Or does it stay the same regardless of the flows

[toi500]

My understanding is that closing the connection is happening, but maybe the npx @playwright/mcp... process itself isnt being fully terminated by Flowise after it is no longer needed.

I ran a test with multiple MCPs by duplicating the flow:

1. After restarting the container (baseline memory 330MB), loading the first chatflow with the configured MCP node increased the idle memory usage to 460MB.
2. Loading a second, distinct chatflow that also used the same MCP configuration did not cause a further increase in the baseline memory, it remained stable around 460MB.

So good news.

The main issue I see here is that this initial bump in memory (130MB in my specific test) isnt recovered even if I delete the MCP. This overhead for this Playwright+Browserless setup is small, but I imagine other MCP server implementations could potentially consume much more baseline memory (500MB, 1GB, or whatever) just to stay connected and idle.

[HenryHengZJ]

Just to confirm, deleting the MCP node, readding it, or have multiple same custom MCP nodes doesn't increase the memory usage further?

[toi500]

Correct.
The memory bump (and it cant be recovered unless you restart the container) only happens when you add the MCP to the flow.

But if you add a new MCP (a different one), the memory increases again.

[toi500]

@HenryHengZJ my interpretation based on that last test (where adding a different MCP config did increase memory again) is that Flowise seems to start – leak? – a separate background process for each unique MCP configuration used across the loaded flows.

The total memory overhead then accumulates based on how many different MCP setups are active at any given time.

As a workaround, I guess we could set up a cron job on the host server to restart the Flowise container every N time to clear out these accumulated processes.

Edit: As a note, I will say that the built-in MCP nodes did not add any memory bump in my tests, just when using the custom MCP node.

Edit 2: I have narrowed this down further. Testing your PR locally (via pnpm), the memory management works as expected: memory increases only while the MCP tool is actively running and then drops right back down immediately afterward.

So, my ultimate conclusion is that Flowise could be in a way failing to kill/terminate the background MCP process when running inside the Alpine Linux Docker container environment (installing it via Dockerfile)

The theory:

• Flowise loads the Custom_MCP node.

• Custom_MCP creates an MCPToolkit.

• MCPToolkit creates an StdioClientTransport (from the @modelcontextprotocol/sdk).

• StdioClientTransport spawns the npx child process.

• Nobody tells StdioClientTransport (or MCPToolkit, or Custom_MCP) to clean up or terminate that child process when the node/flow is deleted or becomes inactive.

[HenryHengZJ]

okay thanks for the details findings.

for now we can merge the PR in first, and see what optimization we can do futher on