Couple questions about MCPs

[jamisonbryant]

I was wondering if anyone could explain why the program "inits" all the MCPs in the config file even if they're not actively attached to a session? Here are my reasons for thinking this is the case:

• when I launch agent-deck for the first time on a new day, my GitLab MCP Oauth flow kicks in
• when I'm using agent-deck, I notice that the env0 MCP has spun up its docker container

I didn't ask agent-deck to do either of these things. I haven't even USED the GitLab MCP with agent-deck yet.

Is it expected behavior that it initializes all MCPs in the TOML file, even if they're not actively attached to a session? It's not super annoying if it is, just a bit inefficient for my setup. If not, I can file a bug.

[asheshgoplani]

Hey @jamisonbryant, great question!

What's Happening

This is the MCP Pool feature in action. When you have this in your ~/.agent-deck/config.toml:

[mcp_pool]
enabled = true
pool_all = true

Agent-deck pre-starts all MCPs as socket proxies on launch, so they're ready for instant attachment. The upside is faster MCP switching. The downside is exactly what you're seeing: OAuth flows trigger, Docker containers spin up, etc.

How to Handle It

Option 1: Disable the pool entirely (simplest)

[mcp_pool]
enabled = false

MCPs will only start when you actually attach them to a session (stdio mode). This is the default behavior.

Option 2: Be selective about what gets pooled

[mcp_pool]
enabled = true
pool_all = false
pool_mcps = ["context7", "firecrawl", "exa"]  # Only pool lightweight MCPs

Option 3: Exclude the heavy ones

[mcp_pool]
enabled = true
pool_all = true
exclude_mcps = ["glab", "env0"]  # Skip OAuth/Docker MCPs

My Recommendation

For MCPs with heavy startup costs (OAuth, Docker, external services), I'd go with Option 3 — keep the pool for fast-attaching lightweight MCPs, but exclude the problematic ones.

Hope that helps! Let me know if you have follow-up questions.