El Model Context Protocol resolvió un problema real. Antes de que existiera un estándar para conectar modelos con sistemas internos, cada integración era código a medida: un adaptador para el repositorio de documentos, otro para el gestor de incidencias, otro para la base de datos. MCP define una forma común de exponer herramientas y recursos a un modelo, y eso redujo semanas de trabajo a una entrada en un archivo de configuración.
Esa misma facilidad es lo que conviene mirar con atención. Habilitar un servidor MCP se parece mucho a instalar una extensión: dos líneas y funciona. Pero lo que se está agregando no es una extensión, es un conjunto de capacidades que el modelo podrá invocar por su cuenta, con las credenciales que le diste y sobre los sistemas que le apuntaste. Cada servidor es una ampliación de la superficie de tu sistema de IA, y merece la revisión que le darías a una dependencia con acceso a producción.
Qué es exactamente lo que se conecta
Un servidor MCP publica, a grandes rasgos, tres cosas: herramientas que el modelo puede ejecutar, recursos que puede leer y plantillas de instrucciones que puede incorporar al contexto. El cliente —la aplicación que hospeda al modelo— descubre ese catálogo al conectar y lo pone a disposición del modelo durante la conversación. El protocolo está en evolución activa, tanto en sus mecanismos de autorización como en la forma de los transportes, así que cualquier control que diseñes debe asumir que las piezas cambiarán.
Hay una distinción práctica que ordena buena parte del análisis: los servidores locales corren como un proceso en la máquina del usuario o del agente, con los permisos de ese proceso; los remotos son un servicio al que el cliente se conecta por red y con el que intercambia credenciales. Los riesgos no son los mismos y no se controlan igual.
La superficie que abre cada servidor
Ejecución con los permisos del entorno
Un servidor local es software de terceros ejecutándose con el usuario que lanzó el cliente. Si ese usuario tiene acceso a claves SSH, tokens en variables de entorno o el directorio completo del proyecto, el servidor también lo tiene, independientemente de las capacidades que declare en su catálogo. La declaración de herramientas describe qué expone al modelo, no qué puede hacer el proceso.
La descripción de las herramientas entra al contexto
Los nombres, descripciones y esquemas de parámetros que publica el servidor se incorporan al contexto del modelo para que sepa cuándo usarlos. Eso significa que un servidor puede influir en el comportamiento del modelo mediante el texto de sus propias descripciones, y también que ese texto puede cambiar entre versiones sin que nadie lo revise. Es un canal de instrucciones que casi nunca aparece en los diagramas de amenaza.
Los resultados vuelven como texto de confianza implícita
Lo que devuelve una herramienta entra al contexto igual que la pregunta del usuario. Si el servidor consulta un sistema donde escriben terceros —tickets, correos, páginas web, comentarios de clientes—, ese contenido llega al modelo sin ninguna marca que lo distinga de las instrucciones legítimas. La superficie no es solo el servidor: es todo lo que el servidor puede traer.
Composición entre servidores
El riesgo interesante aparece con varios servidores conectados a la vez. Uno lee de una fuente externa y otro tiene permiso de escritura o de envío. Por separado ninguno parece peligroso; juntos forman una ruta desde contenido no confiable hasta una acción con efecto real. Esa combinación no la revisa nadie, porque cada servidor se aprobó por separado.
La pregunta no es qué hace este servidor, sino qué camino nuevo abre entre lo que el modelo lee y lo que el modelo puede ejecutar.
Tratar los servidores de terceros como dependencias no confiables
El paralelo correcto es el de una biblioteca de código abierto con permisos de red. No se trata de desconfiar del autor, sino de aplicar la disciplina que ya usas para el resto de tu cadena de suministro. En los proyectos que hacemos, esa disciplina se traduce en cuatro prácticas.
- Origen y versión fijos. Instalar desde un repositorio identificado, fijar la versión y revisar el cambio antes de actualizar. Un servidor que se actualiza solo puede cambiar el conjunto de herramientas disponibles sin aviso.
- Credenciales propias y mínimas. Cada servidor con su token, acotado a las operaciones que necesita y de corta duración. Es el mismo criterio que aplicamos al modelo de permisos de los agentes: la identidad del servidor no es la del usuario que lo configuró.
- Aislamiento del proceso. Contenedor, usuario dedicado, sistema de archivos acotado y salida de red restringida a los destinos que el servidor realmente usa. Sin esto, la revisión del catálogo de herramientas es un ejercicio decorativo.
- Registro de invocaciones. Qué herramienta se llamó, con qué parámetros y qué devolvió. Es la única forma de reconstruir después qué hizo el agente y por qué.
Qué revisar antes de habilitar uno
Antes de aprobar un servidor conviene responder cinco cosas por escrito. Qué herramientas expone y cuáles tienen efectos irreversibles. Contra qué sistemas se autentica y con qué credenciales. Si corre local o remoto, y en el segundo caso a dónde viajan los datos y bajo qué contrato. Qué contenido de terceros puede traer al contexto. Y quién en tu organización es responsable de revisar cada actualización. Si no hay respuesta para la última, el servidor no tiene dueño y terminará siendo parte del inventario de IA en la sombra.
Nada de esto es un argumento contra MCP. El protocolo hace visible y estandarizado algo que antes ocurría igual pero disperso en integraciones a medida, y esa visibilidad es una ventaja para quien quiere gobernar el sistema. El error sería tratar la lista de servidores conectados como configuración y no como arquitectura. Empieza por escribir esa lista —con su propósito, sus credenciales y su dueño— y vas a descubrir que la conversación sobre qué acotar se ordena sola.