Configura 2+ MCP Servers simultáneamente en Claude Desktop y descubre el poder de un asistente con múltiples herramientas.
Hasta ahora, cada MCP Server que creamos hace bien una cosa: administrar tareas, consultar bases de datos, manipular archivos o interactuar con GitHub. Pero el verdadero poder de MCP aparece cuando combinas varios servers simultáneamente. Claude Desktop admite varios MCP Servers ejecutándose al mismo tiempo, y Claude decide automáticamente qué server y qué tool usar según el contexto de la conversación.
Un MCP Server hace algo muy — principio de responsabilidad única. Pero cuando configuras múltiples servers en Claude Desktop, se complementan y crean un asistente completo. Claude ve todas las tools de todos los servers como un catálogo unificado y elige automáticamente la tool correcta. No tienes que decir «usa el server de GitHub»: basta con pedir «crea una issue» y Claude sabe qué tool llamar. Esta arquitectura modular es una de las grandes ventajas del protocolo MCP.
Piensa en cada MCP Server como un "módulo de habilidad" que agregas a Claude. Server de archivos = capacidad de leer/escribir archivos. Server de GitHub = capacidad de interactuar con repositorios. Server de bases de datos = capacidad de consultar datos. Cuantos más módulos agregas, más capaz se vuelve el asistente, sin que ningún módulo necesite saber que los demás existen.
En la práctica, los usuarios avanzados de Claude Desktop configuran entre 3 a 8 MCP Servers simultáneos. El rendimiento no se ve afectado significativamente porque cada server se ejecuta como un proceso independiente, y Claude solo llama al server necesario cuando necesita una tool específica. El costo adicional de tener servers «inactivos» es mínimo: solo esperan llamadas vía stdio.
Configurar varios servers en Claude Desktop es sorprendentemente sencillo. Solo tienes que agregar varias entradas en el objeto mcpServers del archivo de configuración. Cada server tiene su propio nombre, comando y argumentos, y no interfieren entre sí.
Ejemplo de configuración con 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 tiene un nombre único (tareas, base de datos, github) que identifica al server. Claude Desktop inicia todos los servers automáticamente al abrirse y los cierra al cerrarse.
Si dos servers exponen tools con el el mismo nombre, puede haber conflictos y comportamientos impredecibles. Usa siempre nombres de tools que dejen claro el contexto: list_repos (GitHub), list_tasks (tareas), list_files (filesystem). Evita nombres genéricos como list o create.
Cuando hay varios MCP Servers configurados, Claude ve todas las tools de todos los servers como un catálogo unificado. No piensa en "servers", sino en "tools disponibles". Elige qué tool usar según la descripción de la tool y el contexto de la solicitud del usuario. Por eso, las buenas descripciones son absolutamente esenciales.
Claude ve TODAS las tools de TODOS los servers como una lista plana. Cuando el usuario hace una solicitud, Claude analiza el contexto y elige la herramienta más adecuada según dos factores: el nombre de la tool y, sobre todo, la descripción (docstring). Una tool con una descripción deficiente, como «hace cosas», será ignorada en favor de otra con una descripción clara, como «Lista todos los repositorios de GitHub del usuario autenticado, incluidos el nombre, el lenguaje y las estrellas». Buenas descripciones = mejores selecciones automáticas.
Escribe las descripciones de las tools como si se lo explicaras a alguien colega que nunca ha visto tu código. Incluye qué hace la tool, qué parámetros acepta y qué devuelve. En lugar de """Busca issues.""", escribe """Busca issues de um repositório GitHub por estado (open/closed) e labels. Retorna número, título, autor e etiquetas.""". La diferencia en la calidad de las decisiones de Claude es drástica.
En pruebas con múltiples servers, la tasa de aciertos de Claude al elegir la tool correcta es de aproximadamente 95%+ cuando las descripciones son detalladas y baja a cerca de 70% con descripciones vagas. La diferencia entre una buena y una mala descripción puede ser la diferencia entre un asistente confiable y uno frustrante. Dedica tiempo a escribir docstrings de calidad: es la inversión con mayor retorno en el desarrollo MCP.
Veamos un ejemplo concreto de combinación: el server de tareas (Módulo 4.1) funcionando junto con el server de base de datos (Módulo 4.2). Esta combinación permite hacer pedidos que abarcan ambos dominios; por ejemplo, «crea una tarea para cada producto con poco stock». Claude usa ambos servers automáticamente.
Con los servers de tareas e base de datos al ejecutarlos simultáneamente, Claude puede realizar flujos que involucran a ambos. Por ejemplo, al recibir «crea una tarea por cada producto con menos de 10 unidades en stock», Claude primero consulta la base de datos (tool del server de base de datos) para encontrar los productos con poco stock y luego crea una tarea para cada uno (tool del server de tareas). Todo automáticamente, en una sola conversación, sin que el usuario tenga que coordinarlo manualmente.
"Crea una tarea para cada producto con menos de 10 unidades en stock."
Claude llama a query_database con SQL para buscar productos con inventario < 10. Recibe la lista: "Caneta (5), Caderno (3), Borracha (8)".
Claude llama a create_task 3 veces: "Reponer inventario: Caneta (5 un)", "Reponer inventario: Caderno (3 un)", "Reponer inventario: Borracha (8 un)".
Claude dice: "Creé 3 tareas de reposición para los productos con poco inventario."
La magia ocurre porque cada server es independiente — el server de base de datos no sabe que existe el server de tareas, y viceversa. Claude es quien hace la orquestación inteligente, decidiendo el orden de las llamadas y pasando datos de uno al otro. Esto es mucho más flexible que codificar de forma rígida la integración entre ambos sistemas.
Otro ejemplo potente: combinar el server de archivos (Módulo 4.3) con el server de GitHub (Módulo 4.4). Esta combinación permite flujos como «lee el README local y crea una issue con los TODOs encontrados», al unir el acceso al filesystem local con acciones en la nube.
Con los servers de archivos e GitHub al ejecutarlos juntos, Claude puede leer archivos locales y actuar en GitHub según el contenido encontrado. Ejemplo: «Lee el README.md del proyecto y crea una issue por cada TODO que encuentres». Claude usa el server de archivos para leer el README, identifica los TODO en el texto y usa el server de GitHub para crear una issue por cada uno. El archivo local se convierte en una acción en la nube, todo de forma automatizada.
"Lee el README.md de mi proyecto y crea issues para los TODOs que encuentres."
Claude llama a read_file para leer README.md. Identifica 3 TODOs en el contenido.
Claude llama a create_issue 3 veces, una por cada TODO encontrado, con títulos descriptivos.
Con varios servers configurados, es hora de probar escenarios que requieran su colaboración. El objetivo es verificar que Claude pase naturalmente de un server a otro y elija la tool adecuada en cada paso. Prueba con solicitudes que involucren 2 o más servers en una misma conversación.
Escenarios de prueba que usan 2+ servers:
Durante las pruebas, observa el indicador de tools en Claude Desktop: muestra qué tool se está llamando en cada etapa. Esto ayuda a verificar si Claude está eligiendo correctamente. Si se equivoca, revisa las descripciones de las tools. En la mayoría de los casos, una descripción más específica resuelve el problema de inmediato.
Todos los servers se inician sin errores al abrir Claude Desktop (verificar los logs).
Claude muestra todas las tools disponibles de todos los servers (pregunta "¿qué herramientas tienes?").
Las solicitudes que involucran 2+ servidores se ejecutan correctamente, y Claude pasa de un servidor a otro sin intervención.
Los errores en un servidor no afectan el funcionamiento de los demás (resiliencia).
Siguiente Módulo: 4.6 — Buenas prácticas de seguridad