Cómo elegir MCP servers para tu agente (sin instalar 40 repos)

Abrís un README con 200 MCP servers y te paralizás. ¿Instalás el de Postgres? ¿El que dice “database”? ¿El que tiene más estrellas? Elegir MCP servers para tu agente no es un ejercicio de popularidad — es traducir la intención de tu flujo en tres conexiones concretas: de dónde lee datos, qué acciones ejecuta y cómo notifica resultados.

Empezá por la intención, no por el nombre

Antes de mirar repos, escribí en una oración qué debe hacer el agente. Ejemplo: “Lee tickets de Linear, consulta Postgres para ver si hay bloqueos y avisa por Slack.”

Eso te da tres categorías inmediatas:

• workplace-and-productivity o developer-tools para Linear/issue trackers
• databases para Postgres
• communication para Slack

En Savante no buscás por Ctrl+F. Buscá por intención en el directorio — la búsqueda semántica devuelve MCPs relevantes aunque no mencionen “Linear” en el nombre. Es la diferencia con directorios que solo listan por keyword.

Si tu caso es automatización de browser para testing, la categoría browser-automation tiene decenas de opciones — pero la búsqueda por intención te acerca a Playwright/Puppeteer según tu stack.

Señales de mantenimiento

Un MCP abandonado es peor que no tener MCP: el agente intenta usarlo, falla, reintenta y quema tokens.

Mirá estas señales en cada card del directorio:

Stars y último commit. Miles de stars con commit de hace 6 meses puede ser señal de madurez o de abandono — cruzalo con issues abiertos. Un repo con 200 stars y commit de ayer suele ser más confiable que uno con 5k stars archivado.

Archivado. Si is_archived es true, no lo instales. Punto.

Scope official vs community. Los MCPs “official” (del vendor o del ecosistema MCP) tienen menos sorpresas en schemas y transporte. Los community pueden ser excelentes pero requieren más due diligence.

install_ref confiable. Si el directorio muestra un comando npx o uvx listo para copiar, el onboarding es rápido. Si dice <TODO>, vas a perder tiempo leyendo el README del repo — reservalo para MCPs que no tienen alternativa.

Transporte y lenguaje

stdio es el default para Claude Code y Cursor: un proceso local que habla JSON-RPC por stdin/stdout. Simple, pero cada MCP es un proceso más corriendo en tu máquina.

HTTP+SSE / streamable HTTP sirve para MCPs remotos o compartidos en equipo. Más flexible, pero agrega latencia y autenticación.

Lenguaje del server. TypeScript y Python dominan. Si tu equipo no tiene runtime de Python, un MCP en Python te obliga a tener uv o pip configurado — factor eso en la decisión.

En la card del directorio ves transporte y lenguaje antes de instalar. Filtrá por transporte si sabés que solo vas a usar stdio local.

Cuándo un MCP es overkill

No todo necesita MCP. Si el agente solo lee un CSV local una vez por semana, un script + tool custom puede ser más simple que un MCP server completo.

Un MCP tiene sentido cuando:

• La integración se reutiliza en múltiples agentes o sesiones
• El vendor expone APIs complejas que merecen abstracción (GitHub, Slack, Postgres)
• Querés compartir la config con el equipo via .mcp.json o claude_desktop_config.json

Un MCP es overkill cuando:

• Es una operación única que un script de 20 líneas resuelve
• El repo no tiene mantenimiento y hay alternativa activa en la misma categoría
• Agregar el MCP duplica funcionalidad de otro que ya tenés (dos MCPs de Postgres, por ejemplo)

Checklist antes de instalar

1. ¿Responde a una pieza concreta de mi flujo (datos, acción, notificación)?
2. ¿Último commit < 90 días o justificación clara de estabilidad?
3. ¿Tiene install_ref copiable o documentación clara?
4. ¿No duplica otro MCP ya en mi stack?
5. ¿Probé la búsqueda por intención antes de elegir el primero de la lista?

Con 3–5 MCPs bien elegidos podés cubrir el 80% de flujos internos. La siguiente guía — Tu primer stack MCP — te muestra cómo combinarlos en Claude Code y Cursor paso a paso.

Si preferís que alguien arme el stack por vos, describí tu agente en la banda de síntesis del directorio.