Servidores MCP para Claude, Cursor y VS Code: qué conectar primero
Una guía práctica de MCP: en qué se diferencia un servidor de una extensión o una clave de API, qué conexiones aportan valor antes y cómo evitar conceder a un agente un acceso excesivo.
MCP aborda un problema poco vistoso pero importante: ofrece a una aplicación de IA una única forma de descubrir herramientas y datos externos. En lugar de crear un adaptador distinto para GitHub, archivos, una base de datos o Slack, un host ejecuta un cliente MCP que habla con un servidor compatible. La arquitectura oficial de MCP separa el host, el cliente y el servidor; un servidor puede exponer herramientas, recursos y prompts. Ese límite importa más que la promesa de “conectarlo todo”, porque ahí es donde se definen el acceso y la responsabilidad.
Un protocolo, tres roles y conexiones separadas
El host es Claude, Cursor, un editor u otra aplicación en la que trabaja el usuario. El host crea un cliente para cada servidor configurado. Cada servidor expone una capacidad específica: leer un directorio permitido, consultar GitHub, ejecutar consultas seguras en una base de datos o controlar un navegador. No es un túnel omnipotente. Varios servidores estrechos son más fáciles de desactivar, inspeccionar y aprovisionar con credenciales separadas.
La documentación de MCP suele usar stdio para una conexión local: el host lanza un proceso e intercambia mensajes por la entrada y la salida estándar. Un servidor remoto utiliza Streamable HTTP. La elección cambia el despliegue y la confianza. Un proceso local hereda el acceso de la máquina actual; un servicio remoto recibe datos por la red y necesita su propia autenticación.
El sistema de archivos y GitHub crean el primer límite útil
Conecta el servidor menos llamativo que elimine una fricción frecuente con un radio de impacto claro. El acceso al sistema de archivos ayuda cuando el host no puede leer un directorio necesario o cuando la raíz debe estar muy restringida. GitHub añade issues, pull requests, checks y repositorios. Para desarrollo, ese par aporta el contexto de la tarea y el lugar donde queda registrado el trabajo.
Empieza con acceso de lectura. Si un servidor puede crear ramas, cerrar issues o fusionar pull requests, habilita esas acciones por separado. Un token que cubre toda una organización es cómodo en una demo y arriesgado en el trabajo diario. Prefiere una identidad dedicada, alcances mínimos y un repositorio de pruebas para el primer ensayo.
Las bases de datos, Slack y Drive necesitan un modelo de confianza más estricto
Un servidor de Postgres puede inspeccionar un esquema, diagnosticar consultas y analizar datos. Sin embargo, el usuario de solo lectura debe imponerse desde la base de datos, no prometerse en un prompt de sistema. Añade límites de tiempo para las sentencias, bloquea esquemas sensibles y conserva un registro de auditoría para el acceso a producción. Slack y Google Drive pueden revelar conversaciones o documentos que el usuario nunca tuvo intención de incluir en la tarea, así que limita espacios de trabajo, canales y carpetas.
Los recursos de MCP son útiles para el contexto; las herramientas son para acciones. Si un trabajo puede resolverse con un recurso de solo lectura, no expongas una herramienta de escritura. Esto es especialmente importante en torno a facturación, CRM, shells remotos e infraestructura.
Browser MCP y PhonePi sirven interfaces, no API masivas
Browser MCP permite a un agente trabajar a través de una página web, mientras que PhonePi MCP extiende un enfoque relacionado a un dispositivo Android. Son útiles para probar interfaces, reproducir el recorrido de un cliente y trabajar con sistemas que no tienen una API adecuada. La automatización de interfaces sigue siendo más lenta y frágil que una API directa, porque cambian los selectores, las sesiones, los diálogos y los permisos.
Usa un puente de navegador o teléfono cuando la propia interfaz importe. Para sincronización masiva, facturación y escrituras críticas, prefiere una API oficial con idempotencia y registros de operaciones.
Un servidor no es una extensión, una clave de API ni una integración terminada
Una extensión añade interfaz de usuario o comportamiento a una aplicación. Una clave de API demuestra quién llama a un servicio. Una integración describe un flujo de trabajo empresarial terminado. Un servidor MCP es un contrato programático mediante el cual un host descubre e invoca capacidades. El servidor puede seguir necesitando una clave de API, OAuth o autorización local. El protocolo no inventa permisos ni garantiza la calidad de la implementación.
Comprueba el editor, el repositorio, las dependencias, la vía de actualización y las herramientas declaradas. Un servidor instalado desde un README cualquiera ejecuta código con privilegios locales. Fija su versión e inspecciona la configuración antes de introducir secretos.
Un conjunto pequeño supera a un catálogo de veinte servidores
Una secuencia razonable para desarrolladores es: archivos locales dentro de una raíz permitida, un repositorio de GitHub y luego un navegador para validación. Añade bases de datos, chats y documentos en la nube solo para un flujo de trabajo recurrente específico. Elimina las conexiones que no aporten valor después de una semana.
Antes de habilitar escrituras, responde a cinco preguntas: qué datos puede ver el servidor, qué acciones puede realizar, dónde se almacenan los secretos, quién confirma las acciones irreversibles y dónde está el registro de auditoría. MCP reduce el coste de integración, pero no elimina el modelo de amenazas. Una buena configuración hace que un agente sea más útil precisamente porque no le concede todo de una vez.