Servidores MCP de terceros: 7 controles antes de adoptarlos

Un servidor MCP de terceros es un proveedor de herramientas en el que tu agente de IA confía por defecto: describe sus propias herramientas, el modelo lee esas descripciones como instrucciones y, si se ejecuta en local, tiene los mismos accesos que tu cuenta. Al final de esta guía tendrás siete controles para cualquier servidor MCP que no hayas escrito tú, una configuración con las versiones fijadas, una huella de la lista de herramientas de cada servidor que te avisa cuando cambia y una allowlist que decide a qué servidores pueden llegar tus agentes.

La oferta es enorme y nadie la revisa. El 2 de noviembre de 2026 contamos el registro oficial de MCP a través de su API pública: 54.599 servidores en su última versión, 53.756 activos y 843 obsoletos. 36.418 indican un endpoint remoto y 21.864 un paquete instalable. El registro comprueba una sola cosa: quién puede publicar con un nombre. Su documentación lo dice claro: se ocupa de autenticar los namespaces y de alojar los metadatos, y deja el análisis del código a npm, PyPI, Docker Hub y a los marketplaces construidos encima. Aparecer en la lista demuestra que quien publica controla una cuenta de GitHub o un dominio. Sobre lo que hace el código, no dice nada.

Ese hueco ya se ha aprovechado. En septiembre de 2025 Koi Security descubrió postmark-mcp, un paquete de npm que copiaba el servidor MCP de Postmark: quince versiones limpias y, en la 1.0.16, una sola línea que enviaba en copia oculta cada correo a una dirección externa. Según The Register, en su última semana publicado se descargó unas 1.500 veces.

Qué necesitas antes de empezar

• La lista de servidores MCP configurados hoy en cada cliente que usa tu equipo: Claude Code, Claude Desktop, Cursor, VS Code, tus propios agentes. Los servidores que nadie ha aprobado son un riesgo en sí mismos; el OWASP MCP Top 10 los llama MCP09, Shadow MCP Servers.
• Para cada agente, los datos a los que llega y las credenciales que tiene.
• Un sitio donde apuntar las decisiones: un archivo en un repositorio o una página por servidor en un registro interno.
• El MCP Inspector, o cualquier cliente que llame a tools/list y muestre la respuesta tal cual.

Paso 1: comprueba quién publicó el servidor

Cada servidor del registro oficial tiene un nombre en formato DNS inverso. Un nombre bajo io.github.username lo publicó quien controla esa cuenta de GitHub. Un nombre como com.example/server pasó una verificación DNS o HTTP en ese dominio. En nuestro recuento, 31.758 entradas están bajo namespaces de GitHub y 22.841 bajo otros dominios.

Comprueba que coincidan tres cosas: el nombre en el registro, el repositorio del código y el identificador del paquete que vas a instalar de verdad. postmark-mcp no pasa este control. Postmark publicaba su servidor desde su propio repositorio de GitHub; el paquete de npm con el mismo nombre era de otra persona. Si existe, elige el servidor que publica el propio proveedor del servicio. Si solo queda uno de la comunidad, lee el historial de commits y quién lo mantiene, y trata un cambio de dueño reciente como un servidor nuevo.

Paso 2: lee cada descripción que leerá el modelo

Las descripciones de las herramientas son texto de prompt. El usuario ve el nombre de la herramienta; el modelo lee la descripción entera. El 1 de abril de 2025 Invariant Labs demostró que unas instrucciones ocultas en una descripción pueden llevar a un agente a sacar datos a través de otro servidor, uno de confianza. OWASP lo llama MCP03, Tool Poisoning.

Conecta el servidor en un entorno desechable, llama a tools/list y lee el JSON en bruto: cada descripción, cada descripción de parámetro, cada valor por defecto. Marca todo lo que se dirija al modelo ("antes de usar esta herramienta", "no se lo digas al usuario"), que nombre otras herramientas u otros servidores, o que pida archivos y secretos que la herramienta no necesita para su trabajo. Después compara las herramientas con lo que el servidor dice que hace. Un servidor del tiempo con una herramienta que lee archivos locales ya te ha dicho lo que es.

Paso 3: decide dónde se ejecuta y aísla los servidores locales

Un servidor remoto se ejecuta en las máquinas de quien lo gestiona y solo llega a lo que le envías y a lo que le permiten sus scopes de OAuth. Un servidor local es otro riesgo. La guía del proyecto MCP sobre seguridad de servidores locales lo describe como un proceso hijo normal: hereda tus variables de entorno y puede leer todo lo que lee tu cuenta, desde las claves SSH hasta las credenciales de la nube. La guía lo deja claro: el transporte stdio no es un sandbox, cliente y servidor comparten el mismo dominio de confianza.

Así que, si el proveedor ofrece un endpoint remoto y tus datos lo permiten, elige ese. Cuando un servidor tiene que ejecutarse en local, mételo en un contenedor o una VM, sin el directorio personal montado, con solo las variables de entorno que necesita y el tráfico de salida limitado a los hosts que debe llamar. Para los servidores remotos, concede los scopes de OAuth más estrechos y revísalos frente a MCP02 de la lista de OWASP, la escalada de privilegios por acumulación de scopes.

Paso 4: fija la versión exacta, nunca latest

Casi todas las instrucciones de instalación dicen npx -y paquete o uvx paquete, sin versión. Así el cliente descarga la última publicada cada vez que arranca, y así una 1.0.15 limpia se convierte en una 1.0.16 con puerta trasera sin que nadie lo decida. Escribe la versión exacta en la configuración del cliente (paquete@1.4.2, o la imagen del contenedor por digest), haz commit del lockfile y, cuando quien publica lo ofrezca, comprueba la procedencia: las provenance statements de npm enlazan un paquete publicado con el commit y la build que lo generaron.

El registro hace su parte. Sus reglas de versionado exigen una cadena de versión única por publicación, congelan los metadatos una vez publicados y rechazan rangos como ^1.2.3. Fijar versiones tiene un coste: las actualizaciones pasan a ser cosa tuya. Dale a cada servidor un responsable y una fecha de revisión. Un servidor remoto, en cambio, no se puede fijar: quien lo gestiona publica cuando quiere. El siguiente paso cubre ese caso.

Paso 5: guarda la huella de las herramientas y vuelve a aprobar si cambia

Un paquete con la versión fijada congela el código que ejecutas. No congela lo que un servidor remoto dice de sí mismo, y el protocolo le deja anunciar nuevas definiciones de herramientas en cualquier momento con notifications/tools/list_changed. Invariant Labs llama rug pull al abuso de este mecanismo: una herramienta aprobada limpia cambia después de la aprobación.

Defenderse cuesta poco. Al aprobar, guarda la respuesta de tools/list, normalízala (claves ordenadas, sin espacios) y apunta su hash SHA-256 junto a la decisión. En cada inicio de sesión, y con cada notificación list_changed, vuelve a calcularlo y compáralo. Si el hash es distinto, el servidor queda bloqueado hasta que una persona lea las diferencias. Casi siempre serán herramientas nuevas e inofensivas. Los pocos casos que no lo son justifican el control.

Paso 6: revisa también los conectores del lado del cliente

El servidor no es tu única dependencia. Los puentes y proxies que conectan un cliente con servidores remotos también se ejecutan en tu máquina. El 9 de julio de 2025 JFrog publicó la CVE-2025-6514 en mcp-remote, un puente muy usado: un servidor malicioso podía responder al paso de autorización con una URL preparada que ejecutaba comandos en la máquina conectada. Puntuación CVSS de 9,6, versiones afectadas de la 0.0.5 a la 0.1.15, corregida en la 0.1.16.

Mete estos paquetes en el mismo inventario que los servidores, fija su versión y suscríbete a sus avisos de seguridad. Un servidor de confianza al que llegas por un puente que nunca actualizaste sigue siendo una puerta abierta.

Paso 7: pásalo por una allowlist, con registros y una salida

El último control convierte los seis anteriores en una norma.

• Una allowlist de servidores y versiones aprobados, la única fuente que leen tus clientes. El registro publica una especificación OpenAPI que los registros privados pueden implementar, así que una lista interna responde con la misma forma que la pública.
• Un gateway que registra cada llamada a herramientas con sus argumentos. Una acción de un agente que no puedes reproducir es una acción que no puedes investigar; OWASP llama a este hueco MCP08, Lack of Audit and Telemetry.
• Credenciales propias para cada servidor, nunca un token de administrador compartido, para que al revocar una las demás sigan funcionando.
• Una salida por escrito: qué líneas de configuración borrar, qué claves rotar, a quién avisar.

El gateway y la auditoría los explicamos en detalle en cómo blindar un servidor MCP para empresas.

Cómo comprobar que funciona

1. Cada servidor configurado en cada cliente aparece en la allowlist con un responsable, una versión fijada y una fecha de revisión.
2. Una configuración con latest, un npx -y sin versión o una etiqueta de imagen sin digest hace fallar tu control de CI.
3. Si cambias un solo carácter en la descripción de una herramienta de un servidor de prueba, queda bloqueado en el siguiente inicio de sesión.
4. Una llamada a herramientas de cualquier agente aparece en el registro del gateway, con sus argumentos, en menos de un minuto.
5. Al revocar las credenciales de un servidor, todos los demás siguen funcionando.

Fallos habituales y cómo resolverlos

• El hash cambia en cada arranque. Algunos servidores generan las descripciones con marcas de tiempo o en orden aleatorio. Normaliza antes de calcular el hash; si el servidor sigue cambiando, avisa a quien lo mantiene o cámbialo por otro.
• Los desarrolladores añaden servidores en local y se saltan la revisión. En los equipos gestionados, haz que la allowlist sea la única configuración que cargan los clientes, y busca archivos de configuración MCP que la lista no conoce.
• El proveedor no tiene endpoint remoto y el servidor local pide acceso amplio a archivos. Monta solo la carpeta con la que trabaja, en solo lectura cuando puedas, y revisa ese servidor más a menudo que los demás.
• Las actualizaciones se acumulan porque, con las versiones fijadas, son manuales. Agrúpalas una vez al mes: lee juntos el changelog y las diferencias en la lista de herramientas, y actualiza.

Para ir más allá

Revisar servidores es una parte de usar MCP en producción. Para entender qué es el protocolo y cuándo un SaaS necesita un servidor propio, lee qué es MCP y por qué tu SaaS necesita un servidor MCP. Si el mismo servidor de terceros nunca pasa la revisión, escribir el tuyo puede salir más barato: lo contamos en build vs buy de servidores MCP. Sobre quién decide cómo cambia el protocolo, mira la gobernanza de MCP en 2026.