Disabled MCP Servers are still started

[strawgate]

App Version

Latest

API Provider

OpenRouter

Model Used

Any

Actual vs. Expected Behavior

Disabled MCP servers are started anyway

Detailed Steps to Reproduce

1. Add a broken MCP server
2. Disable the MCP server
3. Re-open roo code and see the error from roo trying to start the server

Relevant API Request Output

Additional Context

No response

[dosubot]

There are conditions in the Roo Code that prevent disabled MCP servers from starting. During the "Connection Validation" step, the process checks if the server is disabled and returns an error if it is. Additionally, the documentation mentions that MCP servers can be enabled or disabled using a toggle switch, which supports the mechanism to prevent disabled servers from starting ^[1][2].

If disabled MCP servers are still starting, it might be a bug or an issue with the current implementation. It would be helpful to check the open issues in the repository to see if this problem has been reported or to submit a new bug report if it hasn't been addressed yet.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[strawgate]

They indeed are not visible to the agent but they are still started

[hannesrudolph]

There is one mcp process for all workspaces. If you have one workspace that has MCP's disabled and one that does not, if the MCP's did not start than this would be an issue. This is more a design siutation than a bug. Any ideas on how we could better tackle this?

[strawgate]

I think I understand what you're saying for the overall enabling and disabling of mcp but the behavior I'm seeing is that I disable an individual MCP server in the global MCP config and the server is still started. I would expect disabling an MCP server in the global config would prevent starting the server

[hannesrudolph]

When a server is global, its current activation status is still workspace level until reopened and refreshed from whatever workspace wrote back to the global activation state last. The global is in relation to the settings and not the activation status.

[PrayagS]

I also got hit by this today when I was trying to figure out why memory usage was high. MCP servers were just running even when they were disabled.

Looked into global and project level MCP settings. I expected the following behavior,

• start with a global config that lists all MCP servers with all of them being disabled.
• when I click on edit project level MCP servers, I assumed that it will copy the global config. It instead created a blank file.
• I added one server in the project level config and enabled it. Hoping that it now enable this one server.

I'm now seeing two entries for the same MCP server; one marked as global and one as project level. I'm also seeing two processes running for the same MCP server which seems totally unintentional.

In its current state, I have to maintain a completely blank global file and then add servers individually on a project level. And it also would have been a lot more convenient if this was JSONC and not just JSON; I could just comment out the servers I don't need :P

---

That said, I was wondering if this hierarchical config for MCP servers made sense. Not all MCP servers understand the concept of projects or workspaces. It'll only make it more complex when Roo Code is trying to figure out how to run multiple instances of the same MCP server for different projects opened simultaneously.

I can see a scenario where servers are configured at a project level only. It's then up to the user on how to manage the multiple instances with different configuration for each project.

[strawgate]

Per project MCP servers are basically essential if you're developing an MCP server though

[davibusanello]

• I got into a similar scenario, which @PrayagS described. However, I only use the Global MCP config, but it always has 2 instances of the MCP server running, even if they are disabled.

• I also noticed an issue twice where the MCP kept running even after closing the editor.

From my understanding, it doesn't make sense to have disabled MCPs running, causing unnecessary resource consumption.
For example, I confirmed that this behavior doesn't happen on Cursor->MCP Client/Config, the disabled ones do not run.

[PrayagS]

There is one mcp process for all workspaces. If you have one workspace that has MCP's disabled and one that does not, if the MCP's did not start than this would be an issue. This is more a design siutation than a bug. Any ideas on how we could better tackle this?

@hannesrudolph I was looking at the code (src/services/mcp/McpHub.ts) and had some thoughts.

The language in the code seems to denote that disabled implies that the server's tools are hidden from the LLM and omitted from the system prompt. While this makes sense for global MCP servers, keeping project MCP servers running in a disabled state doesn't.

I think there should be another switch just like disabled which denotes whether the actual process will be kept running or not. I'm not sure of the final UX of such a change but the consequence of updating that config should be that the server's spec is not completely removed from the config file and just a parameter is toggled. That would facilitate easier management of servers since currently the config is just gone when the server is deleted (read shut down).

A simpler alternative is to make this disabled flag work at a tool level rather than the server level (similar to the always allow flag). Then the global disabled flag can control the state of the process rather than its visibility.

---

And given the above behavior, if

• global server/tool is disabled -> agent can't the see the global MCP's tool(s). If a project is specifying the same MCP server, then the agent is free to use that.
• project server/tool is disabled -> agent can't see the project MCP's tool(s). If there's a global instance for this same MCP server, then the agent is free to use that.

The callTool subroutine anyways prioritizes project level MCP tools when no source is specified which will be the default behavior since from what I see, the agent can't exactly specify the source argument.