Configure 2+ MCP Servers simultâneos no Claude Desktop e veja o poder de um assistente multi-ferramenta.
Até agora, cada MCP Server que criamos faz uma coisa bem: gerenciar tarefas, consultar banco de dados, manipular arquivos ou interagir com o GitHub. Mas o verdadeiro poder do MCP aparece quando você combina múltiplos servers simultaneamente. O Claude Desktop suporta múltiplos MCP Servers rodando ao mesmo tempo, e o Claude decide automaticamente qual server e qual tool usar baseado no contexto da conversa.
Um MCP Server faz uma coisa bem — princípio da responsabilidade única. Mas quando você configura múltiplos servers no Claude Desktop, eles se complementam e criam um assistente completo. O Claude vê todas as tools de todos os servers como um catálogo unificado e escolhe a tool certa automaticamente. Você não precisa dizer "use o server de GitHub" — basta pedir "crie uma issue" e o Claude sabe qual tool chamar. Essa arquitetura modular é um dos grandes diferenciais do protocolo MCP.
Pense em cada MCP Server como um "módulo de habilidade" que você adiciona ao Claude. Server de arquivos = habilidade de ler/escrever arquivos. Server de GitHub = habilidade de interagir com repositórios. Server de banco = habilidade de consultar dados. Quanto mais módulos você adiciona, mais capaz o assistente se torna — sem que nenhum módulo precise saber da existência dos outros.
Na prática, usuários avançados do Claude Desktop configuram entre 3 a 8 MCP Servers simultâneos. A performance não é significativamente afetada porque cada server roda como um processo independente, e o Claude só chama o server necessário quando precisa de uma tool específica. O overhead de ter servers "ociosos" é mínimo — eles apenas aguardam chamadas via stdio.
A configuração de múltiplos servers no Claude Desktop é surpreendentemente simples. Basta adicionar múltiplas entradas no objeto mcpServers do arquivo de configuração. Cada server tem seu próprio nome, comando e argumentos — e eles não interferem uns nos outros.
Exemplo de configuração com 3 servers simultâneos:
{
"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"
}
}
}
}Cada entrada tem um nome único (tarefas, banco, github) que identifica o server. O Claude Desktop inicia todos os servers automaticamente ao abrir e encerra ao fechar.
Se dois servers expõem tools com o mesmo nome, pode haver conflito e comportamento imprevisível. Sempre use nomes de tools que deixem claro o contexto: list_repos (GitHub), list_tasks (tarefas), list_files (filesystem). Evite nomes genéricos como list ou create.
Quando múltiplos MCP Servers estão configurados, o Claude vê todas as tools de todos os servers como um catálogo unificado. Ele não pensa em "servers" — ele pensa em "tools disponíveis". A escolha de qual tool usar é baseada na descrição da tool e no contexto do pedido do usuário. Por isso, boas descrições são absolutamente essenciais.
O Claude vê TODAS as tools de TODOS os servers como uma lista plana. Quando o usuário faz um pedido, o Claude analisa o contexto e escolhe a tool mais adequada baseado em dois fatores: o nome da tool e, principalmente, a descrição (docstring). Uma tool com descrição ruim como "faz coisas" será ignorada em favor de uma com descrição clara como "Lista todos os repositórios do GitHub do usuário autenticado, incluindo nome, linguagem e estrelas". Boas descrições = melhores escolhas automáticas.
Escreva descrições de tools como se estivesse explicando para um colega que nunca viu seu código. Inclua: o que a tool faz, quais parâmetros aceita, e o que retorna. Em vez de """Busca issues.""", escreva """Busca issues de um repositório GitHub por estado (open/closed) e labels. Retorna número, título, autor e etiquetas.""". A diferença na qualidade das escolhas do Claude é dramática.
Em testes com múltiplos servers, a taxa de acerto do Claude na escolha da tool correta é de aproximadamente 95%+ quando as descrições são detalhadas e cai para cerca de 70% com descrições vagas. A diferença entre uma boa e uma má descrição pode ser a diferença entre um assistente confiável e um frustrante. Invista tempo escrevendo docstrings de qualidade — é o maior retorno sobre investimento no desenvolvimento MCP.
Vamos ver um exemplo concreto de combinação: o server de tarefas (Módulo 4.1) rodando junto com o server de banco de dados (Módulo 4.2). Essa combinação permite pedidos que cruzam os dois domínios — por exemplo, "crie uma tarefa para cada produto com estoque baixo". O Claude usa ambos os servers automaticamente.
Com os servers de tarefas e banco rodando simultaneamente, o Claude pode executar fluxos que envolvem ambos. Por exemplo: ao receber "crie uma tarefa para cada produto com estoque abaixo de 10", o Claude primeiro consulta o banco (tool do server banco) para encontrar os produtos com estoque baixo, depois cria uma tarefa para cada um (tool do server tarefas). Tudo automaticamente, em uma única conversa, sem que o usuário precise orquestrar manualmente.
"Crie uma tarefa para cada produto com estoque abaixo de 10 unidades."
Claude chama query_database com SQL para buscar produtos com estoque < 10. Recebe lista: "Caneta (5), Caderno (3), Borracha (8)".
Claude chama create_task 3 vezes: "Repor estoque: Caneta (5 un)", "Repor estoque: Caderno (3 un)", "Repor estoque: Borracha (8 un)".
Claude apresenta: "Criei 3 tarefas de reposição para os produtos com estoque baixo."
A mágica acontece porque cada server é independente — o server de banco não sabe que o server de tarefas existe, e vice-versa. É o Claude que faz a orquestração inteligente, decidindo a ordem de chamadas e passando dados de um para o outro. Isso é muito mais flexível do que hardcodar a integração entre os dois sistemas.
Outro exemplo poderoso: combinar o server de arquivos (Módulo 4.3) com o server do GitHub (Módulo 4.4). Essa combinação permite fluxos como "leia o README local e crie uma issue com os TODOs encontrados" — unindo acesso ao filesystem local com ações na nuvem.
Com os servers de arquivos e GitHub rodando juntos, o Claude pode ler arquivos locais e agir no GitHub com base no conteúdo encontrado. Exemplo: "Leia o README.md do projeto e crie uma issue para cada TODO encontrado." O Claude usa o server de arquivos para ler o README, identifica os TODOs no texto, e usa o server GitHub para criar uma issue para cada um. O arquivo local vira ação na nuvem — tudo automatizado.
"Leia o README.md do meu projeto e crie issues para os TODOs que encontrar."
Claude chama read_file para ler README.md. Identifica 3 TODOs no conteúdo.
Claude chama create_issue 3 vezes, uma para cada TODO encontrado, com títulos descritivos.
Com múltiplos servers configurados, é hora de testar cenários que exigem a colaboração entre eles. O objetivo é verificar que o Claude transita naturalmente entre servers, escolhendo a tool certa em cada etapa. Teste com pedidos que envolvam 2 ou mais servers em uma única conversa.
Cenários de teste que usam 2+ servers:
Durante os testes, observe o indicador de tools no Claude Desktop — ele mostra qual tool está sendo chamada em cada etapa. Isso ajuda a verificar se o Claude está escolhendo corretamente. Se ele errar a escolha, revise as descrições das tools. Na maioria dos casos, uma descrição mais específica resolve o problema imediatamente.
Todos os servers iniciam sem erros ao abrir o Claude Desktop (verificar logs).
O Claude lista todas as tools disponíveis de todos os servers (peça "quais ferramentas você tem?").
Pedidos que envolvem 2+ servers são executados corretamente, com o Claude transitando entre servers sem intervenção.
Erros em um server não afetam o funcionamento dos outros (resiliência).
Próximo Módulo: 4.6 — Boas Práticas de Segurança