Experiences with many MCP servers active? #1240
-
|
Hi! Super cool work. What does it look like (re: reliability) when Claude has access to like 10-15 different MCP servers? Is that too much? I haven't tried claude's function calling, but I know with GPT, something like 10-20 complicated functions will be extremely unreliable. Is the thinking behind the list tools endpoint to mitigate that? Is it reccomended--or has anyone tried--to "layer" MCP servers (perhaps between different agents)? My thinking with this is having a higher level claude delegate higher level actions (like "research this topic") to lower level claudes (who would have access to search, artifact functionality, maybe act as a moderator in a multi-agent discourse (STORM)). |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
Hi there! This is a great question. These are both valid approaches -- both a "delegate" model, as well as a "give main Claude all the tools" are potentially workable approaches. My recommendation is to first do the simple thing that works. Start off by just adding all the tools to Claude. See how far you can get by continuing to give Claude tools, without resorting to any sort of delegate model. Eventually, you may start to see performance degradations here -- at this point, it would be worth it to make sure the tool descriptions/prompts you have for each tool are good. Ideally, each tool has a few examples showing Claude how to use it, as well as potentially how not to use it. If at this point you are still finding that Claude isn't using tools as you would want, you could look into something like a delegation approach. This is probably going to be more difficult, so I would wait to do this until you have exhausted the ability of the main Claude to handle all the tools. The good news is that if you do get to this point, you would be able to use these tools with the delegate Claude (you won't have wasted effort here). Good luck on this! |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
The "stateful multi-server workflows are a host responsibility" point is where it gets interesting in multi-agent setups specifically. With a single agent using 10-15 MCP servers, the challenges are the practical ones above: context pressure, naming conflicts, latency. With multiple agents, a new problem surfaces: each is connecting to its own server instances with no shared state between them. Agent A learns something useful, Agent B never sees it. Agent A claims a task, Agent B does not know. One approach is a dedicated coordination MCP server that every agent in the fleet connects to alongside its other servers. Rather than each agent having isolated state, they share memory, tasks, and messages through a single server that persists across agent sessions. The tool list stays small (a dozen tools for read/write/search), so the context cost is low. Any agent that can connect to an MCP server participates regardless of which other servers it uses. This is what Artel does: a self-hosted MCP server for fleet coordination. It answers the layering question the OP raised: one of the layers is a shared coordination server sitting alongside each agent's other tool servers. |
Beta Was this translation helpful? Give feedback.
Hi there! This is a great question. These are both valid approaches -- both a "delegate" model, as well as a "give main Claude all the tools" are potentially workable approaches.
My recommendation is to first do the simple thing that works. Start off by just adding all the tools to Claude. See how far you can get by continuing to give Claude tools, without resorting to any sort of delegate model. Eventually, you may start to see performance degradations here -- at this point, it would be worth it to make sure the tool descriptions/prompts you have for each tool are good. Ideally, each tool has a few examples showing Claude how to use it, as well as potentially how not to use it.
If at thi…