Servidores MCP de la comunidad: cuáles merecen la pena

Actualizado: 2026-05-03

Seis meses después de que el Model Context Protocol (MCP) se volviera el protocolo común para conectar agentes con herramientas externas, el catálogo de servidores comunitarios ya ha superado holgadamente el millar. El problema ya no es encontrar un servidor MCP para una tarea concreta, es decidir cuál de los seis que aparecen en la primera página de GitHub merece confianza. Este post recoge los servidores que uso a diario en mi flujo con Claude Desktop y Claude Code, los que instalé y acabé quitando, y los criterios que aplico para separar trigo de paja.

Puntos clave

• Los cinco servidores oficiales de Anthropic que uso a diario son: filesystem, git, Postgres (solo lectura), fetch y memoria.
• Los servidores de Slack, correo y APIs SaaS de amplio alcance presentan superficies de ataque demasiado grandes para el beneficio real que aportan.
• El riesgo de cadena de herramientas (un servidor malicioso que dirige al agente a invocar otro servidor legítimo con argumentos que filtran información) sigue sin estar resuelto en los clientes MCP actuales.
• Cinco criterios antes de instalar cualquier servidor nuevo: procedencia, alcance, trazabilidad, revocabilidad y modelo de actualización.
• No mezclar en la misma sesión servidores oficiales con servidores comunitarios que no conozcas a fondo.

Lo que ha cambiado desde noviembre

Cuando Anthropic anunció MCP a finales de 2024, el protocolo tenía una docena de servidores oficiales y un puñado de experimentos. Seis meses después la pregunta de adopción está contestada: el catálogo crece rápido, hay clientes más allá de Claude Desktop y aparecen integraciones empresariales que asumen MCP como mecanismo por defecto.

La parte que no ha envejecido bien es el gobierno del catálogo. No hay registro central equivalente a npm con revisión mínima. Los servidores viven en repositorios individuales, se instalan con comandos de shell que clonan binarios de terceros, y la única garantía es la reputación del mantenedor. Ese modelo funciona para proyectos maduros y no funciona para novedades con tres días de vida.

Los cinco que uso todos los días

• Servidor MCP de filesystem, mantenido por Anthropic: permite dar al agente acceso acotado a directorios concretos del disco local con permisos controlados. Lo uso para que Claude lea y escriba archivos en un proyecto concreto sin dejarle navegar por el resto del sistema.
• Servidor MCP de git, también oficial: permite al agente leer el estado del repositorio, ver diffs y consultar el historial de commits. En lugar de copiar y pegar salidas de terminal en la conversación, el agente puede pedir la información cuando la necesita.
• Servidor MCP de Postgres, mantenido por Anthropic y centrado en consultas de solo lectura: conecta Claude con una base de datos de desarrollo y permite hacer exploración de esquema sin escribir SQL de cabeza. No lo conectaría a una base de datos de producción.
• Servidor MCP de fetch, básico pero indispensable: permite al agente descargar páginas web y devolverlas en formato markdown procesable. La implementación oficial respeta robots.txt y tiene límites de tamaño razonables.
• Servidor MCP de memoria, también oficial: proporciona una memoria persistente por sesión que el agente puede consultar y actualizar entre conversaciones. Es el único servidor donde tengo cuidado con la privacidad: lo que se guarda puede salir por fuentes no previstas si se mezcla con otros servidores. Este servidor también es la capa de persistencia que alimenta los knowledge graphs para LLM.

Lo que probé y acabé quitando

Probé el servidor MCP de Slack comunitario y lo quité a los pocos días. La funcionalidad era correcta pero el modelo de permisos estaba mal diseñado: una vez conectado, el agente podía leer cualquier canal al que el usuario tuviera acceso, incluidos privados con información sensible. El riesgo de exfiltración accidental por prompt injection indirecta era demasiado alto.

También probé varios servidores de correo electrónico y los retiré todos. El patrón es parecido: la superficie de ataque de un servidor que lee correo y actúa sobre él es enorme, y los servidores comunitarios no tenían revisiones de seguridad que justificaran el riesgo.

El otro grupo que acabé quitando es el de servidores para APIs SaaS con gran alcance. Un servidor que da al agente acceso completo a la API de Stripe o AWS suena útil hasta que uno revisa el código y ve que las credenciales se pasan como variable de entorno sin rotación, sin control fino de permisos y sin registro de auditoría.

Criterios para decidir qué instalar

Con el tiempo he acabado aplicando cinco criterios antes de instalar cualquier servidor MCP nuevo:

1. Procedencia. Servidores oficiales de Anthropic, servidores de organizaciones reconocidas, o repositorios con mantenedor identificable y actividad sostenida. Los repositorios anónimos con poca actividad se descartan directamente.
2. Alcance. Qué hace el servidor y sobre qué. Un servidor que lee un directorio local concreto es muy distinto de uno con permiso de red arbitrario. Aplicar principio de mínimo privilegio aquí ahorra problemas futuros.
3. Trazabilidad. Qué registra el servidor cuando actúa. Un servidor MCP bien hecho registra cada herramienta invocada con argumentos, lo que permite auditar comportamiento después si algo va mal.
4. Revocabilidad. Cómo se quita si decides que no lo quieres. Verificar que la desinstalación es limpia es parte de la evaluación.
5. Modelo de actualización. Cómo te enteras de que hay una actualización de seguridad. Seguir los repositorios con releases puntuales y desconfiar de los que no las publican.

El riesgo que nadie está mirando

Hay un riesgo transversal que no he visto discutido suficiente en la comunidad. Cuando un cliente MCP tiene varios servidores activos en la misma conversación, los servidores comparten contexto implícitamente a través del agente. Un servidor malicioso puede insertar instrucciones en sus respuestas que dirijan al agente a invocar otro servidor legítimo con argumentos que filtran información.

Este ataque de cadena de herramientas es difícil de detectar porque cada servidor individual se comporta correctamente. Lo que falla es la composición. Mitigarlo requiere aislar contextos entre servidores no confiables, algo que los clientes MCP actuales no hacen por defecto.

Mi recomendación mientras esto no esté resuelto: no mezclar en la misma sesión servidores oficiales con servidores comunitarios que no conozcas a fondo.

Mi lectura

El protocolo MCP ha ganado la apuesta de adopción en solo seis meses. Ha conseguido algo similar a lo que OAuth logró en su momento: establecerse como el mecanismo por defecto para integrar agentes con servicios externos.

El problema que queda sin resolver es el modelo de confianza del catálogo comunitario. Npm aprendió por las malas que un registro sin revisión es un vector de ataque de cadena de suministro, y MCP está recorriendo el mismo camino acelerado. Anthropic ha empezado a firmar servidores oficiales y hay conversación sobre un registro formal, pero al ritmo al que crece el catálogo, cada mes de retraso son cientos de servidores nuevos sin marco de verificación.

Mi recomendación práctica a cualquier equipo que esté adoptando MCP: empezar solo por los servidores oficiales y añadir servidores comunitarios uno a uno, con auditoría manual del código, y desinstalarlos si en un mes no aportan valor medible. El catálogo es amplio y tentador, pero la superficie de ataque crece con cada instalación.