Guía · Intermedio · 11 min
Elegir un servidor MCP: criterios de confianza, mantenimiento, permisos y alojamiento local o remoto
Elija un servidor MCP según su origen, sus permisos y su mantenimiento. Compare el alojamiento local y remoto y revise los accesos antes de conectarlo a su asistente.
Para elegir un servidor MCP, compruebe primero quién lo distribuye, qué acciones puede realizar y cómo se limitarán, supervisarán y revocarán sus accesos. Dé preferencia al servidor que cubra su necesidad con los permisos más limitados, tanto si es local como remoto. La compatibilidad con su asistente y la popularidad del repositorio no bastan para determinar su fiabilidad.
Partir de la tarea y de los accesos necesarios
El protocolo MCP permite que una aplicación cliente utilice funciones ofrecidas por un servidor. Ese servidor puede consultar un servicio, leer documentos o modificar datos. Por tanto, instalarlo añade una capacidad operativa a su asistente: al elegirlo, debe considerar las posibles consecuencias de esa capacidad.
Describa primero la necesidad con un verbo preciso: buscar un procedimiento, consultar solicitudes de soporte o preparar una modificación. Después, indique a qué elementos afecta y qué acciones quedan excluidas. «Consultar las solicitudes del proyecto de soporte, sin publicar comentarios» establece unos límites verificables; «conectar el soporte a la IA» deja demasiadas decisiones implícitas.
Distinga también entre proponer y ejecutar. Un servidor capaz de redactar un borrador no necesita necesariamente permiso para enviarlo. Durante la evaluación, puede bastar con acceder a datos de prueba, aunque el uso final esté previsto en producción.
El directorio de servidores MCP permite localizar candidatos. Prepare para cada uno una ficha breve con el uso previsto, el responsable, el origen, el tipo de alojamiento, los datos accesibles y el procedimiento de retirada. Esa ficha facilita una comparación útil y evita que una integración instalada para una prueba siga conectada sin que nadie se haga cargo de ella.
Comprobar el origen e interpretar las señales de confianza
Empiece por el sitio del servicio correspondiente o por el repositorio de su organización para localizar la integración anunciada. Compruebe después que el repositorio, el paquete descargado y la dirección del servidor remoto se corresponden entre sí. Un nombre parecido, un logotipo o una descripción bien redactada no demuestran esa relación.
El término «oficial» debe tener un significado claro: publicado por el proveedor del servicio, mantenido por la organización del protocolo o simplemente recomendado en una documentación. Cada caso implica responsabilidades distintas. Si se trata de un proyecto comunitario, busque responsables de mantenimiento identificables, una licencia explícita y un canal para notificar vulnerabilidades.
Las estrellas reflejan principalmente la visibilidad de un repositorio. Pueden corresponder a un proyecto más amplio que su integración MCP y no informan directamente sobre el control de permisos. Preste más atención a si los incidentes reciben respuesta, si se explican las correcciones y si se documentan las limitaciones conocidas.
El repositorio asociado a la ficha de servidores de referencia MCP ilustra esta distinción: su documentación presenta estos programas como ejemplos educativos, no como soluciones listas para producción. Así se especifica en el repositorio oficial de servidores de referencia.
Por último, examine cómo se distribuye el software. Las versiones claramente identificadas, el seguimiento de las dependencias y un procedimiento de actualización documentado facilitan el mantenimiento. Ninguna de estas señales constituye por sí sola una certificación de seguridad.
Comparar la ejecución local, el alojamiento propio y el servicio remoto
«Local» indica dónde se ejecuta el programa, pero no todos los destinos con los que se comunica. Un proceso iniciado en su equipo puede llamar a una API externa. A su vez, un servidor remoto puede estar gestionado por su organización dentro de una red privada.
Entre los transportes estándar documentados se encuentran stdio, que conecta el cliente con un subproceso, y Streamable HTTP, que transporta los mensajes mediante HTTP. La elección del alojamiento y la del transporte son decisiones distintas, como explica la especificación de transportes MCP.
| Criterio | Proceso local | Servidor compartido con alojamiento propio | Servicio remoto gestionado |
|---|---|---|---|
| Operación | En el equipo del usuario | A cargo de su organización | A cargo del proveedor |
| Accesos que deben supervisarse | Archivos, entorno y red del equipo | Red interna, cuentas y separación entre usuarios | Cuentas conectadas, datos enviados y conservación |
| Actualizaciones | Deben organizarse en los equipos | El equipo responsable puede centralizarlas | Las aplica el proveedor |
| Dependencia operativa | Disponibilidad y configuración del equipo | Infraestructura y equipo internos | Disponibilidad y condiciones del servicio |
| Retirada | Detener el proceso y revocar los accesos | Desactivar el servicio y las identidades | Desconectar y revocar las autorizaciones |
Elija la ejecución local si necesita acceder a los recursos del equipo y puede administrar ese acceso. Un servidor compartido con alojamiento propio resulta adecuado cuando su organización puede encargarse de la autenticación, las actualizaciones y el aislamiento entre usuarios. Para un servicio remoto gestionado, solicite compromisos documentados sobre el tratamiento de los datos y la continuidad del servicio.
En todos los casos, identifique a la persona que puede intervenir cuando una conexión deja de funcionar o es necesario eliminar un acceso.
Verificar la compatibilidad en el cliente que va a utilizar
La indicación «compatible con MCP» no garantiza que todas las funciones estén disponibles en su aplicación. Compruebe el transporte admitido, el mecanismo de autenticación, las funciones ofrecidas y la compatibilidad declarada entre el cliente y el servidor. Consulte la documentación vigente de ambos, en lugar de apoyarse en un ejemplo antiguo de configuración.
Evalúe, sobre todo, qué controles ofrece la interfaz. Debe poder identificar las herramientas activadas, entender sus parámetros y saber qué operaciones requieren confirmación. Una integración que funciona pero resulta opaca dificulta la supervisión y el diagnóstico de errores.
Compare también las opciones para restringir las capacidades. Algunos servidores ofrecen grupos de herramientas o un modo de solo lectura. El servidor MCP de GitHub, por ejemplo, documenta el filtrado por grupos y por herramientas, además de un modo que desactiva las herramientas de escritura. Estas opciones se detallan en su documentación oficial de configuración.
Compruebe ese filtrado en la configuración que realmente vaya a utilizar. Una opción disponible en el servidor puede no estar accesible desde su cliente o aplicarse de manera diferente según el modo de conexión.
Por último, guarde una lista de las herramientas que aparecen tras establecer la conexión. Le servirá como referencia al actualizar. Para conocer los pasos específicos de cada aplicación, el artículo Instalar un servidor MCP en su asistente complementa este método de selección.
Limitar los permisos en cada nivel
El principio de mínimo privilegio consiste en conceder únicamente los permisos necesarios para la tarea. En un servidor MCP, esto exige revisar varios niveles: las herramientas disponibles para el modelo, las autorizaciones de la cuenta conectada y los permisos del proceso en su entorno.
Ocultar una herramienta en la interfaz no elimina automáticamente los permisos de la cuenta que utiliza. Del mismo modo, una cuenta de solo lectura puede impedir ciertas escrituras aunque una herramienta las ofrezca. Busque restricciones coherentes en cada nivel para que un error de configuración no baste para ampliar todos los accesos.
Para los archivos, utilice preferentemente una carpeta dedicada y permisos adecuados del sistema. Para una base de datos, emplee una identidad limitada a los objetos necesarios. En un servicio de gestión, separe los entornos de prueba y producción cuando exista esa posibilidad.
No confunda una indicación de directorio con un mecanismo de aislamiento. La documentación de roots aclara que orientan al servidor, pero no constituyen un control de acceso; esta función está obsoleta desde la revisión del 28 de julio de 2026. Los detalles figuran en la especificación oficial de roots.
Un servidor local sigue siendo un programa que se ejecuta con permisos. Evite, por tanto, transmitirle todo el entorno del equipo o darle acceso a carpetas ajenas a su función. La guía Proteger un agente de IA desarrolla las medidas de aislamiento y gestión de secretos.
Examinar la autenticación y el recorrido de los datos
La autenticación establece una identidad; la autorización determina qué puede hacer. En un servidor remoto protegido, compruebe cómo obtiene el cliente sus accesos, qué permisos solicita y cómo puede retirarlos el usuario. Una conexión correcta no demuestra que los permisos sean proporcionales a la tarea.
La especificación de autorización MCP describe el mecanismo previsto para los transportes HTTP. Lo diferencia de stdio, donde las credenciales normalmente se obtienen del entorno. No dé por hecho que todos los servidores MCP aplican automáticamente esta especificación: debe comprobar si la admiten.
Antes de proporcionar un secreto, identifique quién lo recibe y dónde se almacena. Dé preferencia a una identidad dedicada a la integración frente a una cuenta de administrador compartida. Compruebe la caducidad, la rotación y la revocación, además del comportamiento del servidor cuando el secreto deja de ser válido.
Siga después el recorrido de un dato: servicio de origen, servidor MCP, cliente, modelo y posibles registros. El servidor puede filtrar un resultado, pero el contenido enviado al cliente puede pasar después a una infraestructura de inferencia remota. Que el conector esté alojado localmente no garantiza, por tanto, la confidencialidad de toda la cadena.
Si interviene un proveedor, pregunte dónde se conservan los resultados, quién puede consultarlos y cómo se eliminan. Si no obtiene esas respuestas, limite la evaluación a datos ficticios. La falta de documentación supone una incertidumbre que debe resolverse antes de conceder acceso a información sensible.
Tratar los resultados como datos no confiables
Un servidor legítimo puede devolver contenido malicioso presente en un documento, una solicitud de soporte o una página web. La confianza en el software no debe extenderse automáticamente a todo lo que lee. Una inyección de prompt busca precisamente hacer pasar contenido externo por una instrucción que debe obedecerse.
Evalúe, por tanto, las combinaciones de capacidades. Una herramienta que lee documentos privados y otra que publica contenido en el exterior pueden abrir una vía de filtración, aunque pertenezcan a servidores distintos. La revisión debe abarcar todas las conexiones disponibles en una misma sesión.
En las operaciones sensibles, la confirmación debe mostrar la acción concreta: destino, datos que se enviarán, objetos que se modificarán y alcance del cambio. Una aprobación general al principio de una tarea no permite revisar una operación cuyos parámetros solo se conocen más adelante.
La documentación de MCP recomienda mostrar las herramientas y permitir que el usuario rechace su ejecución. También aclara que el protocolo no impone una interfaz única. Estos principios figuran en la especificación de herramientas MCP.
La etiqueta «solo lectura» exige la misma cautela: una descripción anuncia un comportamiento, mientras que un permiso restringido lo impone. Compruebe los controles del servidor y del servicio de origen. El artículo Revisar los MCP y las skills antes de instalarlos profundiza en el examen de integraciones y contenidos sospechosos.
Organizar una prueba piloto con criterios de rechazo
Antes de la prueba piloto, prepare una cuenta dedicada, datos ficticios, unos límites de acceso autorizados y una forma de eliminar los objetos creados. Defina el resultado esperado para cada tarea. Así podrá distinguir una interpretación incorrecta del modelo de un problema del servidor o de los permisos.
- Revisar el inventario. Compare las herramientas visibles con las funciones necesarias. Desactive las capacidades ajenas a la tarea.
- Ejecutar una tarea autorizada. Compruebe el resultado en el servicio de origen, además de leer la respuesta del asistente.
- Intentar una operación prohibida. Solicite una escritura o un acceso fuera de los límites permitidos. El sistema debe rechazarlo sin depender únicamente del criterio del modelo.
- Presentar contenido engañoso. Introduzca una instrucción de prueba en un documento ficticio y observe si provoca una acción que no se ha solicitado.
- Revocar el acceso. Compruebe que una nueva operación falla y restablezca después únicamente los permisos necesarios.
Pruebe también qué ocurre si se interrumpe la conexión durante una modificación. Si el cliente pierde la conexión después de enviar una solicitud, la acción puede haberse completado sin que haya llegado su confirmación. Repetirla sin comprobar el estado podría crear un duplicado.
Registre los parámetros relevantes, el resultado observado y las limitaciones de la prueba. Una demostración satisfactoria valida un escenario en una configuración concreta; no garantiza todos los usos futuros. Rechace el paso a producción si las restricciones esenciales siguen sin poder verificarse, si las acciones escapan a la supervisión o si nadie puede revocar los accesos.
Prever el mantenimiento, los incidentes y el costo total
Elegir un servidor implica asumir una carga de mantenimiento. Designe quién seguirá las correcciones, validará los cambios de configuración e intervendrá en caso de incidente. Un repositorio activo no sustituye esa responsabilidad, y una actualización automática también puede cambiar las herramientas disponibles o los permisos solicitados.
Para mantener el control de la instalación, conserve una versión identificable y una configuración reproducible. Prevea después cómo revisar las actualizaciones, probarlas y volver a una configuración conocida. Mantener el software congelado indefinidamente deja que se acumulen los defectos; instalar cada versión sin revisión dificulta identificar el origen de los cambios.
Las buenas prácticas oficiales de seguridad de MCP recogen, entre otros, los riesgos asociados a los servidores locales, los intermediarios de autenticación y los accesos a la red. Utilícelas para preguntar al responsable del mantenimiento qué controles aplica, sin considerar una simple declaración de conformidad como prueba suficiente.
Los registros deben permitir identificar la cuenta utilizada, la herramienta invocada y el resultado de la operación, evitando almacenar innecesariamente secretos o documentos completos. La guía Supervisar un agente de IA en producción detalla cómo organizar este seguimiento.
Por último, compare el costo total: servicio remoto, alojamiento, API utilizadas, llamadas al modelo y tiempo de administración. Mida también el tamaño de los resultados y los reintentos tras los errores. Un servidor sin suscripción puede exigir más trabajo operativo; un servicio gestionado puede reducir esa carga y añadir, al mismo tiempo, una dependencia contractual.
Problemas frecuentes y decisión final
Un servidor conectado que no ofrece herramientas utilizables puede tener un problema de compatibilidad, un filtro activo o permisos insuficientes. Compare la documentación y los registros antes de conceder más permisos. Ampliar los accesos hasta que desaparezca el problema dificulta comprender su causa.
Si una operación parece fallar, compruebe primero el estado del servicio de origen. Un error de transporte no significa necesariamente que la acción se haya cancelado. Para los cambios importantes, exija un procedimiento adecuado de comprobación y recuperación.
Cuando una actualización añada herramientas, revise su utilidad antes de activarlas. Si una integración se vuelve indispensable, pero su mantenimiento sigue siendo incierto, prepare una alternativa o reduzca la responsabilidad que tiene dentro del proceso.
La decisión puede ser aceptado, aceptado con restricciones o rechazado, acompañada de sus motivos y de las condiciones para revisarla. Un impedimento decisivo no debe quedar oculto detrás de una media favorable del resto de los criterios.
Antes de conectar datos reales:
- Se ha comprobado el origen del servidor, del paquete o de la dirección remota.
- La necesidad, el responsable y las acciones excluidas están documentados.
- Los permisos están limitados tanto en el servidor como en el servicio de origen.
- Se conocen el recorrido de los datos y sus condiciones de conservación.
- Se han probado las operaciones prohibidas y la revocación de accesos.
- Las actualizaciones, los incidentes y la retirada tienen un responsable asignado.
La opción adecuada sigue siendo aquella cuyos accesos puede explicar, cuyos límites puede verificar y cuyo mantenimiento puede garantizar durante todo el tiempo que se utilice.
Páginas relacionadas
Preguntas frecuentes
¿Un servidor MCP oficial es siempre seguro?
El origen oficial ayuda a identificar al responsable del software, pero no garantiza que carezca de vulnerabilidades ni que su configuración sea adecuada. Compruebe, sobre todo, qué accesos necesita y cómo se pueden revocar.
¿Se puede utilizar un servidor MCP sin darle una clave API?
Sí, si sus funciones no requieren ningún servicio con autenticación, por ejemplo, para procesar determinados archivos locales. Sin embargo, que no utilice una clave no significa que no tenga permisos: el proceso puede conservar los accesos de la cuenta del sistema con la que se ejecuta.
¿Conviene elegir un servidor MCP local para documentos confidenciales?
La ejecución local puede reducir los intermediarios, pero debe revisar todo el recorrido de los datos. Los fragmentos que recibe el cliente pueden enviarse después a un modelo remoto, aunque el servidor MCP se ejecute en su equipo.
¿Cómo saber si un servidor MCP sigue recibiendo mantenimiento?
Revise las correcciones, las respuestas a los problemas notificados y la compatibilidad documentada, en lugar de fijarse únicamente en la fecha del último commit. Un proyecto estable puede cambiar poco; un repositorio muy activo puede dejar problemas de seguridad sin respuesta.
¿Qué hacer si un servidor MCP solicita más permisos?
Compare los nuevos permisos con las funciones que se hayan añadido y mantenga en suspenso la ampliación de accesos mientras lo comprueba. Si la necesidad no está justificada, conserve los límites anteriores o elija otra integración.