Seis meses despues de que el Model Context Protocol (MCP) se volviera el protocolo comun para conectar agentes con herramientas externas, el catalogo de servidores comunitarios ya ha superado holgadamente el millar. El problema ya no es encontrar un servidor MCP para una tarea concreta, es decidir cual de los seis que aparecen en la primera pagina de GitHub merece confianza. Este post recoge los servidores que uso a diario en mi flujo con Claude Desktop y Claude Code, los que instale y acabe quitando, y los criterios que aplico para separar trigo de paja.
Lo que ha cambiado desde noviembre
Cuando Anthropic anuncio MCP a finales de 2024, el protocolo tenia una docena de servidores oficiales y un punado de experimentos. Seis meses despues la pregunta de adopcion esta contestada: el catalogo crece rapido, hay clientes mas alla 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 catalogo. No hay registro central equivalente a npm con revision minima. Los servidores viven en repositorios individuales, se instalan con comandos de shell que clonan binarios de terceros, y la unica garantia es la reputacion del mantenedor. Ese modelo funciona para proyectos maduros y no funciona para novedades con tres dias de vida.
Los cinco que uso todos los dias
El servidor MCP de filesystem, mantenido por Anthropic, es probablemente el mas util. Permite dar al agente acceso acotado a directorios concretos del disco local con permisos controlados. En la practica lo uso para que Claude lea y escriba archivos en un proyecto concreto sin dejarle navegar por el resto del sistema. La implementacion oficial es solida y tiene revisiones publicas.
El servidor MCP de git, tambien oficial, es el segundo que no quito. 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 conversacion, el agente puede pedir la informacion cuando la necesita. El ahorro de tiempo es real y el riesgo es bajo mientras solo se le de acceso de lectura.
El tercer servidor que uso habitualmente es el de Postgres, mantenido tambien por Anthropic y centrado en consultas de solo lectura. Conecta Claude con una base de datos de desarrollo y permite hacer exploracion de esquema sin escribir SQL de cabeza. Los modos de solo lectura funcionan bien porque el servidor rechaza cualquier consulta que no sea SELECT. No lo conectaria a una base de datos de produccion, pero para desarrollo es comodo.
El cuarto es el servidor MCP de fetch, basico pero indispensable. Permite al agente descargar paginas web y devolverlas en formato markdown procesable. Es la puerta de entrada para que el agente consulte documentacion externa sin tener que copiar URLs manualmente. La implementacion oficial respeta robots.txt y tiene limites de tamanio razonables.
El quinto lo dejo para el servidor MCP de memoria, tambien oficial. Proporciona una memoria persistente por sesion que el agente puede consultar y actualizar entre conversaciones. Es util para contexto de proyecto que no quiero repetir cada vez. Es el unico servidor donde tengo cuidado con la privacidad: lo que se guarda se guarda y puede salir por fuentes no previstas si se mezcla con otros servidores.
Lo que probe y acabe quitando
Probe el servidor MCP de Slack comunitario y lo quite a los pocos dias. La funcionalidad era correcta pero el modelo de permisos estaba mal disenado: una vez conectado, el agente podia leer cualquier canal al que el usuario tuviera acceso, incluidos privados con informacion sensible. El riesgo de exfiltracion accidental por prompt injection era demasiado alto para el beneficio real.
Tambien probe varios servidores de correo electronico y los retire todos. El patron es parecido: la superficie de ataque de un servidor que lee correo y actua sobre el es enorme, y los servidores comunitarios no tenian revisiones de seguridad que justificaran el riesgo. Para correo prefiero seguir con copy-paste manual.
El otro grupo que acabe 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 util hasta que uno revisa el codigo y ve que las credenciales se pasan como variable de entorno sin rotacion, sin control fino de permisos y sin registro de auditoria. Para APIs sensibles prefiero esperar a un servidor oficial o escribir uno minimalista yo mismo.
Criterios para decidir que instalar
Con el tiempo he acabado aplicando cinco criterios antes de instalar cualquier servidor MCP nuevo. El primero es la procedencia: servidores oficiales de Anthropic, servidores de organizaciones reconocidas, o repositorios con mantenedor identificable y actividad sostenida. Los repositorios anonimos con poca actividad los descarto directamente.
El segundo es el alcance: que hace el servidor y sobre que. Un servidor que lee un directorio local concreto es muy distinto de un servidor que tiene permiso de red arbitrario. Aplicar principio de minimo privilegio aqui ahorra problemas futuros. Antes de instalar, me aseguro de entender exactamente que permisos concede.
El tercero es la trazabilidad: que registra el servidor cuando actua. Un servidor MCP bien hecho registra cada herramienta invocada con argumentos, lo que permite auditar comportamiento despues si algo va mal. Un servidor que no registra nada es una caja negra inauditable.
El cuarto es la revocabilidad: como se quita si decides que no lo quieres. Esto parece obvio pero muchos servidores comunitarios tienen procesos de instalacion que dejan estados residuales. Verificar que la desinstalacion es limpia es parte de la evaluacion.
El quinto es el modelo de actualizacion: como se entera uno de que hay una actualizacion de seguridad. Pocos servidores comunitarios tienen un canal formal para avisos. Lo que hago en la practica es seguir los repositorios con releases puntuales y desconfiar de los que no las publican.
El riesgo que nadie esta 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 conversacion, los servidores comparten contexto implicitamente a traves del agente. Un servidor malicioso puede insertar instrucciones en sus respuestas que dirijan al agente a invocar otro servidor legitimo con argumentos que filtran informacion.
Este ataque de cadena de herramientas es dificil de detectar porque cada servidor individual se comporta correctamente. Lo que falla es la composicion. Mitigarlo requiere aislar contextos entre servidores no confiables, algo que los clientes MCP actuales no hacen por defecto. Mi recomendacion mientras esto no este resuelto es no mezclar en la misma sesion servidores oficiales con servidores comunitarios que no conozcas a fondo.
Mi lectura
El protocolo MCP ha ganado la apuesta de adopcion en solo seis meses, lo que no es pequenio para una especificacion que no tenia momento previo. Ha conseguido algo que OAuth consiguio en su momento: establecerse como el mecanismo por defecto para integrar agentes con servicios externos, aunque no sea tecnicamente el mejor disenio posible.
El problema que queda sin resolver es el modelo de confianza del catalogo comunitario. Npm aprendio por las malas que un registro sin revision es un vector de ataque de cadena de suministro, y MCP esta recorriendo el mismo camino acelerado. Anthropic ha empezado a firmar servidores oficiales y hay conversacion sobre un registro formal, pero al ritmo al que crece el catalogo, cada mes de retraso son cientos de servidores nuevos sin marco de verificacion.
Mi recomendacion practica a cualquier equipo que este adoptando MCP es empezar solo por los servidores oficiales y anadir servidores comunitarios uno a uno, con auditoria manual del codigo, y desinstalarlos si en un mes no aportan valor medible. El catalogo es amplio y tentador, pero la superficie de ataque crece con cada instalacion.
