Llevo meses probando servidores MCP a medida que van apareciendo, y la mayoría acaban desinstalados a la semana. No porque no funcionen, sino porque resuelven un problema que no tengo, o lo resuelven peor que hacerlo a mano sin pasar por un intermediario.

Esto es lo que sí ha sobrevivido al filtro, y por qué el resto no.

El filtro que aplico antes de instalar uno nuevo

Antes de añadir un servidor MCP a mi configuración me hago una pregunta muy simple: ¿esto le da al agente acceso a algo que yo no podría darle explicando el contexto en el prompt? Si la respuesta es no, el servidor añade una capa de indirección que no compensa. Si la respuesta es sí —acceso a un sistema externo con estado, una API con autenticación, una base de datos en vivo— entonces vale la pena.

Los que se quedaron

Los servidores que sobreviven en mi configuración tienen algo en común: dan acceso a algo que cambia constantemente y que sería absurdo copiar y pegar a mano en cada sesión. Un servidor que lee el estado real de un repositorio remoto, uno que consulta una base de datos de desarrollo, y uno que interactúa con el navegador para tareas que de otra forma tendría que hacer yo a golpe de click. En los tres casos, el agente necesita ver algo que cambia entre sesiones, no algo que yo ya sé y puedo escribir en el prompt.

Los que descarté, y por qué

Descarté cualquier servidor que solo empaquetaba una API que ya podía consultar con dos frases de contexto. Un servidor MCP para consultar documentación estática, por ejemplo, no aporta nada frente a simplemente pegar el fragmento relevante en el prompt: añade una dependencia externa, un punto de fallo más, y latencia, a cambio de nada que no tuviera ya.

También descarté los que duplicaban capacidades que el agente ya tiene de forma nativa. Si una herramienta de shell ya me deja hacer algo en dos comandos, un servidor MCP dedicado solo añade una capa extra de configuración que mantener.

Un caso concreto: instalé un servidor MCP para Notion que prometía sincronizar bases de datos enteras con el agente. Lo desinstalé a los diez días porque cada vez que Notion tocaba su API el servidor dejaba de responder durante días, y acabé pasando más tiempo arreglando la integración que el que me ahorraba usándola.

El coste que no se ve al instalar

Cada servidor MCP activo consume contexto en cada llamada a herramientas: el modelo tiene que "ver" qué herramientas tiene disponibles antes de decidir cuál usar. Tener diez servidores activos "por si acaso" no es gratis, aunque no los uses en una sesión concreta. He aprendido a desactivar los que no uso esa semana en vez de dejarlos todos encendidos permanentemente.

La recomendación

No instales un servidor MCP porque existe o porque suena útil en abstracto. Instálalo cuando puedas nombrar el problema exacto que resuelve y ese problema implique acceso a algo con estado que cambia entre sesiones. Todo lo demás es contexto que puedes dar con dos frases bien escritas, sin pagar el coste de mantenimiento de una integración más.

Relacionado: MCP explicado sin humo: qué resuelve y qué no