Elimina servidores MCP abandonados sin dejar accesos activos

Los servidores MCP abandonados merecen el mismo tratamiento que los scripts de despliegue abandonados: da por hecho que siguen funcionando hasta demostrar lo contrario. Una entrada obsoleta puede iniciar un comando local, dirigir a un agente a un endpoint remoto, exponer una variable de entorno antigua o conservar una ruta hacia una credencial que ya no tiene responsable.

He visto a desarrolladores eliminar un bloque de configuración, dar el trabajo por terminado y descubrir meses después que la misma herramienta todavía se iniciaba desde una extensión del editor o desde un archivo del repositorio. La solución no es una hoja de cálculo más grande. Hay que separar el descubrimiento, la revocación, la eliminación y las pruebas de que la ruta de acceso ha dejado de funcionar.

Una configuración eliminada no revoca una ruta de acceso

Eliminar servidores MCP abandonados significa cerrar todas las rutas que permiten a un agente realizar acciones, no limitarse a ocultar un servidor del menú de un cliente. La definición del servidor es solo una parte de esa ruta.

Una configuración local típica tiene cuatro piezas: la configuración del cliente, un comando de lanzamiento, la configuración o el entorno que se pasan a ese comando y la autoridad en el servicio de destino. Una configuración remota sustituye el comando local por una URL, pero sigue teniendo configuración del cliente y autoridad en el otro extremo. Los equipos suelen eliminar la primera pieza y dejar intactas las demás.

La especificación del Model Context Protocol describe los servidores como proveedores de capacidades, como herramientas, recursos y prompts. También admite distintos transportes, entre ellos stdio y conexiones basadas en HTTP. Esta diferencia importa al retirar un servidor. Un servidor stdio puede ejecutarse solo cuando un cliente local inicia su comando. Un servicio remoto puede seguir disponible después de que todos los desarrolladores eliminen la entrada local que apuntaba a él.

No mezcles estos conceptos:

• Un registro de configuración indica a un cliente concreto dónde encontrar un servidor.
• Un lanzador es el ejecutable, script, comando de contenedor, extensión o servicio que lo inicia o lo alcanza.
• Una concesión de autoridad es el token, identidad SSH, autorización OAuth, sesión de cuenta o permiso de red que permite que la acción tenga éxito.
• Un registro de ejecución demuestra que un cliente o agente utilizó realmente la ruta.

Equivocarse aquí produce dos resultados problemáticos. Puedes dejar una herramienta antigua capaz de alcanzar datos de producción o revocar una credencial que una herramienta activa todavía necesita y convertir una limpieza rutinaria en un incidente.

Empieza con una regla de retirada clara: si un servidor no tiene un responsable actual, un propósito documentado y pruebas de uso intencionado reciente, desactívalo mientras investigas. «Quizá lo necesitemos algún día» no es responsabilidad. Si alguien necesita reconstruirlo más adelante, el repositorio puede conservar la configuración sin credenciales y permitir que se cree una nueva con una credencial nueva.

Haz inventario de los clientes antes de buscar en el disco

El primer inventario debe enumerar los clientes, no los servidores, porque cada cliente lee la configuración desde lugares distintos. Los desarrolladores suelen tener instalados varios clientes de agentes, además de una integración con el editor, un asistente de terminal y ajustes específicos del proyecto guardados junto al código.

Anota cada lugar que pueda iniciar una conexión MCP en el equipo. Incluye aplicaciones de escritorio, agentes de línea de comandos, extensiones del IDE, scripts locales que invocan un agente y cualquier entorno de desarrollo remoto que monte el directorio personal. Pregunta al desarrollador qué usa realmente y compruébalo. La memoria es una prueba débil cuando la herramienta se ejecutó una vez durante un prototipo hace seis meses.

Para cada cliente, registra su versión, las ubicaciones de configuración indicadas en su propia documentación y si admite ajustes a nivel de usuario y de proyecto. No supongas una ruta porque otro cliente la utilizara. Las ubicaciones cambian y una ruta inventada da una falsa sensación de seguridad.

Una fila útil del inventario contiene suficiente información para tomar después una decisión de retirada:

Los ajustes del proyecto causan la mayoría de las sorpresas. Un desarrollador puede limpiar su configuración personal y seguir iniciando un servidor cada vez que abre un repositorio antiguo. Busca en la rama actual, en los archivos ignorados que se usan para la configuración local, en los archivos de configuración de ejemplo y en los scripts de incorporación. Revisa también los repositorios compartidos de archivos de configuración. Un servidor obsoleto suele sobrevivir porque alguien copió un fragmento práctico en una plantilla.

No trates el inventario como un documento de cumplimiento. Úsalo para impulsar acciones. Si no puedes identificar el sistema de destino y la fuente de autoridad de un servidor, márcalo como no resuelto y evita su uso casual hasta que puedas hacerlo.

Busca lanzadores, no solo archivos que se llamen MCP

Una búsqueda de texto de «mcp» encuentra la configuración evidente, pero los lanzadores pueden ocultarse bajo nombres de scripts genéricos y binarios de paquetes. Busca la etiqueta del servidor, el nombre del comando, el nombre del host, el puerto, el nombre del paquete y los nombres de las variables de entorno que aparezcan en el inventario.

En macOS, este comando proporciona una lista inicial acotada de posibles archivos de configuración JSON en el directorio personal. Omite deliberadamente el árbol de caché, que de otro modo produciría una gran cantidad de metadatos de paquetes irrelevantes.

find "$HOME" -type f \( -name '.mcp.json' -o -name 'mcp.json' -o -name '*mcp*.json' \) \
  -not -path "$HOME/Library/Caches/*" \
  -print 2>/dev/null

La salida tendrá un aspecto parecido a este:

/Users/dev/work/acme-api/.mcp.json
/Users/dev/Library/Application Support/example-client/settings.json
/Users/dev/.config/example-agent/mcp.json

La lista es una prueba, no una lista de eliminación. Abre cada archivo e identifica qué cliente es su propietario. Un nombre de archivo que contenga mcp puede corresponder a documentación, un experimento archivado o un archivo de bloqueo generado. A la inversa, un archivo de configuración con un nombre corriente puede contener la definición real del servidor.

Para archivos JSON cuyo esquema use un objeto mcpServers, este comando imprime una tabla compacta para revisar la configuración. No modifica los archivos.

jq -r '
  .mcpServers // empty
  | to_entries[]?
  | [.key, (.value.command // .value.url // "unknown"),
     ((.value.args // []) | join(" "))]
  | @tsv
' path/to/config.json

Un resultado habitual es este:

issue-tracker\tnpx\t-y @example/issues-mcp
legacy-reporting\thttps://reports.internal.example/mcp\t

Si el comando no produce nada, no deduzcas que todo es seguro. El archivo puede usar otro esquema, el cliente puede guardar los ajustes en otro lugar o el servicio puede llegar a través de una extensión.

Después, revisa las superficies de lanzamiento que sobreviven a una limpieza normal de archivos. En un Mac, mira los perfiles del shell, los ajustes de tareas del editor, los binarios globales del gestor de paquetes y los agentes de lanzamiento del usuario. launchctl print gui/$(id -u) puede revelar procesos que se inician con el usuario conectado, pero su salida puede exponer argumentos de comandos o valores de entorno. Consúltala localmente y no la pegues en un ticket ni en un chat.

Busca contenido con términos concretos en lugar de escanear y exportar todo el directorio personal. Por ejemplo, cuando sepas que un servidor abandonado llama a old-report, busca ese nombre literal, su antiguo nombre de host y su ejecutable. Así encontrarás wrappers como scripts/agent-tools.sh sin convertir una revisión de limpieza en una recopilación de datos privados.

Clasifica cada servidor según su autoridad actual

Un servidor puede parecer muerto y conservar autoridad activa, así que clasifícalo según su forma de autenticación antes de tocar sus archivos. El mismo nombre de servidor puede usar credenciales distintas en equipos diferentes, por lo que una retirada a escala de equipo necesita pruebas por máquina.

Usa cinco categorías prácticas. Describen dónde reside el poder, no cómo se presenta el servidor.

1. Sin autoridad remota. El servidor lee archivos locales no sensibles o produce resultados locales. Aun así puede crear un problema de cadena de suministro o privacidad, pero la revocación suele consistir en eliminar sus permisos de proceso y su configuración.
2. Autoridad basada en el entorno. El lanzador recibe un token API, una contraseña o una cadena de conexión mediante un perfil del shell, un archivo .env, un ajuste del IDE o una configuración de lanzamiento.
3. Autoridad basada en archivos. El lanzador lee una clave privada SSH, un certificado de cliente, un archivo de cuenta de servicio o una base de datos de credenciales local.
4. Autoridad gestionada por el proveedor. El servidor usa OAuth, una instalación de aplicación, un inicio de sesión de dispositivo o una identidad gestionada. El proveedor, no un archivo de texto local, controla la concesión.
5. Autoridad de red y cuenta. El servidor no necesita un secreto explícito porque una red corporativa, una cuenta local, una sesión VPN o una dirección permitida le deja acceder a un servicio. Esta categoría es fácil de pasar por alto y difícil de retirar correctamente.

Registra la cuenta exacta, el alcance y el objetivo de cada fuente de autoridad. «Token de Git» no basta. Necesitas saber si pertenece a una cuenta personal, una cuenta de bot o una identidad de máquina compartida, y si puede leer repositorios, escribir incidencias, activar despliegues o acceder a API administrativas.

Aquí la limpieza deja al descubierto atajos incómodos. Un comando MCP local que recibe un token personal amplio a través de ~/.zshrc no se vuelve inofensivo porque el desarrollador haya dejado de usarlo. El token puede alimentar también otros scripts, por lo que revocarlo requiere coordinación. Eso no es motivo para aplazar el trabajo. Es motivo para identificar las dependencias antes de revocarlo.

Mantén el inventario basado en hechos. No incluyas valores de tokens, claves privadas, encabezados de autorización completos ni copias del contenido de configuraciones. Una referencia como «entrada de credencial con el nombre reporting-read» o «huella SSH terminada en 3f:91» permite a la persona adecuada encontrar la autoridad sin crear otro repositorio de secretos.

Revoca en el servicio antes de eliminar las pruebas locales

Revoca la autoridad activa en el proveedor o servicio de destino antes de eliminar la configuración local. Este orden impide que una configuración copiada, otro equipo o un lanzador inadvertido sigan usando la misma concesión.

Para los tokens API, utiliza la interfaz de gestión de tokens del proveedor o su endpoint de revocación documentado. Confirma qué token revocas mediante su identificador, etiqueta, cuenta, datos de creación o registro del último uso, si el proveedor ofrece esa información. Después elimina su valor de los archivos locales y los almacenes de credenciales. Nunca pruebes un token revocado pegándolo en un formulario web o en un comando del shell que pueda guardarlo en el historial.

OAuth requiere especial cuidado. RFC 7009 define una solicitud de revocación de tokens enviada al endpoint de revocación del servidor de autorización. También permite que el servidor devuelva una respuesta correcta aunque el token no sea válido, lo que impide que quien llama descubra si el token existe. Por eso, un estado 200 por sí solo no demuestra que hayas revocado la concesión correcta. Comprueba la vista de autorizaciones o aplicaciones conectadas del proveedor y haz una llamada controlada a través de la ruta antigua solo si las prácticas de seguridad habituales lo permiten.

Para SSH, elimina la clave pública o la clave de despliegue de todos los lugares que la acepten. Esto puede incluir las claves autorizadas de una cuenta, los ajustes de claves de despliegue de un repositorio, una cuenta de bastión, un servicio de CI y una fuente de gestión de configuración que vuelva a poblar authorized_keys. Eliminar ~/.ssh/old_agent_key solo borra una copia local. No hace nada con otra copia ni con la autorización del lado del servidor.

En el caso de instalaciones de aplicaciones y cuentas de servicio, desactiva o elimina la instalación, rota el secreto del cliente o la credencial privada si existe posibilidad de exposición y elimina las asignaciones de roles que solo existían para el servidor retirado. Trata los roles amplios como una tarea de limpieza aunque la cuenta de servicio permanezca. Una herramienta de agente rara vez necesita el mismo acceso que un administrador humano.

El acceso basado en red requiere otra conversación. Elimina entradas antiguas de listas permitidas, reglas de firewall, pertenencias a grupos VPN o rutas DNS internas solo después de identificar a su responsable y a sus consumidores. No uses un ticket de limpieza MCP como permiso para romper una integración no relacionada. Aísla la regla concreta y fija un plazo para que su responsable confirme si se utiliza.

Registra el resultado de la revocación como un evento: quién la realizó, qué identificador de autoridad revocó, dónde lo hizo y cómo lo verificó. Evita guardar secretos o capturas que los contengan. Este registro importa cuando un repositorio falla más adelante y alguien pregunta si la limpieza lo causó.

Elimina las definiciones locales siguiendo una secuencia reversible

Elimina las definiciones locales después de revocar el acceso de origen y siguiendo una secuencia que conserve una vía privada de recuperación sin conservar credenciales activas. Una desinstalación descuidada puede dejar a un proyecto sin explicación de aquello de lo que dependía. Un archivo demasiado cauteloso puede mantener un token utilizable en una carpeta olvidada. Separa la configuración del material secreto.

Usa esta secuencia para un servidor cada vez:

1. Detén el cliente de agente y la extensión del editor correspondientes. Un cliente en ejecución puede mantener vivo un proceso hijo o volver a escribir sus ajustes al salir.
2. Copia los campos de configuración no secretos del servidor en el registro de retirada: nombre, comando o URL, argumentos, objetivo previsto, responsable y fecha de eliminación. Sustituye los valores secretos por una descripción de dónde estaban guardados.
3. Revoca la autoridad en el servicio de destino y registra los datos de confirmación.
4. Elimina la entrada del servidor de todas las configuraciones de usuario y de proyecto identificadas. Borra las variables de entorno y las referencias a archivos de credenciales retirados.
5. Desinstala el paquete específico, la extensión, la imagen de contenedor o el script wrapper si ningún servidor activo lo utiliza. Si el paquete sirve para otros trabajos, elimina solo el comando abandonado y documenta la dependencia compartida.

Evita editar con una sustitución amplia de texto. Las comas de JSON, las comillas del shell y los bloques de entorno compartidos castigan las ediciones improvisadas. Usa la interfaz de ajustes del cliente cuando escriba una configuración válida de forma predecible. En caso contrario, crea una copia de seguridad con permisos restrictivos, edita un objeto y valida el resultado antes de volver a abrir el cliente.

Para JSON, jq ofrece una comprobación sintáctica sencilla:

jq empty path/to/config.json && echo "valid JSON"

Esto demuestra que el JSON se puede analizar. No demuestra que el cliente acepte el esquema ni que hayas eliminado todas las referencias. Lee el objeto correspondiente después de editarlo y usa el cliente para inspeccionar su lista de servidores configurados.

No archives un .env completo, una clave privada ni un archivo de ajustes que contenga un token bearer en una carpeta archive del proyecto. El control de versiones, las copias de seguridad en la nube y la búsqueda del escritorio hacen que ese error se propague. Conserva un registro sin secretos y utiliza el historial de auditoría del proveedor como prueba de que la credencial anterior existió.

La eliminación de paquetes también requiere moderación. Un paquete de runtime instalado globalmente puede ser utilizado por varias herramientas activas. Antes de borrarlo, pregunta qué nombre de ejecutable invoca cada configuración que siga activa. He visto limpiezas que eliminaban una dependencia de runtime compartida y obligaban después a otro equipo a depurar una sesión de agente rota, porque el mensaje de error mencionaba un paquete ausente en lugar de la herramienta eliminada.

Demuestra que nada inicia ni alcanza el servidor retirado

La retirada termina cuando los clientes relevantes ya no pueden descubrir, iniciar ni autenticar el servidor. Revisar la configuración por sí solo no demuestra ninguna de esas cosas.

Reinicia por completo el cliente. Cerrar una ventana puede no detener un asistente de la barra de menús, el host del editor o un proceso hijo. Vuelve a abrir el cliente e inspecciona su lista de servidores configurados mediante sus diagnósticos habituales. Si muestra el servidor retirado, no has encontrado una fuente de configuración o un mecanismo de sincronización ha vuelto a restaurarlo.

Después, realiza una prueba de lanzamiento acotada. Abre el repositorio que antes proporcionaba la configuración del servidor, inicia el agente y solicita una acción inofensiva que no esté relacionada con el servidor retirado. Observa la actividad de los procesos locales para localizar el nombre del ejecutable retirado y revisa los registros del cliente en busca de intentos de conexión al antiguo nombre de host. No invoques la herramienta retirada contra un objetivo de producción activo solo para comprobar si falla.

En el caso de endpoints remotos, utiliza los registros de auditoría del proveedor, los registros de acceso o la actividad de la cuenta para comprobar si hubo intentos de uso después de la revocación. Una solicitud denegada después de una prueba controlada demuestra que la autoridad ya no funciona. La ausencia de registros es una prueba más débil porque el cliente quizá nunca intentó conectarse.

Comprueba también que la credencial antigua ya no aparezca donde no debe. Busca la etiqueta del token, el nombre de la variable de entorno, el nombre de host conocido, el nombre del archivo y la huella pública SSH. No busques el valor secreto completo si pudiera terminar en el historial del shell, el desplazamiento del terminal o un registro de comandos. La etiqueta y el punto de referencia suelen bastar.

Un fallo que conviene reconocer es este: un desarrollador elimina legacy-reporting de la configuración personal de su agente, reinicia el agente y no ve nada. Una semana después abre un repositorio antiguo. Sus ajustes locales ejecutan npx con un paquete viejo, el script carga REPORTING_TOKEN desde un perfil del shell y la API remota todavía acepta el token. Cada comprobación individual parecía correcta porque solo revisaba la configuración personal. El inventario debería haber relacionado la configuración del repositorio, el lanzador, la fuente del entorno y la concesión de la API antes de empezar la eliminación.

Conserva pruebas sin crear otra caché de secretos

Conserva suficientes pruebas para explicar una retirada, pero no conviertas la carpeta de auditoría en un archivo de accesos utilizables. El registro debe permitir que otro ingeniero responda qué existía, a qué podía acceder, quién aprobó la eliminación y qué prueba la cerró.

Un registro de retirada compacto puede incluir el identificador del servidor, las ubicaciones locales eliminadas, el comando o endpoint sin credenciales, el servicio de destino, el tipo de autoridad, el identificador de la concesión o la huella, la fecha de revocación, el responsable y el resultado de la validación. Guarda las notas operativas con control de acceso en el lugar donde tu equipo ya gestiona los registros de seguridad. No crees otro documento compartido lleno de configuraciones copiadas.

El historial de ejecución puede revelar dependencias que el inventario no detecta. Busca en el historial de sesiones del agente, los registros del cliente, el historial de instalación del gestor de paquetes, los cambios del control de código fuente que añadieron la configuración y la actividad del servicio de destino. Interpreta los tiempos con cuidado. Un registro puede demostrar que se ejecutó un proceso, pero no necesariamente que una herramienta completó una acción privilegiada.

Sallyport registra las ejecuciones de los agentes y las llamadas HTTP o SSH individuales en diarios separados proyectados desde un registro de auditoría cifrado y ciego a escritura. Si un equipo lo utiliza, sp audit verify puede verificar sin conexión esa cadena de auditoría sobre texto cifrado sin necesitar la clave de la bóveda, lo que ayuda a conservar las pruebas durante una revisión de acceso.

No confundas las pruebas de manipulación con un inventario completo. Un registro solo anota las acciones que pasan por su punto de registro. No revelará un servidor antiguo que se ejecutó fuera de él, una configuración olvidada que nadie inició ni un token copiado que otro script utilizó directamente.

Haz que la responsabilidad caduque antes de que las herramientas se conviertan en hallazgos arqueológicos

La limpieza menos dolorosa ocurre cuando los equipos asignan un responsable y una fecha de revisión al instalar una herramienta. La regla parece administrativa hasta que tienes que averiguar por qué un agente todavía puede alcanzar una API cuyo proyecto original terminó hace años.

Pide un plan de retirada breve cada vez que alguien añada un servidor con acceso de escritura, visibilidad de producción o acceso amplio a repositorios. El plan debe indicar el responsable, los repositorios previstos, el tipo de autoridad, los sistemas de destino y el evento que activa la eliminación. Un prototipo puede tener una fecha de revisión próxima. Una herramienta compartida puede tener un mantenedor identificado. Ninguna debe tener una excepción permanente y sin responsable.

Usa la configuración a nivel de repositorio con moderación. Un servidor de proyecto es adecuado cuando el proyecto realmente lo necesita y su configuración no contiene credenciales. Es un mal lugar para los experimentos personales de un desarrollador. Mantén los experimentos en un lugar privado y desechable, y después promuévelos asignándoles un responsable o elimínalos antes de que el árbol de trabajo se convierta en una plantilla.

Revisa la situación después de cambios en el cliente del agente, traspasos de equipo, archivado de repositorios y rotaciones de credenciales. Estos eventos revelan el desvío con más fiabilidad que un ritual de calendario arbitrario. Cuando la revisión encuentre un servidor desconocido, suspende primero su ruta hacia los sistemas sensibles y después rastrea a su responsable y sus dependencias. Una herramienta que nadie puede explicar no debe conservar permiso para actuar.

La próxima limpieza debería empezar con un equipo real y un cliente activo. Completa el inventario hasta que cada servidor tenga un responsable, una ruta de lanzamiento y una fuente de autoridad. Las entradas que no cumplan ese estándar ya te han indicado qué debes retirar.