Configure 2+ MCP Servers simultaneously in Claude Desktop and see the power of a multi-tool assistant.
So far, each MCP Server we’ve created does one thing well: manage tasks, query databases, manipulate files, or interact with GitHub. But the real power of MCP emerges when you combine multiple servers simultaneously. Claude Desktop supports multiple MCP Servers running at the same time, and Claude automatically decides which server and tool to use based on the conversation context.
An MCP Server does something very — the single responsibility principle. But when you configure multiple servers in Claude Desktop, they complement each other and create a complete assistant. Claude sees all the tools from all the servers as a unified catalog and automatically chooses the right tool. You don’t need to say "use the GitHub server"—just ask "create an issue," and Claude knows which tool to call. This modular architecture is one of the MCP protocol’s biggest advantages.
Think of each MCP Server as a "skill module" that you add to Claude. A file server = the ability to read/write files. A GitHub server = the ability to interact with repositories. A database server = the ability to query data. The more modules you add, the more capable the assistant becomes — without any module needing to know the others exist.
In practice, advanced Claude Desktop users configure between 3 to 8 MCP Servers simultaneously. Performance is not significantly affected because each server runs as an independent process, and Claude only calls the server it needs when it needs a specific tool. The overhead of having "idle" servers is minimal—they just wait for calls via stdio.
Configuring multiple servers in Claude Desktop is surprisingly simple. Just add multiple entries to the mcpServers from the configuration file. Each server has its own name, command, and arguments, and they don’t interfere with one another.
Configuration example with 3 simultaneous servers:
{
"mcpServers": {
"tarefas": {
"command": "python",
"args": ["servidor_tarefas.py"]
},
"banco": {
"command": "python",
"args": ["servidor_banco.py"]
},
"github": {
"command": "python",
"args": ["servidor_github.py"],
"env": {
"GITHUB_TOKEN": "ghp_seu_token_aqui"
}
}
}
}Each entry has a unique name (tasks, database, GitHub) that identifies the server. Claude Desktop starts all servers automatically when it opens and shuts them down when it closes.
If two servers expose tools with the same name, conflicts and unpredictable behavior can occur. Always use tool names that make the context clear: list_repos (GitHub), list_tasks (tasks), list_files (filesystem). Avoid generic names such as list or create.
When multiple MCP Servers are configured, Claude sees all the tools from all the servers as a unified catalog. It doesn't think in terms of "servers" — it thinks in terms of "available tools." It chooses which tool to use based on the tool description and the context of the user's request. That's why good descriptions are absolutely essential.
Claude sees ALL tools from ALL servers as a flat list. When the user makes a request, Claude analyzes the context and chooses the most suitable tool based on two factors: the tool name and, most importantly, the description (docstring). A tool with a poor description like "does things" will be ignored in favor of one with a clear description like "Lists all the authenticated user's GitHub repositories, including name, language, and stars." Good descriptions = better automatic choices.
Write tool descriptions as if you were explaining them to a a colleague who has never seen your code. Include what the tool does, which parameters it accepts, and what it returns. Instead of """Busca issues.""", write """Busca issues de um repositório GitHub por estado (open/closed) e labels. Retorna número, título, autor e etiquetas.""". The difference in the quality of Claude's choices is dramatic.
In tests with multiple servers, Claude's accuracy when choosing the correct tool is approximately 95%+ when descriptions are detailed and drops to around 70% with vague descriptions. The difference between a good description and a bad one can mean the difference between a reliable assistant and a frustrating one. Invest time in writing high-quality docstrings—they offer the greatest return on investment in MCP development.
Let's look at a concrete example of combining them: the task server (Module 4.1) running alongside the database server (Module 4.2). This combination enables requests that span both domains—for example, "create a task for each product with low stock." Claude uses both servers automatically.
With the servers from tasks e database running simultaneously, Claude can run workflows involving both. For example, when it receives "create a task for each product with less than 10 in stock," Claude first queries the database (the database server tool) to find products with low stock, then creates a task for each one (the tasks server tool). It all happens automatically, in a single conversation, without the user having to orchestrate it manually.
"Create a task for each product with fewer than 10 units in stock."
Claude calls query_database with SQL to find products with inventory < 10. It receives the list: "Pen (5), Notebook (3), Eraser (8)".
Claude calls create_task 3 times: "Restock: Pen (5 units)", "Restock: Notebook (3 units)", "Restock: Eraser (8 units)".
Claude says: "I created 3 restocking tasks for products with low inventory."
The magic happens because each server is independent — the database server doesn't know the task server exists, and vice versa. Claude handles the intelligent orchestration, deciding the order of calls and passing data from one to the other. This is much more flexible than hardcoding the integration between the two systems.
Another powerful example: combine the file server (Module 4.3) with the GitHub server (Module 4.4). This combination enables workflows like “read the local README and create an issue with the TODOs you find”—bringing together access to the local filesystem and actions in the cloud.
With the servers from files e GitHub running together, Claude can read local files and act on GitHub based on the content it finds. Example: "Read the project's README.md and create an issue for each TODO you find." Claude uses the file server to read the README, identifies the TODOs in the text, and uses the GitHub server to create an issue for each one. A local file becomes a cloud action—all automated.
"Read my project's README.md and create issues for any TODOs you find."
Claude calls read_file to read README.md. It identifies 3 TODOs in the content.
Claude calls create_issue 3 times, once for each TODO found, with descriptive titles.
With multiple servers configured, it's time to test scenarios that require collaboration between them. The goal is to verify that Claude moves naturally between servers, choosing the right tool at each step. Test with requests involving 2 or more servers in a single conversation.
Test scenarios that use 2+ servers:
During testing, observe the tool indicator in Claude Desktop—it shows which tool is being called at each step. This helps you check whether Claude is choosing correctly. If it chooses the wrong one, review the tool descriptions. In most cases, a more specific description solves the problem right away.
All servers start without errors when opening Claude Desktop (check logs).
Claude lists all the tools available from all servers (ask "what tools do you have?").
Requests involving 2+ servers are executed correctly, with Claude moving between servers without intervention.
Errors in one server do not affect the operation of the others (resilience).
Next Module: 4.6 — Security Best Practices