Revisa la configuración del cliente MCP antes de confiar en un servidor

Un servidor MCP nuevo merece la misma revisión que harías a un ejecutable nuevo que pide ejecutarse dentro de tu cuenta de desarrollo. El archivo de configuración puede parecer inofensivo porque contiene un comando y algunos argumentos. En la práctica, esa entrada decide qué código se inicia, qué entorno recibe, a qué directorios puede acceder y qué descripciones de herramientas se ofrecerán a un agente.

El error que sigo viendo es tratar «local» como un límite de confianza. No lo es. Un servidor local suele iniciarse con los permisos de tu usuario, puede actuar antes de publicar su primera herramienta y quizá herede credenciales que nadie pretendía compartir. Revisa el contrato de lanzamiento antes de que el cliente se conecte. Después, revisa las acciones anunciadas antes de que el agente pueda llamarlas.

Un servidor local se ejecuta con las consecuencias de tu cuenta

Un servidor MCP local es un proceso hijo, no un objeto de configuración inofensivo. Si tu cliente lo inicia con tu cuenta habitual de macOS, el servidor puede leer archivos de proyectos accesibles, escribir en tu directorio personal, hacer solicitudes de red salientes y consultar las variables de entorno disponibles para ese proceso. MCP no crea una caja de arena para el servidor. El protocolo transporta mensajes, pero no limita lo que hace el ejecutable entre un mensaje y otro.

La diferencia importa cuando un servidor llega mediante un comando de paquetes. Esta configuración:

{
  "command": "npx",
  "args": ["-y", "some-mcp-server"]
}

hace algo más que iniciar un binario local conocido. Pide a un ejecutor de paquetes que resuelva un paquete, instale o reutilice código de su caché y lo inicie. Una máquina limpia, una caché preparada y una etiqueta de paquete modificada pueden producir código diferente. El comando familiar hace que la gente omita la pregunta importante: ¿qué ejecutable exacto se iniciará hoy?

La misma preocupación se aplica a un servidor descargado junto al proyecto. Un repositorio puede contener una implementación honesta de MCP y un hook de instalación, un envoltorio o una dependencia de ejecución maliciosos. Revisa la ruta que inicia el proceso, no solo el archivo fuente cuyo nombre aparece en una guía de configuración.

Usa la cuenta del sistema operativo como primera decisión de contención. Un espacio de trabajo desechable, una cuenta separada con pocos privilegios o una máquina virtual dan a una primera prueba menos acceso que la cuenta que contiene el código fuente de producción y las credenciales de la nube. Eso no sustituye la revisión del código. Limita el daño si se te escapa algo.

El campo command merece una lectura literal

Lee el comando y los argumentos exactamente como los ejecutará el cliente. No los traduzcas mentalmente a la descripción amigable de un README.

La forma más segura usa una ruta fija al ejecutable y una matriz de argumentos:

{
  "command": "/Users/dev/tools/acme-mcp/bin/server",
  "args": ["--config", "/Users/dev/review/acme-mcp.json"],
  "env": {
    "HOME": "/Users/dev/review-home",
    "PATH": "/usr/bin:/bin"
  }
}

Esta forma ofrece puntos concretos de revisión. ¿Existe el ejecutable en esa ruta? ¿Quién es su propietario? ¿El archivo de configuración está fuera de un repositorio que otras personas puedan modificar? ¿El proceso necesita realmente HOME? ¿Necesita de verdad un compilador, un gestor de paquetes o un PATH amplio?

Un envoltorio cambia la revisión. Considera esto:

{
  "command": "sh",
  "args": ["-c", "npx -y acme-mcp --token $SERVICE_TOKEN"]
}

Ahora el shell expande $SERVICE_TOKEN, interpreta la sintaxis del shell y puede ejecutar más cosas que el único programa que esperabas. El ejecutor de paquetes puede descargar código. El servidor recibe un secreto como argumento del comando, que puede aparecer en la inspección de procesos y en los diagnósticos. Cada capa tiene un comportamiento que una ruta directa al ejecutable evita.

No supongas que todos los clientes ejecutan command de la misma forma. Algunos inician procesos directamente con una matriz de argumentos. Otros ofrecen una opción orientada al shell o permiten un script envoltorio. Lee la documentación del cliente y prueba el lanzamiento con un comando sin datos sensibles antes de aprobar uno real. Si el formato permite tanto la ejecución directa como un shell, elige la ejecución directa, salvo que el servidor tenga una necesidad concreta que puedas explicar.

Inspecciona los envoltorios línea por línea. Los scripts pequeños suelen ocultar el comportamiento más arriesgado: descargar una versión, leer un archivo de tokens, cambiar el directorio de trabajo, exportar todas las variables de entorno o reiniciarse silenciosamente mediante otro entorno de ejecución. Un lanzador de veinte líneas puede merecer más atención que la implementación principal del servidor.

El entorno heredado es la filtración de credenciales que muchos pasan por alto

Un bloque env no significa necesariamente «este es todo el entorno». En muchas API de lanzamiento de procesos, el entorno del proceso padre se transmite, salvo que el lanzador lo sustituya deliberadamente. Las entradas de env añaden o reemplazan determinados valores. Tu cliente MCP puede haberse iniciado desde un terminal, un lanzador de escritorio, un editor o un servicio de automatización, y cada ruta puede aportar variables diferentes.

Eso crea una brecha preocupante entre lo que ven los revisores y lo que recibe el servidor. El JSON puede enumerar solo LOG_LEVEL, mientras el proceso recibe también un token de registro de paquetes, un token de control de código fuente, credenciales de la nube, configuración de proxy, detalles del agente SSH y una URL de servicio interno heredada del cliente.

Antes de conectar el servidor, escribe en lenguaje sencillo el contrato del entorno: este proceso necesita este endpoint, este ajuste que no es secreto y quizá una credencial con un alcance muy limitado. Todo lo demás es autoridad accidental.

Una primera prueba útil consiste en iniciar el propio cliente desde un shell reducido. Este comando de macOS y Unix conserva solo unas pocas variables comunes:

env -i HOME="$HOME/review-home" PATH="/usr/bin:/bin" LANG="${LANG:-C}" \
  YOUR_MCP_CLIENT

Sustituye YOUR_MCP_CLIENT por el comando real del cliente. Si el servidor falla, añade una variable cada vez y anota por qué la necesita. No resuelvas el fallo restaurando todo tu entorno de inicio de sesión. Ese atajo ha expuesto más credenciales de las que mucha gente imagina.

También puedes inspeccionar una configuración guardada sin ejecutar ningún comando. El siguiente fragmento de Python imprime los nombres de los servidores, los comandos, los argumentos y los nombres explícitos de las variables de entorno. Deliberadamente no imprime ningún valor del entorno.

python3 - "$HOME/.config/your-client/mcp.json" <<'PY'
import json, sys

with open(sys.argv[1], encoding="utf-8") as f:
    data = json.load(f)

for name, spec in data.get("mcpServers", {}).items():
    print(f"server: {name}")
    print(f"  command: {spec.get('command', '')}")
    print("  args:")
    for arg in spec.get("args", []):
        print(f"    - {arg}")
    print("  explicit env names:")
    for env_name in sorted(spec.get("env", {})):
        print(f"    - {env_name}")
PY

Su salida tiene una forma parecida a esta:

server: issue-tracker
  command: /Users/dev/tools/issue-mcp/server
  args:
    - --read-only
  explicit env names:
    - ISSUE_TRACKER_URL

Si ves nombres como AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, SSH_AUTH_SOCK o SERVICE_TOKEN, detente y pregunta por qué los necesita el servidor. Los valores secretos no se vuelven seguros porque un archivo JSON los contenga en lugar del código fuente. Los archivos de configuración se copian en copias de seguridad, se comparten en solicitudes de soporte, se suben accidentalmente a repositorios y pueden ser leídos por cualquier proceso que tenga acceso al archivo.

Una lista de herramientas es una declaración de capacidades, no un permiso

La especificación del Model Context Protocol define tools/list para descubrir herramientas y tools/call para invocarlas. Esto es útil porque un cliente puede inspeccionar la interfaz propuesta por un servidor antes de que un agente elija una herramienta. No certifica el servidor, sus descripciones ni los efectos de una llamada.

Trata cada herramienta anunciada como una capacidad propuesta. Lee juntos su nombre, descripción, esquema de entrada y anotaciones. Una herramienta llamada search_issues puede hacer una solicitud de solo lectura, o recopilar archivos del proyecto y enviarlos a un tercero antes de buscar. Una herramienta llamada deploy_preview podría crear recursos, modificar DNS o usar una credencial con un alcance mayor de lo que su nombre sugiere.

La especificación de MCP permite que los servidores proporcionen anotaciones que indican su comportamiento, por ejemplo, si una herramienta lee datos, los modifica o interactúa con un sistema externo. Estas indicaciones ayudan al cliente a mostrar una interfaz útil, pero la especificación no las convierte en mecanismos de control. Un servidor deshonesto o descuidado puede etiquetar una herramienta destructiva como de solo lectura. El sistema operativo y las credenciales del servidor no comprobarán esa etiqueta antes de ejecutar una acción.

Registra un inventario pequeño de cada servidor que apruebes:

• El nombre de la herramienta y la acción que afirma realizar.
• Las entradas que pueden contener rutas de archivos, URL, fragmentos de shell o instrucciones de texto libre.
• Los sistemas a los que puede acceder la herramienta y la credencial que utiliza.
• Los efectos secundarios, incluidos los indirectos, como enviar datos a una API remota.
• La versión exacta o revisión del código que revisaste.

Mantén el inventario cerca de la configuración. Una diferencia resulta útil cuando una actualización añade delete_repository, cambia query por execute o incorpora una entrada que acepta una URL arbitraria. Sin un inventario anterior, la gente suele aprobar una lista modificada porque el nombre del servidor sigue pareciendo familiar.

Las descripciones merecen la misma desconfianza que cualquier otro texto no confiable entregado a un agente. Un servidor puede describir una herramienta como obligatoria, afirmar que no hace falta aprobación o indicar al agente que pase secretos sin relación como argumentos. El agente no debe tratar la prosa proporcionada por el servidor como una autoridad superior a la solicitud del usuario y a las reglas de aprobación del cliente.

Las credenciales necesitan un límite fuera del proceso del agente

No entregues un token de API de larga duración ni una clave SSH privada a un servidor solo porque se ejecute en el mismo portátil. En cuanto el proceso del servidor recibe un secreto, puede registrarlo, reenviarlo, escribirlo en disco o exponerlo mediante el resultado de una herramienta. El cliente no puede recuperar ese secreto después de que el proceso lo haya leído.

Separa dos decisiones que los equipos suelen mezclar. El permiso para iniciar un servidor es permiso para ejecutar código. El permiso para usar una credencial de producción es permiso para actuar sobre un sistema externo. Un servidor puede merecer el primer permiso en un espacio de pruebas y no merecer claramente el segundo.

Para un uso de desarrollo sencillo, emite una credencial limitada y de corta duración que solo pueda acceder a datos de prueba. Escribe su alcance. «Usada por el servidor de incidencias» es impreciso; «puede leer incidencias del proyecto de pruebas y no puede crear, comentar ni cambiar membresías» proporciona algo que los revisores pueden comprobar.

Para acciones que necesitan una credencial importante, guarda el secreto en un límite local de credenciales y expón solo la operación concreta. Sallyport aplica este enfoque a las acciones HTTP y SSH: el agente no recibe la clave API ni la clave SSH, mientras la aplicación ejecuta la acción y devuelve el resultado.

Ese límite cambia la gestión del secreto, pero no elimina la necesidad de revisar el servidor. Un servidor malicioso todavía puede pedir a un agente que realice una llamada dañina pero autorizada. Coloca la aprobación donde ocurre la consecuencia, limita las credenciales a la autoridad mínima útil y lee cada solicitud que cruce hacia un sistema importante.

No pases credenciales en los argumentos del comando. Las listas de procesos, los informes de fallos, los diagnósticos y los procesos padre pueden exponerlas. Evita por la misma razón los secretos en texto plano dentro de archivos de configuración. Si una guía de configuración exige un secreto en alguno de esos lugares, averigua si el servidor puede usar un almacén de credenciales del sistema operativo, un token de corta duración o un servicio externo de acciones antes de aceptar ese diseño.

El primer contacto debe ocurrir en una cuenta de prueba sencilla

Ejecuta un servidor desconocido en una cuenta controlada antes de darle un proyecto, un entorno amplio o credenciales reales. Esta prueba responde a una pregunta concreta: ¿qué hace el programa al iniciarse y cuando el cliente le solicita sus herramientas?

Usa un directorio nuevo con archivos inofensivos cuyos nombres hagan evidentes las lecturas inesperadas. Asigna al proceso un HOME temporal. Empieza con un PATH reducido. No montes un directorio lleno de código fuente porque pretendas probar un servidor de control de código. Empieza con un repositorio falso o con una copia sin credenciales.

Observa el comportamiento antes de cualquier llamada a una herramienta. Un servidor que abre una conexión de red, examina tu directorio personal, lee datos del navegador o crea archivos de persistencia al iniciarse ya ha superado lo que requieren la mayoría de los casos de uso de MCP. Algunos servidores comprueban legítimamente un endpoint o cargan una configuración local. Deberían hacer que ese comportamiento sea fácil de explicar y de desactivar.

Después, solicita el inventario de herramientas, inspecciónalo y realiza una llamada inofensiva con una entrada conocida. Registra la solicitud, el resultado, la salida del proceso y los archivos modificados en el directorio de prueba. Si la herramienta devuelve contenido de otro sistema, haz que los datos de prueba sean inconfundibles para saber si accedió al lugar correcto.

Una secuencia básica de revisión es la siguiente:

1. Verifica la ruta del ejecutable, la versión del paquete, la suma de comprobación o revisión del código y cada script lanzador.
2. Inícialo con un entorno reducido en una cuenta de prueba o un espacio de trabajo aislado.
3. Captura el primer resultado de tools/list y compara cada herramienta con el trabajo previsto.
4. Llama a una operación de lectura inofensiva con datos falsos y observa los archivos, procesos hijos y destinos de red.
5. Añade solo las credenciales y el acceso a directorios que requiera el comportamiento confirmado.

No confundas una respuesta correcta con un servidor seguro. Un servidor puede devolver la respuesta esperada mientras copia archivos o usa en otro lugar un token heredado. La prueba te proporciona evidencia, no una garantía. Detecta diseños descuidados y sorpresas evidentes antes de que lleguen al acceso de producción.

La comodidad de los paquetes crea una ruta de actualización que debes controlar

Los gestores de paquetes y los lanzadores de entornos de ejecución hacen que la configuración de MCP sea muy breve. También crean una ruta de actualización. Un rango de versiones, una etiqueta de paquete flotante o un nombre de paquete sin versión pueden cambiar el servidor que se iniciará la semana siguiente sin ninguna diferencia en la configuración.

Fija una versión cuando tu ecosistema lo permita y registra el origen del paquete junto al inventario de herramientas. Mejor aún, usa un artefacto local revisado o un archivo de bloqueo que tu equipo ya compruebe. El objetivo práctico es sencillo: un lanzamiento posterior debe resolver código que puedas identificar.

No permitas que el agente instale su propio servidor MCP como parte de una tarea. Eso combina la adquisición de software, la ejecución y la autorización de herramientas en una sola solicitud conversacional. Una persona debe añadir la configuración del servidor después de revisar el código y su contrato de lanzamiento. Si un flujo de desarrollo necesita muchos servidores, mantén un catálogo revisado en lugar de aceptar fragmentos de configuración de comentarios de incidencias o de la salida de una herramienta.

Las actualizaciones merecen una breve revisión repetida. Compara el ejecutable o el archivo de bloqueo de dependencias, el comando y los argumentos, los nombres explícitos del entorno y el inventario de tools/list. Añadir una herramienta puede no tener importancia. También puede introducir acceso de escritura que la revisión anterior nunca contempló. Lo mismo se aplica cuando un servidor cambia sus credenciales, endpoint o biblioteca de autenticación.

La recomendación popular de «usar siempre el paquete más reciente para obtener correcciones de seguridad» es incompleta para los servidores MCP. Debes instalar pronto las correcciones de seguridad, pero un cambio automático sin revisar puede modificar el código que se ejecuta junto a tus credenciales. Usa un proceso de actualización controlado que te permita inspeccionar el cambio y revertirlo si el nuevo servidor se comporta de forma diferente.

La aprobación debe seguir a la acción, no al nombre del servidor

Una aprobación única para el proceso del servidor responde solo a una pregunta: ¿puede este ejecutable participar en esta sesión? No puede responder de forma segura a todas las preguntas posteriores sobre eliminar una rama remota, enviar datos de clientes o abrir un comando SSH en un host de producción.

Separa el descubrimiento habitual de las acciones con consecuencias. Enumerar proyectos disponibles, leer una incidencia pública y obtener un esquema local suelen requerir menos revisión que modificar registros o enviar datos fuera del equipo. Tu cliente o límite de credenciales debe solicitar una nueva aprobación humana cuando una llamada cruza esa línea. Si cada llamada de lectura exige atención, la gente hará clic sin leer. Si un solo clic al iniciar concede acceso ilimitado a producción, tarde o temprano alguien se arrepentirá.

La identidad del proceso también importa. Un aviso de aprobación debe indicar qué proceso firmado solicitó el acceso, no mostrar simplemente una etiqueta elegida por el servidor. Cualquier programa puede copiar una etiqueta como database-helper. La ruta del ejecutable, la identidad de firma cuando esté disponible y los argumentos de lanzamiento ofrecen una superficie de revisión mejor.

Conserva un registro en dos niveles: la sesión del agente que solicitó el trabajo y la acción individual que utilizó una credencial o accedió a un servicio externo. Necesitas el registro de sesión para investigar por qué un agente tenía autoridad. Necesitas el registro de la acción para investigar qué cambió realmente. Un solo registro no puede responder bien a ambas preguntas si omite al solicitante o la solicitud exacta.

Un registro resistente a manipulaciones ayuda cuando el servidor, el cliente o el operador discuten después lo ocurrido. No hace segura una acción peligrosa en el momento de aprobarla. Lee el destino, el método, el comando y los parámetros relevantes antes de autorizar una acción difícil de deshacer.

Un servidor rechazado necesita limpieza, no solo eliminación

Si decides que un servidor no es confiable después de conectarlo, elimina de inmediato su entrada del cliente, pero no te detengas ahí. El proceso puede haber escrito archivos, modificado la configuración del shell, creado tareas programadas, cambiado un hook del repositorio o copiado credenciales mientras se ejecutaba.

Conserva las pruebas antes de borrarlo todo. Guarda la configuración, la versión del paquete o revisión del código, la salida del proceso y los registros de acciones. Después inspecciona el HOME de prueba, el directorio de trabajo del servidor, la caché de paquetes, los archivos de inicio del shell, los agentes de lanzamiento, los hooks del repositorio y cualquier directorio en el que el servidor pudiera escribir. Comprueba los procesos activos y las conexiones de red recientes mientras las pruebas sigan disponibles.

Rota todos los secretos que el proceso pudiera haber leído, no solo el secreto que le proporcionaste intencionadamente. Eso incluye tokens heredados, acceso al agente SSH, credenciales de paquetes y sesiones de desarrollo respaldadas por el navegador cuando corresponda. Eliminar una línea de un archivo de configuración no revoca un token que ya se haya copiado.

Después, refuerza el proceso de revisión que permitió la conexión. Si el fallo procedía de un entorno heredado, usa un lanzador reducido. Si se debía a una actualización inesperada del paquete, fija y revisa los artefactos. Si lo causó una descripción engañosa de una herramienta, exige un inventario capturado antes de aprobarla. El resultado útil es un control modificado, no una promesa vaga de tener más cuidado la próxima vez.

Un servidor MCP nuevo obtiene acceso en su momento más peligroso, antes de haber ganado confianza. Haz que su comando sea literal, que su entorno sea pequeño, que su lista de herramientas se inspeccione y que sus credenciales estén separadas del agente. Ese es el momento en que todavía controlas el resultado.